DevOps Interview Questions for Cloud Engineers

DevOps interviews are distinct from pure cloud engineering interviews, even though the two roles overlap significantly. A cloud engineering interview centres on infrastructure design and cloud service knowledge. A DevOps interview centres on the delivery pipeline: how code moves from development to production, how systems stay reliable, and how teams automate operational work.

This page covers the DevOps interview questions that come up most often, what interviewers are actually looking for behind each one, and what separates candidates who stand out from those who just list tools.

How DevOps Interviews Differ from Cloud Engineering Interviews#

In a cloud engineering interview, you might be asked to design a VPC or explain IAM. In a DevOps interview, those topics might appear briefly, but the bulk of the questions focus on:

• How CI/CD pipelines are built and maintained
• How teams ship changes safely and frequently
• How infrastructure is managed as code
• How failures are detected and responded to
• What the actual workflows look like when something goes wrong in production

The practical difference: a cloud engineer who has only ever clicked through the console will struggle with DevOps questions. A DevOps practitioner without depth in cloud fundamentals will struggle with architecture questions. Most modern roles require both, but the emphasis varies.

Interviewers for DevOps roles also weight operational thinking heavily. They want people who have dealt with outages, investigated failures, and built systems that are observable and recoverable. Candidates who’ve only deployed things — but never had to debug them under pressure — have a noticeably different profile.

CI/CD Pipeline Questions#

“What is the difference between continuous integration, continuous delivery, and continuous deployment?” Probing for: Precise definitions, not vague synonyms. CI means code is integrated and tested frequently (at least daily). Continuous delivery means the codebase is always in a deployable state, but humans decide when to deploy. Continuous deployment means every passing build is automatically deployed to production without human approval.

“Walk me through a CI/CD pipeline you’ve built or significantly worked on. What did each stage do?” Probing for: Real experience. Candidates with actual pipeline experience will describe specific stages — code checkout, dependency installation, unit tests, static analysis, Docker build, image push, deployment to staging, integration tests, promotion to production. Candidates who haven’t built pipelines give vague answers that describe the concept, not the implementation.

“How do you handle a failed pipeline in production? Who gets notified, and what happens next?” Probing for: Operational maturity. Strong answers cover: notification mechanisms (Slack, PagerDuty, email), runbooks or escalation paths, rollback strategies, and how failed deployments are investigated. Weak answers say “the developer fixes it” without describing the mechanism.

“What is a deployment strategy? Compare blue-green, canary, and rolling deployments.” Probing for: Understanding of trade-offs, not just names. Blue-green swaps two identical environments — zero-downtime but doubles infrastructure cost and requires clean state. Canary gradually shifts traffic to the new version — slower but limits blast radius. Rolling replaces instances incrementally — resource-efficient but the old and new versions run simultaneously, which can cause schema or API compatibility issues.

“How do you test a pipeline change without breaking the production pipeline?” Probing for: Practical experience. Good answers mention feature branches, separate pipeline configurations for non-main branches, pipeline-as-code that can be validated before merge, and staging environments.

“What are the security risks in a CI/CD pipeline, and how do you mitigate them?” Probing for: Security awareness. Risks include: secrets in environment variables or logs, third-party action supply chain attacks (GitHub Actions), overly broad permissions for the pipeline service account, and access to production credentials from development branches. Mitigations: secrets managers, scoped credentials, branch protection, and dependency pinning.

Docker and Container Questions#

“What is the difference between a Docker image and a Docker container?” Probing for: Clear conceptual grounding. An image is a read-only template. A container is a running instance of an image. This is a baseline check.

“What is a multi-stage Docker build, and why would you use one?” Probing for: Awareness of image size and security. Multi-stage builds allow you to compile or build in a larger image, then copy only the artefacts into a minimal runtime image. This reduces the attack surface and image size — a production best practice.

“What happens if you put secrets in a Dockerfile ENV instruction?” Probing for: Security instinct. Secrets in ENV are visible in the image history and anyone who pulls the image can read them with docker inspect. The correct approach is to inject secrets at runtime (environment variables passed at run time, a secrets manager, or Docker secrets for Swarm).

“How do you make a Docker image build reproducible?” Probing for: Pin base image versions by digest, pin dependency versions, use .dockerignore to exclude irrelevant files, and avoid instructions that make network calls at build time when possible.

Terraform and Infrastructure as Code Questions#

“What is Terraform state, and why does it exist?” Probing for: Understanding of how Terraform tracks what it has deployed. State maps Terraform resources to real-world infrastructure. Without it, Terraform can’t determine what changes to make. State should be stored remotely (S3 + DynamoDB for locking, GCS, or Terraform Cloud) and not committed to version control.

“What happens if two engineers run terraform apply at the same time?” Probing for: Awareness of state locking. Without locking, concurrent applies can corrupt state. Remote backends with locking (DynamoDB for AWS) prevent this. Candidates who haven’t thought about this often haven’t worked with Terraform in a team context.

“What is a Terraform module, and when should you create one?” Probing for: Practical module design judgment. Modules make sense when the same infrastructure pattern is reused across environments or teams. Creating a module for a single use case adds complexity without value. The question is really: do you modularise appropriately or reflexively?

“What is terraform plan, and why should you always review it before applying?” Probing for: This feels basic but reveals discipline. Plans can contain surprises — resource replacements instead of in-place updates, drift from manual changes, or changes to resources you didn’t intend to touch. Engineers who skip the plan review create incidents.

“How would you manage different environments (dev, staging, production) in Terraform without code duplication?” Probing for: Awareness of workspace patterns, separate state files, and variable-based configuration. Strong answers describe a specific approach they’ve used with reasoning. Weak answers say “use Terraform workspaces” without discussing the trade-offs (workspaces share module code but not state — useful for similar environments, but not always the best fit for highly differentiated environments).

“What is Terraform drift, and how do you handle it?” Probing for: Drift occurs when real infrastructure diverges from Terraform state due to manual changes. terraform plan will show drift. Resolution involves either importing the change into state or reconciling the real infrastructure back to the desired state. The operational discipline answer: prevent drift by ensuring all changes go through Terraform.

Monitoring and Observability Questions#

“What is the difference between monitoring and observability?” Probing for: Conceptual distinction. Monitoring is tracking predefined metrics and alerting when thresholds are crossed. Observability is the property of a system that lets you understand its internal state from its outputs — especially useful for debugging novel failures that weren’t anticipated when metrics were defined. Logs, traces, and metrics together enable observability.

“You get paged at 2am because an error rate alert has fired. Walk me through how you investigate.” Probing for: Methodical thinking under pressure. A strong answer: confirm the alert is real, assess impact (how many users affected, is the service down or degraded), check recent deployments or changes, look at error logs and traces for patterns, isolate the failing component, mitigate (rollback or traffic routing) before investigating root cause. Weak answers jump straight to root cause hunting without establishing scope.

“What are the four golden signals? Why are they useful?” Probing for: Latency, traffic, errors, and saturation (from the SRE book). They provide a consistent framework for monitoring any service, regardless of implementation.

“How would you set up alerting that reduces false positives without missing real incidents?” Probing for: Alerting philosophy. Alert on symptoms (user-visible impact), not causes. Use multi-window burn rate alerts rather than simple threshold breaches for SLO-based alerting. Tune thresholds over time. Avoid alert fatigue — an on-call team that ignores alerts because most are noise eventually misses a real one.

Git Workflow Questions#

“What is the difference between a merge commit and a rebase? When would you use each?” Probing for: Understanding the practical difference in history. Merge preserves branch history; rebase replays commits onto the target branch to produce a linear history. Teams often prefer rebasing feature branches before merge to keep main clean, but rebasing shared branches is dangerous. The question probes whether the candidate understands why, not just the mechanics.

“What is trunk-based development, and how does it differ from Gitflow?” Probing for: Trunk-based development: everyone commits to main frequently (at least daily), with short-lived feature branches. Gitflow: longer-lived release, develop, hotfix, and feature branches with a defined branching model. Trunk-based suits teams deploying frequently; Gitflow suits teams with scheduled releases. Neither is universally correct.

“How would you handle a hotfix that needs to go to production immediately while your main branch has unreleased work in it?” Probing for: Practical branching strategy under pressure. Strong answers describe: branching from the last production release tag, fixing there, deploying, then cherry-picking or merging back. Weaker answers either describe reverting all unreleased work or deploying everything including the unreleased changes.

Scenario: Production Deployment Pipeline Failing#

“Your CI/CD pipeline has been working fine for months. Today, a deployment failed in production — the application is returning 500 errors for 20% of requests. Walk me through how you handle this.”

A strong answer:

1. Assess scope immediately. Is it 20% of all users or a specific endpoint? Is it worsening? Check dashboards for error rate trends, latency spikes, and which instances are affected.

2. Check what changed. Recent deployments, configuration changes, infrastructure changes. The most common cause of production incidents is something that changed.

3. Mitigate before investigating. If a rollback is possible and safe, do it. Restoring service takes priority over understanding root cause.

4. Gather evidence. Pull logs from the failing period. Look at traces for failing requests. Check resource saturation (CPU, memory, connection pool exhaustion).

5. Fix forward or roll back. If the fix is simple and low-risk, deploy the fix. If it’s complex, roll back and investigate in staging.

6. Write a post-mortem. Document what happened, when, what the impact was, what fixed it, and what changes prevent it from recurring.

What the interviewer is watching for: Do you stabilise first or investigate first? (Stabilise.) Do you blame or problem-solve? (Problem-solve.) Do you work in a structured way or frantically? (Structured.)

What Makes a DevOps Candidate Stand Out#

The weakest DevOps candidates have the same profile: they can list tools (Jenkins, GitLab CI, ArgoCD, Terraform, Prometheus) but struggle to explain why specific decisions were made or what trade-offs were involved.

Strong candidates demonstrate:

They’ve dealt with things going wrong. Every production system eventually fails. Candidates who can describe a real outage they helped resolve — what broke, how they found it, what they changed — are more convincing than candidates who’ve only deployed working software.

They understand the “why” behind the tools. Terraform exists because manual infrastructure is error-prone and hard to reproduce. CI/CD exists because infrequent deployments create larger, riskier changes. Kubernetes exists because container orchestration at scale is hard to do manually. Candidates who understand these underlying reasons can adapt when the specific tool changes.

They think about the team, not just the technology. DevOps is as much about processes and feedback loops as tooling. Candidates who can describe how they’ve improved deployment confidence for a team — by adding tests, building visibility into the pipeline, reducing deployment time — demonstrate real impact.

Common Weak Points in DevOps Candidates#

Testing as an afterthought. Many candidates describe pipelines that deploy without meaningful automated testing. Interviewers at mature organisations notice.

No experience with production incidents. If you’ve only worked in environments where things rarely break or you weren’t involved in incident response, prepare for this gap. Being honest is better than fabricating experience.

Surface-level Kubernetes knowledge. Many candidates say they “know Kubernetes” but can’t explain pod scheduling, resource limits, or how services route traffic. If Kubernetes is on your CV, expect to be tested on it properly.

Monitoring as an afterthought. Proposing architectures with no consideration of how you’d know if they were healthy is a red flag. Observability should be part of design, not an add-on.