DevOps Engineer Top 100 Interview Questions

DevOps is a way of working in which the people who build software and the people who run it share one goal: delivering changes to users quickly, safely and repeatedly. It combines culture, automation and measurement rather than being a single tool or job title.

It addresses problems that appear when development and operations work apart:

• Slow delivery: releases wait weeks for manual handovers, approvals and environment setup.
• Risky releases: large, infrequent changes are hard to test and hard to roll back.
• Blame between teams: developers are measured on features and operations on stability, so each side resists the other.
• Environment drift: servers configured by hand behave differently, so code that works in testing fails in production.
• Slow recovery: without monitoring and clear ownership, problems take hours to find and fix.

DevOps answers these with small, frequent changes, automated build, test and deployment, infrastructure defined as code, and feedback from production through monitoring. Success is measured by delivery speed and stability together, not one at the expense of the other.

In a traditional split, developers hand finished code to a separate operations team that deploys and runs it. In DevOps, one team owns a service from code to production, and automation replaces most handovers.

When the traditional model still appears:

• Regulated settings may require a separation of duties for production access, but this can be met with automated approvals and audit trails instead of separate teams.
• Very small teams often blend both roles anyway, which is DevOps by necessity.

The key shift is shared responsibility: the people who write the code feel the cost of running it, so they design it to be easy to deploy, observe and recover.

CALMS is a five-part model for checking whether a team has adopted DevOps as a whole, not just its tools. Each letter names one area that must improve together with the others.

How to use it in practice:

• Score each pillar from one to five in a team review to find the weakest area.
• Fix the weakest pillar first; strong automation does little if a blame culture stops people from reporting problems.

Interview tip: interviewers often probe whether you see DevOps as more than tooling, so mention culture and measurement, not only automation.

Four metrics are widely used to measure delivery performance: two describe speed and two describe stability. Looking at all four stops a team from trading reliability for speed without noticing.

Why they matter:

• Speed metrics show how quickly users get value and fixes.
• Stability metrics show whether that speed is safe.
• High performers improve both together, because small, frequent changes are easier to test and to undo.

Use medians rather than averages for time-based metrics, since one very long incident or a stale branch would distort a mean.

DevOps is a broad set of cultural and technical practices for delivering software; Site Reliability Engineering is a specific discipline that applies software engineering to operations, with reliability targets as its core tool. A common summary is that SRE is one concrete way to implement DevOps ideas.

When to use which:

• Use DevOps practices everywhere to shorten the path from commit to production.
• Add SRE practices when a service has users who depend on it and you need an explicit, measurable trade-off between new features and stability.

Both reject the idea that operations is manual work done by hand; SRE adds a rule that engineers should spend a limited share of their time on repetitive operational work.

Platform engineering is building shared, self-service tooling so that product teams can deliver and run software without each team solving infrastructure problems from scratch. The result is often called an internal developer platform.

• Golden paths: ready-made templates for a new service that already include a pipeline, logging, monitoring and security checks.
• Self-service: teams create environments, databases or deployments through a portal or a command instead of filing tickets.
• Guardrails, not gates: policies are built into the platform, so the safe way is also the easy way.
• Reduced cognitive load: developers focus on product code while the platform team owns the common plumbing.
• Treated as a product: the platform has users, a roadmap and feedback, and adoption is earned rather than forced.

flowchart LR
  A["Product team"] -->|requests| B["Self-service portal"]
  B --> C["Service templates"]
  B --> D["Pipelines"]
  B --> E["Environments"]
  C --> F["Running service with monitoring"]
  D --> F
  E --> F

Platform engineering grows out of DevOps when many teams repeat the same infrastructure work; it centralises that work without returning to a separate operations team that owns deployments.

"You build it, you run it" means the team that writes a service is also responsible for operating it in production, including deployments, monitoring and being on call. Ownership does not end when code is merged.

What changes for the team:

• On-call duty: team members respond to alerts for their own service, so they feel the cost of noisy or fragile code.
• Operational design: health checks, useful logs, metrics and safe rollbacks become part of the definition of done.
• Faster fixes: the people paging at night know the code, so diagnosis is quicker than with a separate support team.
• Better priorities: reliability work competes fairly with features because the same team sees both.

What it needs to be fair and sustainable:

1. A shared platform for pipelines, logging and monitoring, so each team is not building tooling alone.
2. A humane on-call rotation with enough people and time off after busy nights.
3. Runbooks and alerts that are actionable rather than a stream of noise.

Interview tip: mention that the model only works with good tooling and fair on-call practices; otherwise it burns teams out.

Start with the biggest source of pain, automate it, and shrink the release size step by step instead of changing everything at once.

1. Measure the current state: record lead time, deployment steps, failure rate and recovery time so progress can be shown.
2. Put everything in version control: code, configuration, scripts and infrastructure definitions.
3. Automate the build and tests: every change gets a fast, repeatable check.
4. Script the deployment: turn the manual checklist into one automated, repeatable process and run it in a test environment first.
5. Release more often: move from monthly to weekly, then smaller, so each release carries less risk.
6. Add monitoring and rollback: make it safe to deploy by knowing quickly when something breaks.

flowchart LR
  A["Measure baseline"] --> B["Version control"]
  B --> C["Automated build and test"]
  C --> D["Scripted deployment"]
  D --> E["Smaller, frequent releases"]
  E --> F["Monitoring and rollback"]
  F -->|review metrics| A

Trade-offs to discuss:

• Quick wins build trust, but the deepest gains come from culture changes such as shared on-call.
• Releasing more often feels risky at first; pair it with automated checks and easy rollback so incidents fall rather than rise.

Version control is the single record of what changed, when, by whom and why, and every automated practice in DevOps starts from it. Without it, there is nothing reliable to build, test, deploy or roll back.

• Trigger for automation: each commit or merge starts the pipeline that builds, tests and deploys the change.
• Audit trail: every change has an author, a timestamp and a message, which supports reviews, compliance and incident analysis.
• Easy rollback: a known-good earlier version can be rebuilt or redeployed exactly.
• Collaboration: branches and reviews let many people change the same system without overwriting each other.
• Everything as code: application code, pipeline definitions, infrastructure and configuration all live in the repository, so environments can be recreated from it.

The practical rule is that if something is not in version control, it cannot be reviewed, reproduced or automated reliably, and it will eventually drift.

Both bring the changes from one branch into another, but merging preserves history as it happened, while rebasing rewrites a branch so it appears to start from the latest commit of the target branch.

When to use which:

• Rebase your own feature branch onto the main branch to pick up recent changes and keep a clean, linear history.
• Merge into shared branches, and never rebase commits that other people have already pulled, because their copies would no longer match.
• Many teams squash a feature branch into a single commit on merge, which gives a clean history without rebasing shared work.

In trunk-based development, everyone integrates small changes into one main branch at least daily. With long-lived feature branches, work stays isolated for days or weeks and is merged when a feature is complete.

When to use which:

• Choose trunk-based development for continuous integration and frequent releases; it needs good automated tests and feature flags.
• Long-lived branches can suit open-source projects with outside contributors or teams that must ship several separately supported versions.

The key point is that integration risk grows with the time branches stay apart, which is why continuous integration and trunk-based development go together.

A merge conflict happens when two changes edit the same lines, or when one change deletes code that another edits. Resolve it in your own branch, understand both changes, and let the pipeline prove the result before it reaches the shared branch.

1. Update first: bring the latest target branch into your own branch so the conflict appears locally, not on the shared branch.
2. Read both sides: understand what each change intended; keeping only your version silently drops someone else's work.
3. Combine deliberately: write the version that satisfies both intentions, then remove all conflict markers.
4. Build and test locally: a file can merge cleanly as text and still break logic elsewhere.
5. Push and let the pipeline run: merge only after the automated checks pass.
6. Ask when unsure: a short conversation with the other author is cheaper than a production bug.

How to prevent conflicts:

• Integrate small changes often, so each conflict is small.
• Avoid mass reformatting mixed with logic changes, since it touches many lines at once.
• Split very large files that many people edit for unrelated reasons.

Semantic versioning gives a release a number in the form MAJOR.MINOR.PATCH, where each part says what kind of change the release contains. It lets users judge the risk of an upgrade from the number alone.

Rules that are easy to get wrong:

• When you increase a part, reset every part to its right to zero.
• Pre-release labels such as 3.0.0-rc.1 sort before 3.0.0.
• Version 0.y.z signals initial development, where anything may change.

In a pipeline, the next version is often derived automatically from commit message conventions, so a commit marked as breaking raises MAJOR and a fix raises PATCH.

A monorepo keeps many projects or services in one repository; a polyrepo setup gives each project its own repository. Neither is better in general: the choice depends on how tightly the code is coupled and how much tooling the team can invest in.

When to use which:

• Choose a monorepo when services share a lot of code, change together often, and you can build only what changed.
• Choose many repositories when teams are independent, release on different schedules, or need strict access separation.

Whichever you choose, the pipeline must avoid rebuilding everything on every change, either through change detection in a monorepo or through clear dependency versions across repositories.

Protecting the main branch means no change reaches it without review and passing checks, because the main branch is what gets deployed. Most hosting systems let you enforce these rules instead of relying on discipline.

• No direct pushes: every change arrives through a reviewed merge request.
• Required reviews: at least one approval from someone other than the author, and from code owners for sensitive areas.
• Required status checks: build, tests, linting and security scans must pass before merging.
• Up-to-date requirement: the branch must include the latest main branch, so checks ran against the real result.
• No force pushes or deletion: history on the main branch cannot be rewritten.
• Signed commits: optionally require cryptographic signatures to prove who authored each commit.

These rules turn the main branch into a reliable source for releases. Emergency fixes should follow the same path with a faster review, rather than bypassing protection.

Interview tip: add that protection only works if the required checks are fast; slow checks push people to look for ways around them.

Never commit secrets, generated files or anything that is specific to one machine. Secrets are the most serious case, because history keeps them even after the file is changed.

Keep out of the repository:

• Passwords, access keys, tokens, private keys and certificates.
• Build output and downloaded dependencies, which the pipeline recreates.
• Local configuration, editor settings and log files.
• Large binary files, which bloat every clone.

If a secret is committed:

1. Revoke and rotate it immediately: assume it is already compromised, even if the repository is private.
2. Check for misuse: review access logs for the period the secret was exposed.
3. Remove it from history: rewrite history to delete it, then ask everyone to re-clone, because deleting the file in a new commit is not enough.
4. Prevent a repeat: add a pre-commit secret scanner and a pipeline check, and load secrets from a secret store at runtime.

The order matters: rotating the secret is the real fix, while cleaning history only limits future exposure.

Continuous integration means every developer merges small changes into the main branch frequently, and each change is built and tested automatically. Problems are found within minutes of being introduced, while the change is still fresh in the author's mind.

A good CI pipeline checks, in rough order of speed:

1. Build: the code compiles and dependencies resolve.
2. Static checks: formatting, linting and type checks.
3. Unit tests: fast tests of individual functions and classes.
4. Security checks: dependency vulnerabilities and leaked secrets.
5. Integration tests: components working together against real dependencies or close stand-ins.
6. Package: produce a versioned artifact ready for deployment.

flowchart LR
  A["Commit pushed"] --> B["Build"]
  B --> C["Static checks and unit tests"]
  C --> D["Security scans"]
  D --> E["Integration tests"]
  E --> F{"All passed?"}
  F -->|yes| G["Publish artifact"]
  F -->|no| H["Notify author"]

The pipeline is only useful if a red build is fixed immediately; a team that tolerates broken builds loses the feedback CI is meant to give.

A build pipeline is a series of automated stages that turn a commit into a deployable, tested artifact. Stages are ordered so the cheapest and fastest checks run first, which gives quick feedback and saves compute time on changes that would fail anyway.

Why the order matters:

• Fail fast: a typo caught by the linter in 20 seconds should not wait behind a 15-minute test suite.
• Build once: later stages reuse the artifact from the build stage, so what was tested is exactly what gets deployed.
• Cost: expensive environments are only created for changes that already passed the cheap checks.

Independent stages, such as linting and unit tests, can run in parallel to shorten the total time.

A build artifact is the packaged output of a build, such as a compiled binary, an archive or a container image, stored with a version so it can be deployed later. Building it once and promoting the same artifact through every environment guarantees that what was tested is exactly what runs in production.

Why rebuilding per environment is risky:

• Different inputs: a dependency may release a new version between builds, so the production build contains untested code.
• Different tools: a build server may have a different compiler or library version than the one used before.
• Lost traceability: you can no longer say for certain which commit and dependencies are running.

How to build once:

1. Build and version the artifact in the first pipeline stage.
2. Store it in an artifact repository with its commit identifier and checksum.
3. Deploy that same artifact to each environment, changing only configuration.
4. Keep environment-specific settings outside the artifact, in configuration or environment variables.

This principle is often stated as "build once, deploy many", and it is the basis for reliable rollbacks to a known artifact.

First measure where the time goes, then remove repeated work, run independent work in parallel, and move slow checks out of the path that blocks every change.

1. Profile the pipeline: find the slowest stages and the slowest individual tests.
2. Cache dependencies and build outputs: avoid downloading and compiling the same things on every run.
3. Parallelise: run independent stages at the same time and split large test suites across several runners.
4. Build only what changed: in large repositories, detect affected projects and skip the rest.
5. Fix slow tests: replace sleeps and real network calls with faster, reliable alternatives.
6. Tier the checks: run fast checks on every commit and the long end-to-end suite before release or on a schedule.

flowchart TD
  A["Measure stage times"] --> B{"Repeated work?"}
  B -->|yes| C["Add caching"]
  B -->|no| D{"Independent stages?"}
  D -->|yes| E["Run in parallel"]
  D -->|no| F["Optimise slow tests"]
  C --> G["Measure again"]
  E --> G
  F --> G

Trade-offs:

• Caches speed things up but can hide problems if they become stale, so key them on the files that define dependencies.
• Moving tests out of every commit lowers feedback time but delays detection of the bugs those tests would catch.