Easy DevOps interview questions

Ordering and retransmission are what TCP adds, and both of them cost time. Naming something that deliberately gives them up, and saying why, is what turns a textbook answer into a real one.

The arithmetic takes thirty seconds to learn and gets asked constantly. What it is really testing is whether you have ever had to size a VPC that could not be resized later.

Five stages, and which one you are stuck in tells you what to fix. A machine that reaches a GRUB prompt has a different problem from one that hangs waiting on a filesystem that no longer exists.

Most of what looks like used memory on a healthy Linux box is page cache doing its job. Knowing which column to read, and why df and du disagree, is half of Linux triage.

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.

Multi-AZ is the answer and the reason matters more than the acronym. Each tier fails differently, and the database is the one where high availability means a failover with a real gap, not zero interruption.

Four levels, and the two that matter operationally are the subscription, where quotas and billing live, and the resource group, which is the unit you delete. Getting the boundaries wrong is expensive to unpick later.

Service principal with a client secret is the answer people give and the one that leaves a credential in a config file. Managed identity is the same object with the secret handled by the platform.

One is layer 4 and regional, one is layer 7 and regional, one is layer 7 and global. Answer on those two axes and the choice makes itself, including when you need two of them together.

Two questions settle most of it: how much of the machine do you want to own, and is the workload request-shaped or long-running. Fargate is a way of running containers rather than a competitor to ECS and EKS, which is the distinction people get wrong.

Two structural differences matter more than any service mapping: the VPC is global rather than regional, and permissions are granted to members on resources through a hierarchy rather than attached to identities.

The comparison table is easy to recite and explains nothing about the failure the difference actually 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.

A question that sounds introductory and turns on one distinction: what you stop operating, and what you start paying for instead. 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.

Four commands, and the interesting one is plan, because it is the only point where you see the three-way comparison Terraform is actually making before anything changes.

It copies a small Python program to the target over SSH, runs it, and deletes it. Once that is clear, the agentless claim, the performance characteristics and the idempotency requirement all stop being separate topics.

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.

A VM virtualises hardware and boots its own kernel. A container is a process on the host kernel with its view of the world restricted. Everything else, including the security answer, follows from that one difference.

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

Three states, three completely different causes, and one command that tells you which you are looking at. The state name says whether the problem is the scheduler, the registry or your own process.

A namespace scopes names, permissions and quotas. It does not scope the kernel or the network by default, and the gap between what people assume it isolates and what it does is where the trouble starts.

Selectors match object labels; owner references record controller relationships. Keeping those mechanisms separate explains how a Service can select the wrong pods without owning them.

A ReplicaSet keeps a count. A Deployment manages a sequence of ReplicaSets, and that is the entire difference: it is what turns a change into a rollout you can pause and undo.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.

The writable layer is part of the container, not the image, and it dies with the container. Everything about volumes follows from knowing which of those two a file is in.

It is Kubernetes with an opinion, and the opinion that catches everyone is that containers do not run as root. A manifest that works on vanilla Kubernetes and fails here usually fails for exactly that reason.

Explain per-node eligibility and update behaviour, then verify that a Ready collector is actually delivering logs.

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.

The registry is often assumed to figure 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, 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.

The opener in most DevOps interviews, and the one most people answer as a list of nouns. What earns the follow-up is saying what each stage is allowed to fail for and how long it takes.

Pipeline as code moved the build definition into the repository, where it is reviewed and versioned with the thing it builds. Declarative is the default answer, and knowing when scripted still earns its place is the follow-up.

Jenkins is mostly plugins, they have a dependency graph nobody drew, and the controller is a single point of failure for every team. The answer is a rehearsal against a copy of production, not a maintenance window and hope.

Four nested things and one rule that explains most confusion: jobs run on different machines and share nothing unless you make them. Everything about artifacts and caching follows from that.

Stages, jobs, steps, and a pool that supplies the machine. The piece that decides most real designs is the agent pool, because Microsoft-hosted agents cannot reach a private network and most enterprise deployments need to.

Compare proxy, hosted and group repositories. Trace a tested artifact into production, and understand when a cache can keep builds running during an upstream outage.

Git merges by comparing both branches against their common ancestor. A conflict means both sides changed the same region, and the resolution nobody checks is the one that compiles and is semantically wrong.

Connect version numbers to consumer promises, then test an additive API change against older clients and distinguish release metadata from artifact identity.

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.

Prometheus asks your service for numbers on a schedule rather than waiting to be told. That one design choice explains service discovery, exporters, staleness and why short-lived jobs are the awkward case.

Metrics quantify impact, traces expose instrumented request paths, and logs describe individual events. Follow a slow checkout across all three while accounting for missing evidence.

All three can search logs. What differs is who operates the cluster and how the bill is shaped, and the bill is what kills these projects, not the querying.

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.

Status codes describe an HTTP failure category. Locate the component that emitted the response, then use its logs to distinguish connection, capacity and application failures.

Three places, and which one depends on how the thing was started. Knowing which logs the runtime collects and which the application writes itself, and that journald may not persist across reboots, saves the first twenty minutes.

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.

Four scanners, four different things they see, and one rule that decides whether any of them help: a finding that arrives at the release gate is an argument, and the same finding on a pull request is a ten-minute fix.

Encryption is the part people focus on and the least interesting part. What you are buying is short-lived credentials, a revocation path and an audit trail, none of which an environment variable can give you.

Measuring the whole codebase gives a team an unpayable debt and a gate they turn off. Measuring only the lines changed in this pull request gives them a gate they can pass today.

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.

Stateless does not mean there is no state. It means the state is not in the instance, which is what lets you kill any instance at any time. Every scaling and deployment property people want depends on that one thing.

It converts a synchronous failure into a delay. That is the whole benefit and the whole cost, because the caller now gets an answer before the work has happened and somebody has to tell them when it did.

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 useful method is to decompose the bill into invocations, gigabyte-seconds and the lines nobody models, then locate the honest crossover rather than arguing about it.

Code is one of three inputs now. Data and the trained model are the other two, and they version differently, break differently and cannot be tested the way code is.

A loop that calls a model, gets asked to run a tool, runs it, and feeds the result back. Every operational difference comes from the fact that the number of iterations is not known in advance.

Tokens are the unit and input and output are priced differently. Get the arithmetic on the table in the first minute, because the number usually decides the design before any other consideration does.

The first question, the one people prepare least, and the only one where you choose what the rest of the interview is about. Two minutes, ending on something you want to be asked about.

A screening question that filters out people who have read about the field rather than looked at it. The answer that fails is a list of tools; the one that works describes who you serve and what you are on the hook for.

The question is really whether you learn deliberately or absorb whatever passes by. One specific thing learned recently, with why you picked it and what you did with it, beats any list of newsletters.