DevOps Interview Questions

An image is a read-only template with the OS layer, runtime, code and dependencies. A container is a running instance of an image with its own writable layer.

A set of practices and culture that brings development and operations together to deliver software faster and more reliably through automation, continuous integration and delivery, monitoring and shared ownership.

CI merges and tests code frequently and automatically. Continuous delivery keeps every build releasable, with a manual approval to production. Continuous deployment releases every passing change automatically.

A request to merge changes from one branch into another, used for code review, discussion and running automated checks before merging.

Plan, design, build, test, release, deploy, operate and monitor — with feedback flowing back into planning. DevOps shortens this loop by automating builds, tests and deployments and by sharing ownership of production.

Git is a version control system. Every clone has the full history, so you can commit, branch and view history offline, and there is no single point of failure. You sync with remotes using fetch, pull and push.

git add moves changes into the staging area (index), choosing exactly what goes into the next snapshot. git commit records that snapshot with a message. Small, focused commits make history and reviews easier.

Hosting for repositories plus collaboration: pull requests and code review, issues and projects, Actions for CI/CD, packages, security scanning (Dependabot, secret scanning, code scanning) and branch protection rules.

A human-friendly data format used by pipelines, Kubernetes and Docker Compose. Indentation defines structure (spaces, never tabs), lists start with -, and unquoted values like yes, no or 1.10 may be parsed as booleans or numbers.

Merge preserves history and adds a merge commit. Rebase replays your commits on top of another branch for a linear history but rewrites commit hashes — never rebase commits others have pulled.

Trunk-based development uses short-lived branches merged to main frequently — great for CI/CD. GitFlow uses long-lived develop and release branches — suits scheduled releases but adds overhead.

Defining and running multi-container apps (API, database, cache) with one YAML file and one command, mainly for local development and testing.

A Pod runs one or more containers. A Deployment manages replicas of Pods and rolling updates. A Service gives Pods a stable network address and load-balances between them.

A YAML file in .github/workflows with triggers (on: push, pull_request, schedule), jobs that run on runners, and steps that run commands or reusable actions. Jobs run in parallel unless linked with needs.

1name: ci
2on: [push, pull_request]
3jobs:
4  test:
5    runs-on: ubuntu-latest
6    steps:
7      - uses: actions/checkout@v4
8      - uses: actions/setup-node@v4
9        with: { node-version: 22, cache: npm }
10      - run: npm ci
11      - run: npm test

It is fast, deterministic and runs on every change: restore with lock files, build, lint, run unit tests, scan dependencies, and produce one versioned artifact or image that is promoted through environments unchanged.

The stages that take a built artifact through environments — dev, staging, production — with deployment jobs, configuration per environment, automated smoke tests, approvals and gates such as monitoring checks.

Use a small, pinned base image, multi-stage builds, copy dependency manifests before source code to maximise layer caching, run as a non-root user, add a .dockerignore and keep secrets out of the image.

A container’s writable layer disappears when it is removed. Use named volumes (managed by Docker) for databases and bind mounts for development source code. In Kubernetes, use persistent volume claims.

A store for container images, such as Docker Hub, GitHub Container Registry, Azure Container Registry or Amazon ECR. Pipelines push tagged images; platforms pull them. Tag with the commit SHA, not only latest.

A file mapping your configuration to real resources so Terraform can plan changes. Store it remotely (S3 + DynamoDB lock, Azure Storage, Terraform Cloud) with locking and encryption, and never edit it by hand.

Blue-green runs two identical environments and switches all traffic at once, allowing instant rollback. Canary sends a small percentage of traffic to the new version first and increases it as metrics stay healthy.

Defining infrastructure in version-controlled files (Terraform, Bicep, CloudFormation) so environments are reproducible, reviewable, testable and can be recreated automatically.

Store them in a secret manager (Key Vault, AWS Secrets Manager, GitHub encrypted secrets), prefer short-lived credentials via OIDC federation, mask them in logs and never commit them to the repository.

Security checks in every stage: dependency and container vulnerability scanning, static analysis (SAST), secret scanning, infrastructure policy checks and dynamic testing (DAST) — shifting security left.

Logs are detailed event records, metrics are numeric time series for dashboards and alerts, and traces follow one request across services. OpenTelemetry collects all three; alert on symptoms users feel (error rate, latency), not every cause.

A test pyramid: many fast unit tests on every commit, fewer integration tests against real dependencies in containers, a small set of end-to-end tests on critical journeys, plus static analysis and security scans. Flaky tests must be fixed or quarantined.

Redeploy the previous artifact, swap back slots, shift traffic back in blue-green or canary setups, or use kubectl rollout undo. Database changes need backward-compatible migrations (expand and contract) so the old version still works.

Azure Boards for work tracking, Repos, Pipelines (YAML with stages, environments and approvals), Test Plans and Artifacts feeds. It suits enterprises with existing Microsoft tooling; GitHub leads on open source and developer experience.