DevOps & CI/CD Interview Questions: 50 Questions with Answers

DevOps interviews look like tool trivia from the outside: Jenkins, GitHub Actions, Terraform, Kubernetes, Prometheus. In practice, good interviewers use the tools as a way into one question: can this person change production safely? That means fast feedback on every commit, artifacts you can trust, deployments that limit damage, infrastructure you can recreate, and monitoring that tells you something is wrong before customers do.

The fifty questions below follow the path of a change from commit to production. Examples use GitHub Actions, Terraform, Kubernetes and Prometheus because they are the most common in Indian product companies and GCCs today, but each answer explains the concept so it transfers to GitLab CI, Jenkins, CloudFormation or Datadog. For containers and Kubernetes in depth, pair this with our Docker and Kubernetes interview questions.

How DevOps and CI/CD Are Interviewed

CI/CD Fundamentals: Questions 1-10

Q1. What is DevOps?

DevOps is a set of practices and a culture that brings development and operations together so teams can deliver changes quickly and reliably. The practices include automation of build, test and deployment, infrastructure as code, monitoring and fast feedback, shared ownership of production ("you build it, you run it"), and blameless learning from incidents. It is not a job title or a tool, though "DevOps engineer" is commonly used for engineers who build these platforms.

Q2. CI vs continuous delivery vs continuous deployment?

Regulated environments (banking, payments) often stop at continuous delivery with an approval gate, which is perfectly valid.

Q3. What are the stages of a typical CI/CD pipeline?

1. Trigger: push or pull request.
2. Build: compile, resolve dependencies (cached).
3. Fast tests: lint, unit tests, static analysis.
4. Security checks: dependency vulnerabilities, secret scanning, SAST.
5. Package: build an immutable artifact, usually a container image tagged with the commit SHA, and push it to a registry.
6. Deploy to staging and run integration, contract and smoke tests.
7. Deploy to production progressively (canary or rolling) with automated health checks.
8. Verify and notify: compare metrics, roll back automatically on failure, announce the release.

Q4. What is "build once, deploy many"?

Build the artifact a single time and promote the same artifact through staging and production, injecting environment-specific configuration at deploy time. Rebuilding per environment risks shipping something different from what was tested (a dependency changed, a different compiler flag). Tag images with the immutable commit SHA, not just latest.

Q5. Trunk-based development vs GitFlow?

Trunk-based development: everyone merges small changes into main at least daily, using short-lived branches and feature flags for unfinished work. It suits CI/CD and frequent deploys. GitFlow: long-lived develop, release and hotfix branches, suited to versioned products with scheduled releases (installed software, mobile apps), but it creates merge pain and delays integration. Most product companies deploying web services multiple times a day use trunk-based development. Git details are covered in our Git interview questions.

Q6. What is the test pyramid and how does it shape a pipeline?

Many fast, cheap unit tests at the base; fewer integration and contract tests in the middle; very few slow end-to-end UI tests at the top. In a pipeline, run the base on every commit within minutes, and the upper layers after packaging or on staging. A pipeline dominated by end-to-end tests becomes slow and flaky, and developers start ignoring it.

Q7. What is an artifact repository and why use one?

A store for versioned build outputs: container registries (ECR, GCR/Artifact Registry, Docker Hub, Harbor), and package repositories (Nexus, Artifactory, GitHub Packages) for JARs and npm packages. It provides immutability, traceability from deployment to commit, caching of third-party dependencies, and a place to enforce scanning and retention policies.

Q8. How should artifacts be versioned?

For services deployed continuously, the commit SHA (optionally with a build number) is the most reliable identifier. For libraries and APIs consumed by others, use semantic versioning: MAJOR for breaking changes, MINOR for compatible features, PATCH for fixes. Many teams tag images with both the SHA and a human-friendly version.

Q9. What makes a good CI pipeline?

Fast (developers get feedback on a pull request within about 10 minutes), reliable (no flaky failures that teach people to click "re-run"), reproducible (pinned tool versions, hermetic builds), secure (least-privilege credentials), and informative (clear failure messages and test reports). Interviewers will often follow up with "how would you speed up a 40-minute pipeline?" (see Q16).

Q10. What are DORA metrics?

From the DevOps Research and Assessment programme, these four metrics measure both throughput and stability. The research's key finding is that the two are not a trade-off: teams that deploy more often in small batches also tend to fail less and recover faster. Use them to guide improvement, not to rank individuals.

Building Pipelines: Questions 11-18

Q11. Write a CI/CD pipeline for a containerized service.

name: orders-service

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write          # lets the job request an OIDC token for AWS

concurrency:
  group: orders-${{ github.ref }}
  cancel-in-progress: true # a newer push cancels the older run on the same branch

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "21"
          cache: maven
      - name: Unit and integration tests
        run: mvn -B verify

  build-and-push:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.meta.outputs.image }}
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-ci-orders
          aws-region: ap-south-1
      - id: ecr
        uses: aws-actions/amazon-ecr-login@v2
      - id: meta
        run: echo "image=${{ steps.ecr.outputs.registry }}/orders-service:${{ github.sha }}" >> "$GITHUB_OUTPUT"
      - name: Build and push image
        run: |
          docker build -t "${{ steps.meta.outputs.image }}" .
          docker push "${{ steps.meta.outputs.image }}"

  deploy-staging:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: echo "deploy ${{ needs.build-and-push.outputs.image }} to staging, then run smoke tests"

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production   # environment protection rules can require approval
    steps:
      - run: echo "progressive rollout of ${{ needs.build-and-push.outputs.image }}"

Things to point out: tests gate the build; images are tagged with the commit SHA; AWS access uses OIDC with a role instead of stored access keys; concurrency avoids wasted runs; and production uses a protected environment, which can require approval (continuous delivery) or be automatic (continuous deployment). The deploy steps are placeholders for your deployment tool, such as updating a Helm release or a GitOps repository.

Q12. Show the same idea in Jenkins.

pipeline {
  agent { label 'docker' }
  options { timeout(time: 30, unit: 'MINUTES'); disableConcurrentBuilds() }
  environment { IMAGE = "registry.example.com/orders-service:${env.GIT_COMMIT}" }
  stages {
    stage('Test') {
      steps { sh 'mvn -B verify' }
      post { always { junit 'target/surefire-reports/*.xml' } }
    }
    stage('Build image') {
      when { branch 'main' }
      steps {
        sh 'docker build -t $IMAGE .'
        withCredentials([usernamePassword(credentialsId: 'registry', usernameVariable: 'U', passwordVariable: 'P')]) {
          sh 'echo "$P" | docker login registry.example.com -u "$U" --password-stdin'
          sh 'docker push $IMAGE'
        }
      }
    }
    stage('Deploy to production') {
      when { branch 'main' }
      steps {
        input message: 'Deploy to production?'
        sh './deploy.sh production $IMAGE'
      }
    }
  }
}

Jenkins remains common in Indian enterprises and service companies. Know declarative vs scripted pipelines, agents, shared libraries for reuse across teams, and the credentials plugin. A common criticism is the operational burden of maintaining Jenkins controllers and plugins, which pushes teams towards hosted CI.

Q13. How do you handle database migrations in CI/CD?

Run migrations as an explicit pipeline step (Flyway, Liquibase, Alembic, Django migrations) before or alongside the deploy, and make them backward compatible using the expand-and-contract pattern: first add new columns or tables (expand), deploy code that writes to both old and new, backfill, switch reads, and only later remove the old structure (contract). This way, old and new versions of the application can run at the same time during a rolling or canary deploy, and you can roll back the code without rolling back the schema.

Q14. How do you deal with flaky tests?

Measure them first: track per-test failure rates across runs. Quarantine known flaky tests into a non-blocking job with an owner and a deadline, rather than letting them fail the main pipeline or deleting them. Fix root causes: shared state between tests, time and ordering dependencies, real network calls, and fixed sleeps instead of waiting for a condition. Automatic retries hide flakiness and should be limited and visible.

Q15. What is a monorepo CI challenge and how is it handled?

In a monorepo, running every test for every change is wasteful. Use path-based triggers or a build system with dependency awareness (Bazel, Nx, Turborepo, Gradle) to build and test only affected projects, with remote caching so unchanged targets are reused. Polyrepos avoid this but make cross-service changes and shared library upgrades harder.

Q16. A pipeline takes 40 minutes. How would you speed it up?

1. Measure the time per stage; do not guess.
2. Cache dependencies (Maven, npm, pip) and Docker layers; order the Dockerfile so dependency installation comes before copying source code.
3. Parallelize independent jobs and shard test suites across runners.
4. Run only what changed in monorepos.
5. Move slow suites (full end-to-end, performance) off the pull-request path to post-merge or nightly, keeping a small smoke set on PRs.
6. Use bigger or self-hosted runners for heavy builds when the cost is justified.

Q17. What is a multi-stage Docker build and why use it in CI?

A Dockerfile with a build stage containing compilers and dependencies, and a final stage that copies only the built artifact into a slim runtime image. Smaller images pull faster during deploys and have fewer vulnerabilities to patch. Also run as a non-root user, pin base image versions (or digests), and use .dockerignore.

FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -B dependency:go-offline          # cached unless pom.xml changes
COPY src ./src
RUN mvn -B package -DskipTests

FROM eclipse-temurin:21-jre
WORKDIR /app
RUN useradd --system appuser
COPY --from=build /app/target/orders-service.jar app.jar
USER appuser
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Q18. How do you promote between environments?

Use the same artifact (Q4) with environment-specific configuration from a config store, Kubernetes ConfigMaps and Secrets, or Helm values per environment. Promotion is gated by automated checks (tests and health metrics in staging) and, if required, approvals. With GitOps, promotion is a pull request that updates the image tag in the production environment's configuration repository (Q36).

Deployment Strategies and Rollbacks: Questions 19-28

Q19. Compare the main deployment strategies.

Q20. Blue-green vs canary: when do you choose each?

Blue-green is simple to reason about and gives instant rollback, and it fits when you can afford duplicate capacity and want to test the full new environment before switching (for example, a monolith or a release with infrastructure changes). Canary limits damage: a bug that only appears under real traffic affects 1% to 5% of users before automated analysis stops it. It fits high-traffic services with good metrics, like a payments API during peak hours. Many teams combine them: canary analysis on top of a blue-green style traffic switch.

Q21. How does a Kubernetes rolling update work?

spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%        # up to 3 extra pods during the update (rounded up)
      maxUnavailable: 0    # never drop below 10 ready pods
  minReadySeconds: 10
  template:
    spec:
      containers:
        - name: orders
          image: registry.example.com/orders-service:3f9c2ab
          readinessProbe:
            httpGet: { path: /health/ready, port: 8080 }
            periodSeconds: 5

Kubernetes creates new pods up to maxSurge, waits for them to pass the readiness probe, then terminates old pods, keeping at least replicas - maxUnavailable ready. Without a meaningful readiness probe, traffic reaches pods that are not ready. Roll back with kubectl rollout undo deployment/orders. Graceful shutdown also matters: handle SIGTERM, stop accepting new requests, and finish in-flight ones within terminationGracePeriodSeconds.

Q22. How do you automate canary analysis?

Use a progressive delivery tool (Argo Rollouts, Flagger, Spinnaker, or cloud-native options) with a traffic router (service mesh or ingress) to shift traffic in steps such as 5%, 25%, 50%, 100%, pausing between steps. At each step, compare the canary's error rate and latency against the stable version using queries to your metrics system, and abort automatically if they breach thresholds. Choose metrics that reflect user experience, and make sure the canary receives enough traffic for the comparison to be statistically meaningful.

Q23. How do feature flags fit into CI/CD?

Flags decouple deploy (code reaches production) from release (users see the feature). Unfinished features can merge to main behind a disabled flag, which enables trunk-based development. Flags allow gradual rollout to internal users, then a percentage, then everyone, and act as kill switches during incidents. Risks: combinatorial testing and stale flags; remove flags once a feature is fully rolled out.

Q24. What should trigger an automatic rollback?

Failed health or readiness checks, error rate above a threshold relative to baseline, latency percentiles (p95, p99) above an SLO, or business signals such as a drop in successful payments or checkouts. Business metrics often catch problems technical metrics miss, for example a UI change that breaks a button without any server errors.

Q25. What if a deployment cannot simply be rolled back?

Irreversible changes include destructive schema migrations, data transformations, and changed message formats already consumed by other services. Prevent the situation: expand-and-contract migrations (Q13), backward and forward compatible message formats (add fields, do not rename), versioned APIs, and feature flags for behaviour changes. When rollback is impossible, roll forward with a fix, which is why fast pipelines matter.

Q26. What is zero-downtime deployment and what is needed for it?

Users see no errors or unavailability while versions change. Requirements: more than one instance behind a load balancer; readiness probes; connection draining and graceful shutdown; backward compatible database and API changes; sessions stored outside instances (Redis, signed tokens) or sticky sessions handled carefully; and warm-up for services that are slow when cold (JVM JIT, caches).

Q27. What is a deployment freeze and when is it justified?

A period when production changes are restricted, for example during a major sale event or festive season peak at an e-commerce company, or month-end processing at a bank. Freezes reduce risk during high-stakes windows, but long or frequent freezes cause big risky batches of changes afterwards. Mature teams keep freezes short and still allow emergency fixes through an expedited process.

Q28. How do you deploy safely across multiple regions?

Deploy region by region (or cell by cell), starting with the region with the least traffic or an internal canary region, with bake time and automated checks between waves. A bad change then affects one region, and traffic can fail over. Keep configuration changes on the same progressive path, since configuration pushes cause many large outages.

Infrastructure as Code and Terraform: Questions 29-37

Q29. What is infrastructure as code and why use it?

Defining infrastructure (networks, servers, databases, load balancers, IAM) in version-controlled files that tools apply automatically, instead of clicking through a console. Benefits: reproducible environments, code review for infrastructure changes, an audit trail in Git, disaster recovery by re-applying, and no undocumented "snowflake" servers.

Q30. Declarative vs imperative IaC; Terraform vs Ansible?

Declarative tools (Terraform, CloudFormation, Kubernetes manifests) describe the desired end state, and the tool works out the changes. Imperative approaches (scripts) describe steps. Terraform is mainly for provisioning cloud resources. Ansible is mainly for configuration management of machines (installing packages, editing config files) over SSH, without agents, and is procedural in execution though its modules aim to be idempotent. Teams often use Terraform to create infrastructure and Ansible or container images to configure what runs on it.

Q31. What is Terraform state and why is it critical?

The state file maps resources in your configuration to real resources (IDs, attributes) and lets Terraform compute the diff between desired and actual. Without it, Terraform does not know what it manages. Store it in a remote backend (S3, GCS, Azure Blob, Terraform Cloud) with encryption, versioning and locking, because state can contain secrets and two concurrent applies can corrupt it. Never edit state by hand; use terraform state mv, rm or import.

terraform {
  required_version = ">= 1.6"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"            # pin a major version; upgrade deliberately
    }
  }

  backend "s3" {
    bucket         = "acme-terraform-state"
    key            = "prod/orders/terraform.tfstate"
    region         = "ap-south-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"  # newer Terraform versions can lock with use_lockfile = true instead
  }
}

provider "aws" {
  region = var.region
}

variable "region" {
  type    = string
  default = "ap-south-1"
}

variable "environment" {
  type = string
}

module "orders_db" {
  source            = "./modules/postgres"
  name              = "orders-${var.environment}"
  instance_class    = var.environment == "prod" ? "db.r6g.large" : "db.t4g.medium"
  multi_az          = var.environment == "prod"
  deletion_protection = true
}

output "orders_db_endpoint" {
  value = module.orders_db.endpoint
}

Q32. Walk through the Terraform workflow.

terraform init downloads providers and configures the backend. terraform fmt and validate check style and syntax. terraform plan compares configuration with state and real infrastructure and shows what will be created, changed or destroyed. terraform apply executes the plan (ideally a saved plan file, so what was reviewed is exactly what is applied). In CI, run plan on pull requests and post the output for review, and run apply only after merge, with locking.

Q33. What is drift and how do you handle it?

Drift is when real infrastructure no longer matches the code, usually because someone changed it in the console. terraform plan reveals drift as unexpected changes. Handle it by either importing the change into code (if it should stay) or letting Terraform revert it. Prevent it with restricted console write access, scheduled drift-detection plans that alert, and a culture that every change goes through code.

Q34. What are Terraform modules, and how do you structure multiple environments?

Modules are reusable units of configuration with inputs and outputs, such as a standard service module that creates a load balancer, autoscaling group and alarms. For environments, the common approaches are a separate directory per environment that calls shared modules with different variables (clear and explicit, with separate state per environment), or workspaces (one configuration, several states; convenient but easy to apply to the wrong workspace). Tools such as Terragrunt reduce repetition across many environments and accounts.

Q35. Terraform plan shows it will destroy and recreate the production database. What do you do?

Stop and read why: the plan marks attributes that "force replacement", such as changing the identifier or certain storage settings. Options: revert that attribute change; use a lifecycle rule (prevent_destroy = true as a safety net, or ignore_changes for attributes managed elsewhere); if a resource was only renamed in code, use a moved block or terraform state mv so Terraform knows it is the same resource; and plan an actual migration with snapshot and restore if replacement is truly required. Also enable deletion protection on databases at the cloud provider level.

Q36. What is GitOps?

GitOps uses a Git repository as the single source of truth for the desired state of deployments, and an agent in the cluster (Argo CD or Flux) continuously reconciles the cluster to match Git. Deploying means merging a pull request that changes an image tag or manifest; rolling back means reverting a commit. Benefits: an audit trail, easy rollbacks, drift correction, and CI does not need cluster credentials, because the cluster pulls changes instead of CI pushing them.

Q37. How do you manage Kubernetes manifests across environments?

Helm packages manifests as charts with templates and per-environment values files, and manages releases with rollback. Kustomize uses a base plus overlays that patch it, without templating. Both work well with GitOps. Keep secrets out of plain manifests (Q40) and validate rendered manifests in CI with schema and policy checks.

Security and Secrets in CI/CD: Questions 38-42

Q38. How do you give a pipeline cloud access without storing credentials?

Use OIDC federation: the CI system issues a short-lived signed identity token for the job, and the cloud provider (AWS IAM, GCP Workload Identity Federation, Azure) exchanges it for temporary credentials for a specific role, restricted to a particular repository and branch. No long-lived access keys sit in CI secrets to be leaked. This is shown in Q11 with id-token: write and role-to-assume.

Q39. What is DevSecOps, and which scans belong in a pipeline?

Building security into every stage instead of a final audit. Typical checks: secret scanning (stop committed keys), SCA (software composition analysis of dependencies for known vulnerabilities), SAST (static analysis of your code), container image scanning (OS packages in images), IaC scanning (misconfigurations like public buckets), and DAST (testing the running app in staging). Fail builds on critical findings, triage the rest, and generate an SBOM (software bill of materials) so you can answer "are we affected?" quickly when a new vulnerability is announced.

Q40. How should application secrets be managed?

Keep them in a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) and inject them at runtime, for example through the External Secrets Operator or a CSI driver on Kubernetes. Never commit them to Git, bake them into images, or print them in logs. Note that Kubernetes Secrets are only base64-encoded by default, so enable encryption at rest and restrict access with RBAC. Rotate secrets regularly and on any suspected leak.

Q41. What is supply chain security in CI/CD?

Protecting the path from source to production against tampering: pin third-party CI actions and dependencies to specific versions or commit SHAs, use trusted base images, sign images (for example with Sigstore cosign) and verify signatures at deploy time with admission policies, generate provenance attestations (the SLSA framework describes levels), and limit who can change pipeline definitions. Incidents where popular CI actions or packages were compromised have made this a common interview topic.

Q42. How do you apply least privilege in pipelines?

Give each job only the permissions it needs (read-only by default, as in the permissions block in Q11), separate roles for plan and apply, require approvals for production environments, keep pull requests from forks away from secrets, and restrict who can modify pipeline files through branch protection and code owners.

Monitoring, Observability and Reliability: Questions 43-50

Q43. Monitoring vs observability?

Monitoring watches known failure modes with predefined metrics, dashboards and alerts. Observability is the ability to ask new questions about a system's behaviour from its outputs, which matters for failures you did not predict. It rests on three signal types: metrics (cheap aggregates over time), logs (detailed events), and traces (a request's path across services). OpenTelemetry is the common standard for producing them. More in our observability guide.

Q44. What should you monitor for a web service?

Start with the four golden signals from Google's SRE book: latency (separating successful and failed requests), traffic, errors and saturation. The RED method (rate, errors, duration) applies to request-driven services, and USE (utilization, saturation, errors) to resources like CPU, memory, disks and connection pools. Add business metrics such as orders per minute or payment success rate.

Q45. What are SLIs, SLOs and error budgets?

An SLI is a measured indicator of user experience, such as the fraction of requests served successfully within 300 ms. An SLO is the target for it, say 99.9% over 30 days. The error budget is what the SLO allows to fail: 0.1% of 30 days is about 43 minutes of full unavailability, or the equivalent in failed requests. When the budget is healthy, teams ship faster; when it is exhausted, they slow down and prioritize reliability. An SLA is a contractual commitment to customers, usually looser than the internal SLO.

Q46. How do you design good alerts?

Alert on symptoms users feel (error rate, latency, SLO burn rate), not on every cause (one pod's CPU at 90%). Every page should be urgent, actionable and linked to a runbook; anything else goes to a ticket or dashboard. Multi-window burn-rate alerts page when the error budget is being consumed fast (for example, 2% of a 30-day budget in one hour) and open tickets for slow burns.

groups:
  - name: orders-service
    rules:
      - alert: OrdersHighErrorRate
        expr: |
          sum(rate(http_requests_total{service="orders", status=~"5.."}[5m]))
            /
          sum(rate(http_requests_total{service="orders"}[5m])) > 0.02
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Orders 5xx rate above 2% for 5 minutes"
          runbook: "https://runbooks.example.com/orders/high-error-rate"

Q47. How do you correlate a deployment with an incident?

Annotate dashboards with deploy events, include the version or commit SHA in logs, metrics labels and traces, and have the deploy pipeline post to the incident channel. The first question in many incidents is "what changed?", and a timeline that shows a deploy two minutes before the error spike points straight at the cause and the remedy: roll back first, debug after.

Q48. What happens in incident management and postmortems?

During an incident: declare it, assign an incident commander, mitigate first (roll back, fail over, disable a flag), communicate status regularly, and keep a timeline. Afterwards, write a blameless postmortem: impact, timeline, root causes and contributing factors, what went well, and action items with owners. Blameless means focusing on how the system allowed the mistake, so people share information honestly. Track MTTR (mean time to restore) as part of DORA metrics.

Q49. What is chaos engineering?

Deliberately injecting failures (killing instances, adding latency, failing a dependency, blocking a zone) in a controlled way to verify that the system and the team handle them. Start in staging with a hypothesis ("if one Redis replica dies, latency stays under 200 ms"), limit the blast radius, and graduate to production game days only with good observability and an abort switch.

Q50. How would you design CI/CD for 50 microservices?

Provide a paved road: reusable pipeline templates (shared workflows or Jenkins shared libraries) so each service gets build, test, scan, image push and progressive deploy by default; a standard Helm chart or base manifests; GitOps for deploys with one config repository or directory per environment; contract tests between services so teams can deploy independently; per-service canary analysis with standard SLO metrics; centralized observability with consistent labels; and a platform team that owns the templates while service teams own their pipelines' service-specific steps. Measure DORA metrics per team to find where the platform needs work. This is the kind of system-level answer SDE-2 and platform interviews look for; see microservices interview questions for related topics.

Scenario Round Practice

Senior DevOps and SRE interviews often end with scenarios. Practise structuring each answer as: stabilize, diagnose, fix, prevent.

"The deploy succeeded, but the error rate doubled."

Stabilize by rolling back immediately (or halting the canary) rather than debugging in production. Then diagnose using the deploy diff, logs and traces filtered by the new version, and compare configuration between versions. Prevent recurrence with canary analysis on error rate, a better readiness check, or a test that would have caught it.

"Our builds randomly fail about one time in five."

Collect failure data by test and step; look for patterns (a particular runner, time of day, parallel jobs sharing a database). Quarantine flaky tests, isolate test resources per job, pin tool versions, and replace sleeps with condition waits. Report flakiness rates so the trend is visible.

"Someone changed a security group in the console and production broke."

Restore via Terraform apply (which reverts drift) or a reviewed fix in code. Then remove console write access for production, add drift detection, and make the infrastructure change process fast enough that people are not tempted to bypass it.

"An access key was committed to a public repository."

Revoke and rotate the key first (assume it is already compromised; automated scanners find public keys within minutes), check cloud audit logs for misuse, then remove it from history and add pre-commit and CI secret scanning. Move the workload to OIDC or short-lived credentials so there is no static key to leak.

To go further, read our DevOps and SRE career path guide, review AWS interview questions for the cloud side, and brush up on Linux and shell interview questions, which most DevOps rounds include.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.