Top 30 Advanced DevOps & Cloud Interview Questions and Answers
30 advanced multiple-choice DevOps & Cloud interview questions, the deep end: internals, failure modes, and the design calls a senior engineer is expected to defend. They come from 30 bites in the DevOps & Cloud library, the hardest slice of the 538 DevOps & Cloud interview questions in the library. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
Infrastructure, containers, CI/CD, and cloud
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
A platform team notices their pipeline is consistently green, but lead time for changes has grown from hours to days. Which diagnostic approach best aligns with value stream thinking?
Show the answer
Answer: d · Decompose lead time into queue, active pipeline, and post-pipeline release intervals
Decomposing lead time reveals whether waste hides in pre-merge queues, slow green stages, or post-merge deployment friction. Investigating test flakiness is tempting but misguided because a green pipeline rules out build failures as the cause.
Read the full bite: Pipeline is green but lead time grows. Three areas to investigate?
Question 2 of 30
Why does an image built with Docker run correctly on a Kubernetes node that uses containerd and runc instead of the Docker daemon?
Show the answer
Answer: c · They all conform to OCI image and runtime specifications
Interoperability comes from shared OCI image and runtime specs, so any compliant tool can consume the same artifact; there is no rebuild or embedded Docker daemon involved.
Read the full bite: What is the OCI and why do its specs matter?
Question 3 of 30
What is the most realistic downside a team accepts when prioritizing strict portability across two cloud providers?
Show the answer
Answer: a · They forgo the deepest managed services and slow feature velocity
Portability forces a lowest-common-denominator design, sacrificing best-of-breed managed services and adding overhead that slows delivery. Faster shipping is the opposite of what multi-cloud abstraction produces.
Read the full bite: Designing for portability across two clouds
Question 4 of 30
Which scenario best illustrates a fundamental CI/CD difference between monoliths and microservices regarding blast radius and artifact indivisibility?
Show the answer
Answer: a · A microservice team deploys a signed container side-by-side with the previous version, while a monolith rollback requires reverting the entire application
This captures the core idea that monoliths produce a single indivisible artifact requiring full rollback, while microservices support independent side-by-side deployments with signed images. Option C reverses these architectures and promotes the shared-pipeline anti-pattern the card explicitly warns destroys team autonomy.
Read the full bite: How does your CI/CD strategy differ between monoliths and microservices?
Question 5 of 30
When bursting compute into the public cloud from on-prem, which factor most often becomes the real bottleneck?
Show the answer
Answer: d · Data gravity and the latency or cost of reaching on-prem data
Compute scales quickly, but the data the workload needs usually lives on-prem, so latency and egress dominate. Instance variety and quotas are minor and easily addressed by comparison.
Read the full bite: Hybrid cloud bursting from a VMware footprint
Question 6 of 30
Which approach best lets a risky feature launch despite a nearly exhausted error budget while upholding reliability?
Show the answer
Answer: d · Roll out behind a flag to a small canary, gate progression on live burn, and get explicit risk sign-off
Canary plus flag plus burn-gated rollout and documented risk acceptance contains blast radius while enabling the business. A flat refusal, a full rollout, or hiding errors all abandon reliability discipline.
Read the full bite: Risky launch with a near-empty error budget?
Question 7 of 30
Why can the host run strace against a container process even though strace is absent from the container image?
Show the answer
Answer: c · The container shares the host kernel, so the host PID can be traced directly
Containers are host processes under a shared kernel, so tracing the mapped host PID works from outside; nothing is injected into the image and strace is not hidden inside it.
Read the full bite: Trace a container process's syscalls from the host
Question 8 of 30
What fundamentally distinguishes the SRE response to a recurring high-volume alert from a traditional ops response?
Show the answer
Answer: a · SRE treats it as a defect to automate or eliminate so effort scales sublinearly with load
SRE applies software engineering to remove the recurring work entirely, breaking the link between load and headcount. Faster manual response, more dashboards, or more engineers are the linear-scaling ops pattern SRE avoids.
Read the full bite: SRE vs traditional ops on a recurring alert?
Question 9 of 30
Which characteristic of blue-green deployment most directly enables sub-minute rollback during a failed release?
Show the answer
Answer: c · The blue environment remains fully operational and ready to receive traffic after cutover.
The card states that because the old environment stays warm, rollback is a single traffic switch rather than a redeploy. Option A describes a canary release, which reuses the same infrastructure and gradually shifts traffic, making it a common misconception rather than true blue-green behavior.
Question 10 of 30
An upstream service breaches its SLO solely because a downstream dependency had an outage. How should a well-designed error budget policy handle the burn?
Show the answer
Answer: c · Attribute the burn to the downstream service that caused the failure
Correct attribution charges the responsible downstream team, creating proper incentives and shielding the upstream victim. Charging the upstream team, splitting blindly, or ignoring it all distort accountability.
Read the full bite: Error budget policy across dependent microservices?
Question 11 of 30
After force-pushing a Git history rewritten with git-filter-repo to remove leaked credentials, why must teammates delete their local clones and re-clone rather than pull?
Show the answer
Answer: a · A pull-and-push from their stale local branch would recontaminate the remote with the old commits containing the secret
The card explicitly warns that a teammate who pulls and then pushes from a stale local clone will reintroduce the old commits containing the secret back to the remote. While reflogs retain local history, the critical blast radius is recontamination of the shared repository, not a local merge issue.
Read the full bite: How do you fully remove leaked credentials from Git history?
Question 12 of 30
What is the main trade-off of placing latency-sensitive VMs in a tight cluster placement group?
Show the answer
Answer: d · It reduces fault isolation since instances share the same rack or zone
Packing instances physically close for low latency concentrates them, so a single hardware or zone failure can take down many at once. Placement groups do not cap instance size or disable enhanced networking.
Read the full bite: Optimizing low-latency VM-to-VM networking
Question 13 of 30
After adding USER app to a Dockerfile, the container starts but the app cannot write to its own directory. What was most likely missed?
Show the answer
Answer: c · The application files were not chowned to the app user, leaving them root-owned
Switching USER without changing file ownership leaves files owned by root, so the unprivileged user cannot write them; USER belongs before CMD and non-root users can write to directories they own.
Question 14 of 30
In a CI/CD context, why does merging an upstream dependency change naturally trigger the parent pipeline with git subtree but not with git submodules?
Show the answer
Answer: b · Subtree creates a new commit in the parent repository when merging the dependency, while submodules only update a pointer requiring a separate superproject commit.
Subtree creates an actual commit in the parent repository when a dependency is merged, which CI systems detect as a repository change, whereas submodules only update a pointer file and require an explicit superproject commit to register. Distractor C describes a real submodule checkout failure mode but confuses clone-time behavior with pipeline trigger semantics.
Read the full bite: Compare git submodules and git subtree for CI/CD
Question 15 of 30
In a Spot-based batch system, what mechanism ensures a task is reprocessed when its worker is reclaimed mid-job?
Show the answer
Answer: b · The queue's visibility timeout makes the unacknowledged task available again
If a worker is reclaimed before acknowledging, the message reappears after the visibility timeout for another worker to process. Metadata services, load balancers, and Reserved capacity do not provide this requeue guarantee.
Read the full bite: Cost-effective fault-tolerant batch processing
Question 16 of 30
Why is passing an NPM token via a Dockerfile ARG insecure even if you never reference it in the final stage?
Show the answer
Answer: a · The ARG value is recorded in image metadata and visible via docker history
ARG values persist in the image build history and can be inspected, so the secret leaks; BuildKit secret mounts avoid this by keeping the value in tmpfs only during a single RUN. The other claims are fabricated.
Read the full bite: Pass build-time secrets securely with BuildKit
Question 17 of 30
An engineer adds a user_id label to a request counter and Prometheus memory usage explodes. What is the underlying cause?
Show the answer
Answer: b · Each unique label combination becomes a separate stored time series
An unbounded label like user_id multiplies the number of unique label combinations, and Prometheus stores one series per combination, so series count and memory explode. Scrape interval changes sample volume per series, not the series count.
Read the full bite: What is high-cardinality data in Prometheus?
Question 18 of 30
Why can tail-based sampling guarantee retention of all error traces while head-based sampling cannot?
Show the answer
Answer: b · Head-based decides before the trace outcome is known; tail-based decides after the trace completes
The sampling timing is the key difference: head-based commits at trace start with no knowledge of the result, so it cannot prefer errors, whereas tail-based waits for completion and can apply outcome-based policies. Hardware and compression are irrelevant to this distinction.
Question 19 of 30
What is the main operational trade-off of using a distroless image instead of Alpine?
Show the answer
Answer: c · There is no shell or package manager, so debugging by exec is not possible
Removing the shell and package manager shrinks the attack surface but means you cannot exec a shell to debug; distroless is generally smaller, runs binaries fine, and does not require root.
Read the full bite: Distroless images: benefits and trade-offs
Question 20 of 30
Beyond reducing noise, what is the strongest argument for paging on symptoms rather than internal causes?
Show the answer
Answer: d · Symptom alerts catch unanticipated failure modes because any cause that hurts users surfaces as a symptom
Symptom alerts fire for any failure that degrades the user experience, including modes you never predicted, while cause alerts only cover anticipated conditions. Cost is minor, cause signals still belong on dashboards, and symptoms still need diagnosis.
Question 21 of 30
When integrating artifact signing into CI/CD, what is the primary security reason to move signing operations from the build runner to a remote KMS or HSM?
Show the answer
Answer: a · To ensure the private key never touches disk on ephemeral compute treated as untrusted
The card treats build runners as untrusted ephemeral infrastructure, so keeping the private key on a remote KMS or HSM prevents exfiltration if the runner is compromised. Option C is tempting but wrong because signature verification at deploy time must remain a hard gate regardless of how signing is performed.
Read the full bite: How would you integrate artifact signing into CI/CD and secure the keys?
Question 22 of 30
Why does writing millions of tiny objects under one sequential key prefix limit object-store throughput?
Show the answer
Answer: a · Each tiny write incurs request overhead and a single prefix can hotspot one partition
Throughput is bounded by request rate plus partition distribution, so per-object overhead and a single hot prefix throttle writes. Prefixes do not increase storage size, are not rejected, and small objects are not written twice.
Read the full bite: Maximizing object-store throughput for small files
Question 23 of 30
Two clients concurrently update the same object in a strongly consistent object store. What is the realistic outcome?
Show the answer
Answer: b · Last writer wins and one update is silently lost without coordination
Object stores replace whole objects with no built-in locking, so concurrent PUTs are last-writer-wins and an update is lost unless you use conditional writes. There is no automatic merge, lock, or reconciliation.
Question 24 of 30
Which approach delivers the lowest RTO and RPO for a stateful database when its availability zone fails?
Show the answer
Answer: d · A synchronous standby in another AZ that promotes on failure
A synchronous cross-AZ standby holds committed data and promotes quickly, giving near-zero RTO and RPO. Snapshots and backups lose recent writes and take time to restore, and a bigger same-AZ volume offers no AZ-failure protection.
Read the full bite: Block storage availability across AZ failure
Question 25 of 30
Three mandatory backends each have 99.95% availability. Why can the user-facing service not also reach 99.95% from these alone?
Show the answer
Answer: c · Because availabilities of serial dependencies multiply, yielding a lower combined number
For required dependencies in series the availabilities multiply, so 99.95% cubed is about 99.85%, already below target. Each critical dependency must be stricter, or you add redundancy and graceful degradation to break the serial chain.
Question 26 of 30
When you run docker compose up with no -f flags in a directory containing both compose.yaml and compose.override.yaml, what happens?
Show the answer
Answer: d · Compose merges compose.override.yaml on top of compose.yaml automatically
Compose auto-loads and deep-merges compose.override.yaml over the base. It does not ignore it (A) nor wholesale-replace the base (C); merging is the defined behavior, not an error (B).
Read the full bite: Structuring Compose files across environments
Question 27 of 30
Why does copying the full source before installing dependencies hurt build caching when only one code line changes?
Show the answer
Answer: b · The changed source busts the COPY layer, invalidating the later install layer too
A changed layer invalidates itself and every subsequent layer, so installing after copying source forces a reinstall. Caching is not disabled by COPY (A) and does apply to intermediate layers (D).
Question 28 of 30
The error budget is exhausted but the burn came from a single, now-resolved incident. What is the most constructive response to the launch request?
Show the answer
Answer: b · Present burn data and propose mitigations like a flagged canary with fast rollback to enable a controlled launch
A data-driven response distinguishes a resolved one-off from ongoing instability and offers risk-reducing mitigations so a controlled launch can proceed. A flat freeze ignores context, a full launch ignores the spent budget, and lowering the SLO games the policy.
Read the full bite: Launching a risky feature with no error budget left
Question 29 of 30
In an automated rollback pipeline triggered by a failed canary smoke test, which step must occur before redeploying the last known good release?
Show the answer
Answer: c · Shift traffic back to the stable baseline and freeze the canary progression
The card states that traffic isolation—freezing the canary and shifting traffic to the stable baseline—must happen before any rollback begins to minimize blast radius. Running health checks against the previous release is part of post-redeploy verification, while manual approval or in-place patches break the automated safety contract.
Read the full bite: Smoke test fails after canary deployment. Design the automated rollback.
Question 30 of 30
Which strategy best balances immediate pipeline unblocking with sustainable reduction of E2E flakiness at scale?
Show the answer
Answer: b · Baseline flakiness rates, auto-quarantine chronic offenders from presubmit, and fix root causes like concurrency
Baselining metrics and quarantining chronic offenders targets root causes while protecting presubmit integrity. Relying solely on retries masks flakiness, delays detection of real breakages, and never reduces the overall flakiness rate.
Read the full bite: How would you diagnose, report, and mitigate E2E flakiness at scale?
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.