Easy DevOps interview questions

A beginner question with a senior follow-up hiding in it. Once you know a hard link is a second name for an inode, log rotation and backup behaviour both stop being mysterious.

Everyone recites the four letters. The scoring answer walks each packet across the wire and knows the places the exchange silently dies.

A one-line mistake that locks you out of the obvious fix. The fast recovery teaches more about the permission model than any man page will.

Every ops engineer schedules jobs; few can say which shell cron uses, where stdout lands, or why percent signs delete half a command. Those gaps are exactly what interviews test.

Everything top, htop and your APM agent display is derived from procfs anyway. Knowing the raw files turns any bare SSH session into a monitoring console.

The answer that lands is about one epoll loop per core, not config snippets. Master versus worker duties, the arithmetic of worker_connections, and the limits people forget to raise.

A and AAAA are the easy part. The bites live at the zone apex, inside 255-byte TXT chunks, in CAA blocking your renewals, and in SRV records half the internet ignores.

Volatile by default on many distros, size-capped by silent policy, binary on disk. Know the storage modes, the vacuum knobs, and how journald feeds central logging.

VRRP heartbeats, market data feeds, mDNS noise and cluster chatter all ride multicast, and all of it assumes a switched LAN. Why clouds drop it and what replaces it.

Asked in almost every cloud screen, and most candidates recite the table without ever naming the failure it causes. The ephemeral port range is the whole answer.

Trace the route and return path before changing rules. First establish whether the failing connection uses IPv4, IPv6 or a private service endpoint.

The junior-filter question that still separates candidates who understand the model from those who memorised a definition. The answer is three mechanical differences and one economic one.

Ask whether Multi-AZ means a DB instance or a DB cluster. One has a non-readable standby; the other has two readers. That distinction decides whether the proposal can relieve the primary.

Roles versus users looks like syntax trivia and is actually a secrets-management position. The follow-ups about instance profiles and IRSA separate practitioners from tutorial graduates.

Gateway endpoints avoid NAT processing for supported traffic. Interface endpoints have hourly and processing fees; cost savings depend on traffic, while access restrictions need explicit policies.

Postgres spends memory on a backend process per connection, and serverless fan-out treats that as an invitation. Pooling at the proxy layer is the standard cure; pinning is the catch.

Quotas are invisible until launch day. Treating them as tracked inventory with utilization alerts beats discovering them in a postmortem.

Managed Kubernetes offers several responsibility models. Application availability remains yours even when the provider also manages nodes and networking, and the interview tests whether you know where that line sits.

Reading a plan is a skill separate from writing HCL. People trusted with production approves read the diff in a fixed order, and one of the checks is what the plan does not contain.

HashiCorp calls provisioners a last resort and expects you to say why in concrete terms: tainted resources, invisible drift, SSH reachability. Then name what replaces each legitimate use.

The right answer depends on who owns the truth: the platform, the caller, or nobody. At scale there is a fourth option most candidates miss, where your image pipeline publishes values instead of Terraform hunting for them.

OpenTofu is the Linux Foundation fork of Terraform 1.5 under MPL, drop-in compatible for most code, with distinct features such as native state encryption. Removed blocks and provider mocking also exist in Terraform. Portability survives by pinning version floors and testing both binaries in CI.

Generation works when the inputs are genuinely data and dies when YAML grows loops. The line between encoding decisions and writing a worse programming language is where these interviews are actually scored.

Terraform shapes the world; images define what boots inside it. Bake contents into versioned artifacts on a patch cadence, roll fleets by replacement, and keep user_data for identity and wiring only.

The friendliest DaemonSet question there is, and it still separates people who have operated one from people who have read about one. The scheduling rules hide the traps.

It sounds like trivia and screens for something real: whether you understand that a pod is a shared namespace boundary with an owner, not just a group of containers.

Most candidates say the registry figures it out. The real mechanism is an index of per-platform manifests and a client-side choice at pull time, and knowing which layer makes that choice is the whole question.

Exec into a distroless image and you get nothing, because there is nothing to exec into. Ephemeral containers inject tooling into a running pod without restarting it, and the security caveats are what interviewers really listen for.

The gating instinct is right and the cardinality is wrong: init containers make every new replica race the same migration. Here is the once-per-release shape interviewers want, plus the rollback rule that shapes all DDL review.

Two cleanup mechanisms hide behind one taint: image garbage collection removes unreferenced images by LRU at threshold crossings, while eviction kills pods. Candidates who conflate them fail this question quietly.

Best-effort objects, one-hour TTL, deduplicated by count, invisible unless shipped out. Events narrate scheduling and lifecycle decisions; treating them as durable records is the expensive mistake.

Two-phase deletion, a controller that purges content, finalizers holding the door. Stuck CRD instances, dead webhooks and GitOps recreates are the real story; standards prevent the ticket.

A vocabulary check with a trap inside it. Strict semantic versions bind libraries and SDKs; continuously deployed services play a different game, and pretending otherwise signals inexperience.

Same commit, different dependency trees: the vocabulary answer is lockfiles, the practitioner answer includes frozen installs, integrity hashes and pinned toolchains.

Changelogs fail because discipline lives in people instead of gates. Enforce commit convention at merge time, generate at tag time, and know what automation cannot write.

Hooks must finish in seconds or developers bypass them, and a bypassed hook protects nothing. Budget feedback latency numerically and split checks by authority and hermeticity.

Ownership files decay faster than org charts. What separates working CODEOWNERS from rubber-stamp theatre is hygiene: team aliases, stale-owner linting, and keeping review routing apart from paging.

Dependency bots fail as noise generators or silent auto-mergers. Tiering by risk, weekly batching, and treating bot PRs with a real review SLA is what keeps updates flowing.

One cadence for every team is the naive answer. Cadence follows constraints: store review for mobile, compatibility windows for APIs, contracts and embedded realities for trains.

The roles question is really a delegation test: can you split commanding the incident from fixing it? Name the roles, the comms cadence, and the handoff discipline that keeps 3am coherent.

Usable runbooks live one click from the alert, front-load symptom-to-action pairs, and stay alive because CI and drills force the issue rather than anyone hoping.

One surface cannot serve the responder and the review. Tier dashboards by the question each audience asks, and make every tile answer in five seconds or link one click deeper.

Monitoring dies silently: stuck alert queues, full TSDBs, collectors killed inside the same blast radius. Layer independent checks and a heartbeat so absence of signal pages louder than any red dashboard.

Comms is a role, not a chore bolted onto the incident commander. Audience-specific cadences, a committed next-update time in every message, and plain language that support can actually repeat.

The gentlest scheduling question there is, and it still separates people who read the events from people who guess. Check whether the pod has a node before choosing between scheduling and startup diagnosis.

This one separates people who read journals from people who restart harder. The exit code and signal systemd already recorded usually name the disease.

A public registry throttles by source IP and your whole fleet shares one. Why fifty nodes count as a single anonymous user, and authentication and caching changes that reduce upstream demand.

Wall-clock schedules meet daylight-saving transitions: spring forward deletes an hour of cron targets, fall back repeats one. Schedule in UTC, add idempotency keys, rehearse in staging.

Stop the source before tuning anything: kill the runner, revoke its credentials, shed test-shaped traffic at the edge, protect checkout. Forensics and guardrails only after customers stop feeling it.

The honest answer splits traffic containment from access control. Flat yes or no loses points here; the condition under which segmentation stops being theatre is what the interviewer wants.

Experienced answers are ordered and verifiable: minimal base, benchmark applied as code, identity and exposure next, then continuous proof it stayed that way. Checklists recited out of order are the tell.

VPN grants a network, ZTNA brokers an application. The strong answer covers the engineer-specific protocols nobody mentions, device posture for contractors, and the break-glass path when the IdP is down.

A WAF matches patterns in HTTP and stops there. Know exactly which classes it catches, which it cannot see, and what closes the gap, because block-dashboard confidence is how breaches happen anyway.

Champions programmes die as mailing lists with a name. Survivors protect the time, pay in career currency, keep the job description tiny, and measure outcomes rather than attendance.

Labels without consequences die quietly. Attach classification to enforced defaults in Terraform modules, propagate tags to every copy of the data, and give engineers twenty worked examples instead of a taxonomy lecture.

Discover, scan, deduplicate, prioritise with context, route with SLA clocks, verify, measure. Most programmes rot at dedup and ownership: five scanners produce five conflicting queues nobody trusts.

The default answer is 'horizontal' because interviews reward it. The correct answer names the constraint that makes distribution expensive and knows when one big machine is the engineering choice.

The vocabulary question hiding real depth: which primitive replaces ORDER BY, why sharding by player is wrong, and what a 45,000 updates-per-second storm actually costs.

The tool emits recommendations; the programme is everything around it. Interviewers use this question to see whether you can turn a dashboard into landed changes without breaking production or trust.

Most tagging initiatives are spring cleans that rot within two quarters. The durable answer treats the schema like an API contract enforced where resources are born, and knows which lever actually wins.

Pay-per-use sounds free until the invoice arrives. The candidates who impress decompose the bill into invocations, gigabyte-seconds and the lines nobody models, then locate the honest crossover.