DevOps Interview Questions and Answers (2026)

DevOps interview questions span the whole delivery pipeline — from what actually differs between continuous delivery and continuous deployment, to how you'd roll back a bad release safely. Here are the ones that come up most often.

1. What's the difference between CI, CD, and continuous deployment?

   Continuous Integration is the practice of frequently merging code into a shared branch, with an automated build and test suite running on every commit/PR to catch integration issues early — the goal is a codebase that's always in a buildable, tested state. Continuous Delivery extends this by automatically packaging and preparing every passing build for release (through staging environments), so the software is always in a deployable state, but the final push to production requires a manual approval gate. Continuous Deployment goes one step further and removes that manual gate entirely — every change that passes the pipeline is automatically deployed to production with no human intervention. The distinction between delivery and deployment often trips people up in interviews: delivery = "always ready to ship, human decides when," deployment = "ships itself." Most regulated or enterprise environments practice continuous delivery rather than full continuous deployment.

2. Compare blue-green and canary deployments.

   Blue-green deployment maintains two identical production environments — "blue" (currently live) and "green" (the new version) — and cuts over traffic all at once (typically via a load balancer or DNS switch) once the green environment is validated. Rollback is instant: just switch traffic back to blue. It requires running double the infrastructure during the transition and doesn't catch issues that only appear under partial real-world load. Canary deployment instead rolls the new version out to a small percentage of real traffic first (e.g., 5%), monitors error rates/latency/business metrics, and gradually increases the percentage if healthy, aborting and rolling back the canary slice if not. Canary catches issues with less blast radius and real production traffic patterns, but is more complex to implement (needs traffic-splitting infrastructure and good automated health signals) and takes longer to fully roll out. Blue-green favors simplicity and fast rollback; canary favors risk reduction on exposure.

3. Why does Infrastructure as Code matter?

   IaC (Terraform, Bicep, ARM, CloudFormation, Pulumi) defines infrastructure declaratively in version-controlled files instead of manual console clicks, which gives you reproducibility (spin up identical dev/test/prod environments from the same definition), auditability (every infra change is a reviewable diff/PR with a history), and drift detection (the tool can show and reconcile when live infrastructure has diverged from the declared state). It also makes disaster recovery realistic — rebuilding an entire environment from scratch becomes a pipeline run instead of days of manual reconstruction from memory or tribal knowledge.

   resource "azurerm_storage_account" "main" {
     name                     = "mystorageacct01"
     resource_group_name      = azurerm_resource_group.rg.name
     account_tier             = "Standard"
     account_replication_type = "LRS"
   }

   Without IaC, environments tend to drift apart over time through undocumented manual changes, causing "works in staging, breaks in prod" failures that are hard to diagnose.

4. Explain the basics of Docker and why containerization matters.

   Docker packages an application with its dependencies, runtime, and configuration into an image built from a Dockerfile, which runs as an isolated container sharing the host OS kernel (unlike a VM, which virtualizes the whole OS) — this makes containers far lighter-weight and faster to start than VMs. This solves the "works on my machine" problem by guaranteeing the same environment travels from a developer's laptop through CI to production.

   FROM node:20-alpine
   WORKDIR /app
   COPY package*.json ./
   RUN npm ci --production
   COPY . .
   CMD ["node", "server.js"]

   Containers are also the foundation for modern orchestration (Kubernetes, Container Apps) since they're a consistent, portable unit of deployment that can be scheduled, scaled, and health-checked uniformly regardless of what language or framework the app is written in.

5. Walk through what a typical CI/CD pipeline actually does, stage by stage.

   A pipeline typically triggers on a commit or PR and runs: (1) checkout — pull the source code; (2) build/compile — restore dependencies and compile/transpile the code; (3) unit tests — fast, isolated tests that fail the build immediately if broken; (4) static analysis/linting — code quality and security scanning (SAST); (5) package/containerize — produce a versioned artifact or container image; (6) push to artifact repository — store the immutable, versioned build output; (7) deploy to a lower environment (dev/staging) — often automatic; (8) integration/end-to-end tests against that environment; (9) manual approval gate (for delivery, not full deployment); (10) deploy to production, often with a progressive strategy (canary/blue-green); (11) post-deploy smoke tests and monitoring hooks to auto-rollback on failure.

   - stage: Build
     jobs:
       - job: BuildAndTest
         steps:
           - script: npm ci && npm test
           - script: docker build -t myapp:$(Build.BuildId) .

6. What rollback strategies exist, and how do you decide which to use?

   The fastest rollback is traffic-based — blue-green switch-back or reverting a canary's traffic weight to 0%, restoring service in seconds without touching the code. Redeploying the previous known-good artifact/image version from the artifact repository is the next-fastest and most common approach in typical pipelines, since immutable versioned builds make "redeploy version N-1" a trivial, low-risk operation. Database migrations complicate rollback the most — you need migrations to be backward-compatible (expand/contract pattern: add new columns/tables without removing old ones until the new code is fully rolled out and stable) so a code rollback doesn't break against a forward-migrated schema. Feature flags offer the least disruptive rollback of all — killing a flag to disable a broken feature without any deployment at all. The right strategy depends on blast radius and speed needed: flag kill-switch first if available, then traffic-based, then artifact redeploy, with schema rollback treated as a last resort requiring careful planning.

7. How should secrets be managed in a CI/CD pipeline?

   Secrets (API keys, connection strings, credentials) should never be committed to source control or hardcoded in pipeline YAML — instead they belong in a dedicated secrets manager (Azure Key Vault, HashiCorp Vault, AWS Secrets Manager) or the CI platform's native secret store (GitHub Actions secrets, Azure DevOps variable groups linked to Key Vault), injected into the pipeline at runtime as masked environment variables. Pipelines should use short-lived, scoped credentials — ideally OIDC-based federated identity (e.g., GitHub Actions to Azure via workload identity federation) instead of long-lived service principal secrets, so there's no static credential to leak or rotate at all.

   - name: Deploy
     env:
       AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
     run: az deployment group create ...

   Secrets should also be scoped to least privilege per environment/pipeline and rotated regularly, with access audited.

8. What's the difference between metrics, logs, and traces in observability?

   Metrics are numeric time-series data (CPU %, request rate, error count, latency percentiles) that are cheap to store and great for dashboards, alerting thresholds, and spotting trends over time, but they don't tell you *why* something happened. Logs are discrete, timestamped event records (structured or unstructured) capturing detailed context about specific occurrences — an exception stack trace, a failed validation — and are the go-to for root-cause investigation once you know roughly where to look. Traces follow a single request's journey across multiple services/hops in a distributed system, showing where time was spent at each step (a span per hop), which is essential in microservices architectures for diagnosing "which downstream call is actually slow" when a single logical operation touches five services. The three are complementary: metrics tell you *something* is wrong and roughly when, traces narrow down *where* in the call chain, and logs tell you *exactly why* at that specific point.

9. What is GitOps and how does it differ from a traditional push-based deployment pipeline?

   GitOps treats a Git repository as the single source of truth for both application and infrastructure desired state, with an in-cluster or in-environment agent (e.g., Argo CD, Flux for Kubernetes) continuously reconciling the live environment to match what's declared in Git, pulling changes rather than the pipeline pushing them. This differs from a traditional CI/CD pipeline where a pipeline job actively pushes changes out to the target environment using credentials it holds for that environment. GitOps advantages: the pull-based agent needs no external write credentials into the environment (reducing attack surface), drift is continuously detected and auto-corrected, and every change to the live state has a corresponding Git commit — giving a complete audit trail and trivial rollback via git revert. It's most associated with Kubernetes but the underlying principle (declarative desired state + continuous reconciliation) applies more broadly.

10. What are feature flags and why are they valuable in a DevOps workflow?

    Feature flags (feature toggles) are conditional switches in code that let you enable or disable functionality at runtime without a deployment, decoupling code deployment from feature release. This enables trunk-based development — merging incomplete features behind a flag directly to main without breaking production — progressive rollouts (enabling a feature for 1% of users, then 10%, then 100%, similar to canary but at the feature level rather than infrastructure level), and instant kill-switches if a feature misbehaves, all without needing to redeploy or roll back a build. They also enable A/B testing and targeted release to specific user segments (internal users, beta customers). The tradeoff is added code complexity (conditional branches) and the discipline required to clean up stale flags — flag debt accumulates quickly if old flags aren't removed once a feature is fully rolled out and stable.

11. What is an artifact repository and why is it a distinct concept from source control?

    An artifact repository (Azure Artifacts, JFrog Artifactory, Nexus, container registries like ACR/Docker Hub, npm/NuGet feeds) stores the immutable, versioned *build outputs* of your pipeline — compiled binaries, container images, packages — as opposed to source control, which stores human-authored source code changes. Separating the two matters because deployments should always be built once and promoted unchanged through environments (dev to staging to prod) rather than rebuilt from source at each stage, which guarantees what you tested is bit-for-bit what you ship — rebuilding at each stage risks subtle differences from dependency resolution or environment drift. Artifact repositories also provide versioning/immutability guarantees, vulnerability scanning integration, and retention policies. A pipeline typically pushes a uniquely tagged image like myapp:1.4.2-a1b2c3d (semantic version plus commit SHA) once, then every environment pulls that exact same tag.

12. At a high level, what is the twelve-factor app methodology?

    The twelve-factor app is a set of principles for building cloud-native, horizontally scalable SaaS applications, originating from Heroku's engineering practices. Core ideas include: one codebase tracked in version control with many deploys; explicit, declared dependencies (no relying on system-wide packages); configuration stored in environment variables, not in code; treating backing services (databases, queues) as attached resources swappable without code changes; strict separation of build, release, and run stages; running the app as one or more stateless processes (no local session state, enabling horizontal scaling); exposing services via port binding rather than relying on a runtime-injected web server; scaling out via the process model rather than threading tricks within one process; fast startup and graceful shutdown (disposability); keeping dev/staging/prod as similar as possible; treating logs as event streams written to stdout rather than managed by the app; and running admin/management tasks as one-off processes. It's a foundational checklist for whether an app is actually ready to run well in containerized, horizontally scaled cloud environments.

More prep guides on the AI Interview Bot blog.