Question 1

What does DevOps mean to you?

Accepted Answer

Shared ownership of software from commit to production — developers accountable for how their code runs, and platform engineers building the automation that makes that safe. In practice it shows up as automated delivery, infrastructure as code, observability owned by the team writing the code, and a blameless culture around failure. The answer to avoid is "DevOps is a role that does CI/CD". Interviewers listen for cultural and organisational components alongside tooling, and naming the four DORA metrics as how you would measure it is a strong close.

Question 2

What is a container image layer and why does layer order matter?

Accepted Answer

An image is built from stacked read-only layers, one per instruction, cached and reused across builds. Order matters because changing one layer invalidates every layer after it — so you copy dependency manifests and install dependencies before copying application source. This single optimisation turns a two-minute rebuild into ten seconds. The security corollary is that deleting a file in a later layer does not remove it from the image, so a secret baked into an early layer remains recoverable.

Question 3

How do you reduce container image size and why does it matter?

Accepted Answer

Multi-stage builds so the runtime image contains only artefacts, minimal or distroless base images, combining RUN commands, cleaning package caches in the same layer, and a .dockerignore. It matters for pull time — which affects cold start and autoscaling speed — and for vulnerability surface. The security argument is stronger than the size one: a build-tool-laden image gives an attacker a compiler and package manager inside your container. Distroless has no shell, which changes how you debug — worth naming as the trade-off.

Question 4

What is the difference between CMD and ENTRYPOINT?

Accepted Answer

ENTRYPOINT defines the executable that always runs; CMD provides default arguments that can be overridden at run time. Using ENTRYPOINT in exec form with CMD for defaults gives a container that behaves like a command with sensible defaults. The exec-form point matters operationally: shell form runs the process as a child of a shell, so it does not receive SIGTERM directly and graceful shutdown silently breaks. That is a real cause of dropped requests during deployments.

Question 5

Why does SIGTERM handling matter for containers?

Accepted Answer

The runtime sends SIGTERM and then, after a grace period, SIGKILL. The application should stop accepting new work, finish in-flight requests and exit. If it ignores SIGTERM — or is not PID 1 because of a shell-form entrypoint — requests are cut off on every deploy and scale-in. This causes the low-rate 5xx blip many teams accept as normal during deployments, which is entirely avoidable. Connecting the platform behaviour to an application code requirement is exactly what a DevOps interviewer is testing.

Question 6

What Linux commands would you use to diagnose a slow server?

Accepted Answer

top or htop for CPU and memory, vmstat and iostat for system-wide CPU, memory, swap and disk I/O, df and du for disk, ss for connections, dmesg for kernel messages including OOM kills, and journalctl for service logs. Then strace or perf to go deeper on a specific process. Knowing that an OOM kill appears in dmesg identifies "the process just disappeared" quickly. The AWS-specific equivalent when the instance is unreachable is the EC2 Serial Console or the instance screenshot, which is worth naming.

Question 7

A disk is full but du does not account for the space. What is happening?

Accepted Answer

Almost certainly a deleted file still held open by a running process — the space is not released until the descriptor closes. Find it with lsof looking for deleted entries, then restart the holding process. It is usually a log file removed rather than rotated. Knowing the lsof diagnosis immediately is a strong signal. The preventive answer is proper log rotation with copytruncate, or shipping logs off the machine so they never accumulate locally.

Question 8

How would you debug a service that is unreachable?

Accepted Answer

Work outward in layers: is the process running and listening on the expected port; does the host firewall allow it; does the security group allow it in the right direction; does the NACL allow both request and return traffic; is there a route and gateway; does DNS resolve correctly; and is the load balancer target healthy. Naming VPC Reachability Analyzer as the tool that traces the configured path and names the blocking component turns a list of hypotheses into a definitive answer. The host firewall is the layer people forget when AWS configuration looks correct.

Question 9

What is the difference between a Deployment, StatefulSet and DaemonSet in Kubernetes?

Accepted Answer

A Deployment manages interchangeable stateless replicas with rolling updates. A StatefulSet gives stable identities and per-pod persistent storage with ordered operations, for databases and queues. A DaemonSet runs one pod per node, for log collectors, monitoring agents and CNI plugins. The judgement to add is that a StatefulSet means you own backup, failover and upgrades for that data store, and on AWS a managed database usually beats self-managing on Kubernetes. Recommending against a StatefulSet is often the better engineering answer.

Question 10

How does Kubernetes decide where to schedule a pod?

Accepted Answer

The scheduler filters nodes by feasibility — resource requests, node selectors, affinity and anti-affinity, taints and tolerations, volume topology — then scores the remaining and picks the best. If none pass, the pod stays Pending and the autoscaler may add capacity. The point that matters operationally is that scheduling uses *requests*, not actual usage, so under-set requests cause overcommitment and over-set requests waste money. That single fact explains most Kubernetes capacity problems.

Question 11

What are resource requests and limits, and what happens when a container exceeds each?

Accepted Answer

A request is what the scheduler reserves; a limit is the runtime ceiling. Exceeding a CPU limit causes throttling — the container is slowed. Exceeding a memory limit causes an OOM kill and restart, because memory is incompressible. That asymmetry is the substance. Exit code 137 in a restarting container means OOM-killed, and recognising that immediately is what shows operational experience rather than theory.

Question 12

What is the difference between a liveness, readiness and startup probe?

Accepted Answer

Liveness determines whether the container is healthy — failing it restarts the container. Readiness determines whether it can serve traffic — failing it removes the pod from endpoints without restarting. A startup probe protects slow-starting applications by disabling the other two until it succeeds once. The dangerous misconfiguration is a liveness probe checking a downstream dependency: when the database blips, every replica restarts simultaneously, turning a partial outage into a total one. Liveness tests the process; readiness is where dependency checks belong.

Question 13

What is a PodDisruptionBudget and how can it cause a problem?

Accepted Answer

A PDB declares the minimum pods that must remain available during voluntary disruptions such as node drains, so an upgrade cannot evict all replicas at once. Set too strictly — minAvailable equal to the replica count — it blocks drains entirely and stalls cluster upgrades indefinitely. That the same mechanism can cause both an outage and a stuck upgrade is what makes it a good question. Managed node groups and Karpenter both respect PDBs, so it directly affects whether upgrades complete.

Question 14

What is the difference between git merge and git rebase?

Accepted Answer

Merge creates a commit joining two histories, preserving what actually happened. Rebase replays your commits on top of the target branch, producing linear history but rewriting commit hashes. Never rebase a branch others have pulled, because their history diverges. The rule about not rebasing shared branches is the safety point interviewers check. A common convention worth naming is rebasing locally before pushing to keep history readable, then merging pull requests with a squash or merge commit.

Question 15

How do you handle merge conflicts and how do you avoid them?

Accepted Answer

Resolve by understanding both changes rather than picking a side blindly, then testing. Avoid them with small, frequent, short-lived branches, regular integration from main, and clear ownership so two people rarely edit the same code simultaneously. The structural answer is trunk-based development with feature flags, because long-lived branches guarantee painful merges. Interviewers use this to probe working practice as much as Git mechanics.

Question 16

Write a command to find the ten largest files in a directory tree.

Accepted Answer

Use find to list files with sizes, sort numerically and take the top ten; du with sort for directories. The point is comfort composing standard tools rather than memorising a specific incantation. Small scripting questions check whether you can actually operate a machine. Being able to explain why -print0 or careful quoting matters for filenames with spaces is worth more than the shortest one-liner.

Question 17

How do you make a shell script safe for automation?

Accepted Answer

Start with set -euo pipefail so it exits on error, undefined variables and pipeline failures. Quote all variable expansions, use trap for cleanup, check preconditions explicitly, log what it is doing, and make it idempotent so a re-run after partial failure is safe. Idempotency is the requirement that matters most in automation, because scripts get re-run after failures. A deployment script that appends rather than sets, or creates without checking, causes duplicates on the second run.

Question 18

What would you automate first in a team doing everything manually?

Accepted Answer

Whatever is most frequent, most error-prone and most painful — usually deployment, because manual deployment is both risky and limits release frequency. Then environment provisioning with IaC, then testing, then routine operational tasks. Measure where time actually goes rather than guessing. The reasoning is frequency multiplied by risk, not "what is easiest to automate". Naming that you would measure first shows you optimise for impact rather than for the satisfying project.

Question 19

What is immutable infrastructure and why does it help?

Accepted Answer

Servers and containers are never modified after deployment — to change anything you build a new artefact and replace the old one. Running instances always match a tested build, configuration drift is impossible, rollback is redeploying the previous artefact, and debugging does not have to account for accumulated ad-hoc changes. On AWS this means golden AMIs from Image Builder or containers, deployed by replacing instances or tasks. The contrast is in-place configuration management, where every server's state is the result of a unique history nobody can reproduce.

Question 20

How do you manage configuration across environments without duplication?

Accepted Answer

A shared base with environment-specific overlays — Kustomize overlays, Helm values files, or IaC variable files per environment — so the difference is small, visible and reviewable. Secrets come from Secrets Manager per environment, never from the configuration files. The test of a good setup is whether you can see the entire difference between staging and production in one small diff. If you cannot, the environments drift and staging stops predicting production behaviour.

Question 21

How do you handle secrets rotation without downtime?

Accepted Answer

Support two valid credentials during the rotation window: create the new one, deploy consumers that accept both, switch producers, verify, then revoke the old. Secrets Manager's alternating-users rotation strategy implements exactly this for databases. The dual-validity window is what makes rotation non-disruptive, and it applies to database passwords, API keys and certificates alike. Teams that rotate by changing the value and redeploying everything simultaneously usually stop rotating.

Question 22

What is the on-call experience you would design for a team?

Accepted Answer

Enough engineers that the rotation is sustainable; runbooks linked from every alert; a documented escalation path; alerts that are actionable, urgent and user-affecting only; a handover process; compensation or time in lieu; and an agreement that a noisy alert is a defect to be fixed rather than tolerated. Tracking pages per shift as a health metric is the concrete mechanism, with a threshold above which alert tuning becomes the priority. Someone who has been on call describes the human side unprompted, which is what this question surfaces.

Question 23

How do you decide what belongs to the platform team versus application teams?

Accepted Answer

The platform owns what should be consistent and is expensive to get right repeatedly — networking, identity, delivery pipelines, observability standards, guardrails. Teams own what is specific to their product. The platform provides paved paths rather than approval gates. The failure mode is a platform team that becomes a ticket queue, recreating the bottleneck cloud was meant to remove. Framing the platform as a product with internal customers is what avoids it.

Question 24

How do you introduce infrastructure as code to a resistant team?

Accepted Answer

Start where the pain is — a repeated manual task or an environment nobody can recreate — and demonstrate value on something low-risk. Import existing infrastructure gradually rather than demanding a rewrite, provide modules so the easy path is the correct path, and pair with people rather than mandating a standard. The paved-path idea is the important one: adoption happens when the governed way is also the easiest way. Mandates without tooling produce compliance theatre, and interviewers assessing seniority listen for that distinction.

Question 25

What is the difference between a rolling restart and a rolling update?

Accepted Answer

A rolling update replaces pods or tasks with a new version. A rolling restart replaces them with the same version — used to pick up a changed ConfigMap or Secret, or to clear bad state — triggered by patching an annotation so the pod template changes. The gotcha it addresses is that changing a ConfigMap does not restart pods consuming it as environment variables, so the change silently does not apply. Knowing kubectl rollout restart and why it works by mutating an annotation is a practical detail.

Question 26

How do you handle deployment dependencies between services?

Accepted Answer

Design so ordering does not matter: make APIs backwards and forwards compatible, use expand-and-contract for contract changes, and have services tolerate a dependency being briefly on the old version. Where ordering genuinely matters, express it in the pipeline rather than relying on timing. The rule is that a deployment requiring a specific cross-team order will eventually be done in the wrong order. Designing for order-independence is more robust than coordinating, which demonstrates systems thinking.

Question 27

What monitoring would you set up on day one for a new service?

Accepted Answer

An uptime or synthetic check from outside; SLIs for success rate and latency with an SLO and burn-rate alerting; the four golden signals on a dashboard with deployment markers; structured logs with trace correlation; error grouping; and an alarm on the service hitting a capacity or concurrency limit. Starting with an external check is pragmatic because it catches the whole class of "the service is fine but unreachable" failures. Defining the SLO on day one is what forces the team to decide what "working" means.

Question 28

A developer asks for production access to debug an issue. How do you respond?

Accepted Answer

Ask what they need to see and provide it through logs, metrics, traces or a read-only view, which solves most cases. If direct access is genuinely required, grant time-bound elevated access through a role with session logging — Systems Manager Session Manager rather than SSH — with an alert on the grant and a review afterwards. A flat refusal pushes people towards shared credentials and workarounds. Offering a better path first and a controlled path second is what a mature platform engineer does.

Question 29

How do you keep an EKS cluster up to date safely?

Accepted Answer

Check deprecated API usage against the target version first using cluster insights; upgrade the control plane, then core add-ons, then node groups, respecting the version skew policy. Use managed node groups so drains respect PodDisruptionBudgets, test in a non-production cluster, and stay within the supported version window. Checking deprecated APIs before upgrading prevents workloads breaking on a version bump. Falling out of the supported window incurs extended-support charges and eventually forces an unplanned upgrade, which is worse than a planned one.

Question 30

How do you balance delivery speed against stability?

Accepted Answer

They are not opposed: smaller, more frequent changes are easier to review, test and roll back, so high performers achieve both. Use error budgets to make the trade-off explicit — ship while budget remains, prioritise reliability when it is exhausted — so the decision is data-driven rather than an argument. Citing the DORA finding that speed and stability correlate positively is the strongest version. The error budget as the arbitration mechanism turns a values disagreement into a policy, which is what makes it work in practice.

Question 31

What would you do in your first month on an unfamiliar AWS estate?

Accepted Answer

Inventory with Config and the Cost and Usage Report to find what exists and what matters; map how code reaches production; check IAM, guardrails and logging; find out what wakes people up; and talk to the teams. Then fix the highest-risk gap — usually credentials, untested backups or a missing rollback path — rather than starting a rewrite. Understanding and stabilising before changing is what interviewers assess. Naming a specific first fix — verifying that backups restore, or removing long-lived access keys — is more convincing than a general plan.

Question 32

What is the difference between reliability engineering and keeping things running?

Accepted Answer

Keeping things running is reactive — respond to alerts, restart failures, repeat. Reliability engineering treats operations as an engineering problem: measuring with SLOs, capping toil, automating repetitive work, and using postmortems and error budgets to change the system so the same failure cannot recur. The measurable expression is the toil cap — roughly half an engineer's time on engineering that reduces future load. A team firefighting all week is not doing reliability engineering regardless of job titles.

Question 33

How do you test disaster recovery?

Accepted Answer

Actually execute it: fail over to the secondary region in a scheduled exercise, restore a database from backup into a test environment and validate the data, and measure the real recovery time against the objective. Document what went wrong and fix it. An untested DR plan has an unknown recovery time, which is functionally the same as having none. Restoring backups regularly is the minimum, since an unverified backup is a hope rather than a control.

Question 34

What do you look for when reviewing an infrastructure pull request?

Accepted Answer

Whether anything is being destroyed or replaced; whether permissions are least-privilege; whether secrets appear anywhere; whether resources are tagged for cost attribution; whether the change is reversible; whether limits and probes are set sensibly; and whether it matches what the description claims. Scanning the plan or change set for destroy and replace lines first is the practical habit, because those cause outages and are easy to miss in a long diff. Automating a check that fails on an unlabelled destroy is the enforced version.

Question 35

How do you decide between EC2, ECS, EKS, Fargate and Lambda?

Accepted Answer

Start at the most managed option and step down only when a real constraint forces it. Lambda for short event-driven work; Fargate for containers without node management; ECS for simpler AWS-native orchestration; EKS when you need Kubernetes ecosystem or portability; EC2 for full OS control, specialised hardware or licensing. Naming the specific constraint that forces each step is what makes it a framework rather than a preference. Choosing EKS because the team likes Kubernetes, without a workload requirement, is a cost an interviewer will probe.

Question 36

Tell me about a time automation you built caused a problem.

Accepted Answer

A good answer describes real automation, the failure mode — acting on wrong input, running when it should not, or acting too fast to stop — the impact, how you detected and halted it, and the guardrail added afterwards: a dry-run mode, a blast-radius limit, a confirmation for destructive actions, or a rate limit. Interviewers ask this to see whether you build guardrails by default. The lesson they want is that automation amplifies mistakes, so anything destructive needs a bound on how much damage it can do before a human notices.

Question 37

How do you handle a flaky test suite?

Accepted Answer

Quarantine flaky tests so they do not block the pipeline, but track them as defects with owners rather than deleting them; find the cause — shared state, timing assumptions, real network calls, ordering — and fix it; and measure flakiness rate as a first-class metric. It matters because of trust: once a red build is assumed flaky, real failures are ignored and the pipeline protects nothing. Framing flakiness as a reliability problem rather than an annoyance is the mature position.

Question 38

What is the difference between a security group and a NACL, and which do you reach for?

Accepted Answer

Security groups are stateful, attached to interfaces, allow-only, and can reference other security groups — which is the idiomatic pattern for tiered architectures. NACLs are stateless, subnet-level, support deny rules, and require explicit rules in both directions. The practical guidance is to do almost everything with security groups and reserve NACLs for coarse subnet denies, because stateless rules require remembering ephemeral port ranges for return traffic — a classic source of mysterious failures.

Question 39

How do you keep learning in a field that changes this fast?

Accepted Answer

Depth on fundamentals — networking, Linux, distributed systems — because those transfer across every platform while service names change. Then hands-on work with new services on real problems, release notes for what you operate, and postmortems from other organisations, which teach failure modes cheaply. The point that lands is distinguishing durable knowledge from vendor-specific detail: someone who understands TCP, DNS and consistency models learns any cloud quickly, while someone who memorised service names relearns everything each cycle.

Question 40

How would you reduce deployment lead time from two weeks to one day?

Accepted Answer

Measure where the time actually goes first — waiting for approval, manual testing, batching releases, environment contention. Then attack the largest queue: automate the testing gate, remove manual approvals for low-risk changes, provide on-demand environments, and reduce batch size so each release is smaller and safer. Measuring before optimising is the answer, because the bottleneck is usually organisational rather than technical — approvals and batching, not build speed. Reducing batch size is the counter-intuitive lever that improves both speed and safety.

Question 41

What is a canary deployment and how do you decide to promote?

Accepted Answer

A canary sends a small percentage of real traffic to the new version, monitors it, then increases the share. Promotion should be gated on automated metrics — error rate and latency against the stable version — with automatic rollback, rather than a human watching a dashboard for five minutes. The automated criterion is what makes it valuable. Naming a specific one, such as p99 latency within a tolerance of baseline over a defined observation window, is what shows you have implemented rather than described it.

Question 42

How do you handle an incident where you cannot find the root cause quickly?

Accepted Answer

Restore service by whatever safe means — roll back, fail over, shed load, disable the feature — and continue investigating with the pressure off. Preserve logs, metrics and affected state. Communicate that service is restored while investigation continues, then run a blameless postmortem. The priority order is what is being tested: mitigation before understanding. Engineers who keep debugging a live outage because they want to know why are optimising for curiosity over users.

Question 43

What is GitOps and would you use it on AWS?

Accepted Answer

GitOps makes a Git repository the source of truth with an agent continuously reconciling the cluster to match. On EKS that is Flux or Argo CD, with Flux available as an EKS add-on. You get drift correction and auditability, since every change is a reviewed commit. The trade-off to acknowledge is that emergency manual changes are reverted unless you have a defined break-glass procedure. Presenting reconciliation as purely beneficial, without that caveat, is the weaker answer.

Question 44

How would you design a paved path for application teams on AWS?

Accepted Answer

Provide a templated repository with a working pipeline, IaC modules for the standard patterns — a Fargate service behind an ALB, a Lambda API, a data pipeline — pre-wired observability, secrets handling and guardrails, plus documentation and an example. Teams start from it rather than assembling from scratch. The measure of success is adoption without mandate: if the paved path is genuinely the fastest route, teams choose it. Naming that you would treat it as a product with feedback and versioning is what distinguishes a platform engineer from a template author.

AWS DevOps Engineer Interview Questions Interview Questions and Answers

How to use this set