DevOps & Deployment interview questions and answers

Question 1

What are IaaS, PaaS, and SaaS?

Accepted Answer

Answer: They are three levels of cloud service, differing in how much the provider manages for you. IaaS (Infrastructure as a Service): the provider gives you virtual machines, storage, and networking. You manage the operating system, runtime, and your app. Examples: AWS EC2, Google Compute Engine. PaaS (Platform as a Service): the provider also manages the OS, runtime, scaling, and patching. You just deploy your code. Examples: Heroku, Google App Engine, AWS Elastic Beanstalk. SaaS (Software as a Service): the provider runs a finished application that you just use through a browser. You manage nothing. Examples: Gmail, Salesforce, Notion. The more you move up (IaaS to SaaS), the less you control and the less you have to operate. Analogy: pizza. IaaS: they give you the kitchen, you cook. PaaS: they give you the oven pre-heated and the dough ready, you add toppings and bake. SaaS: the pizza is delivered hot. In an interview: IaaS gives you raw VMs and you manage the OS up. PaaS manages the platform so you just deploy code. SaaS is a finished app you only use. Moving up trades control for less operations work.

Question 2

What is infrastructure as code (IaC)?

Accepted Answer

Answer: Infrastructure as code means you describe your servers, databases, networks, and cloud resources in text files, and a tool creates or updates them to match. You do not click around a cloud console by hand. Why: the setup is version-controlled, reviewable in a pull request, repeatable (spin up an identical staging environment in minutes), and self-documenting. Manual clicking drifts, is undocumented, and cannot be rolled back. Tools: Terraform and Pulumi (cloud-agnostic), AWS CloudFormation, and CDK. They are usually declarative: you state the desired end state, and the tool works out the changes. Analogy: instead of building each house by hand from memory, you keep the blueprint in version control and a machine builds an identical house from it every time. In an interview: Infrastructure as code describes cloud resources in version-controlled text files that a tool applies. It makes environments repeatable, reviewable, and rollback-able, versus manual console clicking which drifts and is undocumented. Terraform is the common tool.

Question 3

What is Docker, and why is it used?

Accepted Answer

Answer: Docker is a platform for packaging an application together with everything it needs to run, its code, runtime, libraries, and config, into one unit called a container. That container runs the same way on your laptop, a test server, and production. Why it is used: Portability: a container runs on any machine with Docker, so the old 'it works on my machine' problem goes away. Consistency: the same image is used from development through to production, so environments match. Efficiency: containers share the host operating system's kernel instead of each carrying a full OS, so they are small (megabytes) and start in milliseconds. Scalability: you can run many identical containers of an app behind a load balancer, and start or stop them quickly as load changes. Analogy: a shipping container. It does not matter what is inside or which ship, crane, or truck carries it; the outside is standard so it moves anywhere without repacking. In an interview: Docker packages an app with its dependencies into a container that runs identically everywhere. It solves environment mismatch, keeps dev and prod consistent, is lightweight because containers share the host kernel, and makes horizontal scaling easy.

Question 4

What are the key components of Docker, and what does each do?

Accepted Answer

Answer: Docker Engine: the core. It has three parts: - Docker Daemon (dockerd): a background service that actually builds images, runs containers, and manages networks and volumes. - Docker CLI (the docker command): what you type; it sends requests to the daemon. - REST API: how the CLI (or other tools) talk to the daemon programmatically. Docker Image: an immutable, layered template containing an app and its dependencies. You build it once. Docker Container: a running instance of an image, with its own isolated processes, filesystem, and network. Docker Registry (Docker Hub is the public one): where images are stored and shared. docker pull downloads, docker push uploads. Docker Volume: persistent storage that outlives a container, for databases and uploaded files. Docker Network: virtual networks that let containers talk to each other. Analogy: the CLI is the remote control, the daemon is the machine doing the work, images are the blueprints, containers are the running machines, the registry is the warehouse of blueprints, and volumes are the external hard drives. In an interview: The Docker Engine is the daemon that does the work, the CLI you type, and the REST API between them. Images are immutable templates, containers are running instances, a registry like Docker Hub stores images, volumes persist data, and networks connect containers.

Question 5

What is the difference between a container and a virtual machine?

Accepted Answer

Answer: Both package an app so it runs the same everywhere, but at different levels. A virtual machine emulates a whole computer. It runs its own full operating system on top of a hypervisor. It is heavy: gigabytes in size, tens of seconds to boot, strong isolation. A container packages just your app and its dependencies (libraries, runtime), and shares the host machine's operating system kernel. It is light: megabytes in size, starts in milliseconds, weaker isolation than a VM but plenty for most uses. Docker is the common tool. Because containers are small and fast, you can run many on one machine and start them instantly, which is why they suit microservices and autoscaling. Analogy: a VM is a whole separate house with its own foundations and plumbing. A container is a furnished room in a shared building: your own space, but the building's utilities are shared. In an interview: A VM virtualises a whole machine with its own OS: heavy, slow to boot, strongly isolated. A container packages just the app and shares the host kernel: tiny, starts instantly, lighter isolation. Containers suit microservices and autoscaling.

Question 6

What is the difference between a Docker image, a container, and a Dockerfile?

Accepted Answer

Answer: Dockerfile: a text recipe. It lists the steps to build your app's environment: a base image, dependencies to install, files to copy, the command to run. Image: the built result of a Dockerfile. A read-only, layered snapshot of a filesystem plus metadata. You build it once and push it to a registry. Images are immutable and tagged (myapp:1.4). Container: a running instance of an image. You can start many containers from one image, each with its own writable layer on top. When it stops and is removed, that writable layer is gone unless you used a volume. It is class and object, for environments: the image is the template, the container is a live instance. Analogy: the Dockerfile is a recipe, the image is a frozen ready-meal made from it, and a container is that meal heated up and being eaten. In an interview: A Dockerfile is the build recipe, an image is the immutable built snapshot you push to a registry, and a container is a running instance of an image with its own writable layer. One image, many containers.

Question 7

What is Docker Hub, and what is an image tag?

Accepted Answer

Answer: Docker Hub is the default public registry, an online store of Docker images. Official images (nginx, postgres, node, python) and community images live there. docker pull nginx downloads from it; docker push myuser/myapp uploads to it. Companies also run private registries (AWS ECR, GitHub Container Registry) for their own images. A tag is a label on an image, written as name:tag, for example node:20-alpine or myapp:1.4. If you leave the tag off, Docker assumes :latest. Tags let you keep multiple versions of an image and pin exactly which one to run. Using :latest in production is risky because it can silently change. Analogy: Docker Hub is an app store for pre-built environments. A tag is the version number on the box. In an interview: Docker Hub is the default public image registry; you pull images from it and can push your own, and companies use private registries too. A tag is a version label like myapp:1.4; omitting it means :latest, which you avoid pinning to in production.

Question 8

Explain the lifecycle of a Docker container.

Accepted Answer

Answer: A container moves through a few states: 1. Created: docker create makes a container from an image but does not start it. 2. Running: docker start (or docker run, which does create plus start) runs the container's main process. 3. Paused: docker pause freezes all its processes; docker unpause resumes them. 4. Stopped / Exited: the main process finished, or docker stop sent it a signal to shut down. The container still exists and can be restarted. 5. Removed: docker rm deletes the stopped container and its writable layer for good. Key point: stopping a container does not delete it. Its data in the writable layer survives a stop but not a remove. For data you need to keep, use a volume. Analogy: a car: built in the factory (created), driving (running), parked with the engine off (stopped), and scrapped (removed). Parking does not destroy the car. In an interview: Created, running, paused, stopped, removed. docker run is create plus start, docker stop shuts it down but keeps it, docker start runs it again, and docker rm deletes it. Data in the writable layer survives a stop but not a remove, so use a volume for anything you must keep.

Question 9

How does Docker isolate containers from each other and the host?

Accepted Answer

Answer: Docker uses built-in Linux kernel features: Namespaces: give each container its own view of the system. Separate namespaces for process IDs (a container sees only its own processes), the network (its own interfaces and ports), mount points (its own filesystem), users, and hostname. So processes in one container cannot see or signal processes in another. cgroups (control groups): limit and account for how much CPU, memory, and I/O a container can use, so one container cannot starve the others or the host. A layered filesystem gives each container its own writable layer on top of the shared read-only image. This is lighter than a VM (no separate OS) but also weaker: all containers share the host kernel, so a kernel exploit could cross the boundary. That is why you avoid running containers as root and keep the host patched. Analogy: an office building where each company gets locked rooms (namespaces) and a metered power and water supply (cgroups), but they all share the same building foundation (the kernel). In an interview: Docker uses Linux namespaces to give each container its own isolated view of processes, network, and filesystem, and cgroups to cap its CPU, memory, and I/O. It is lighter than a VM but shares the host kernel, so it is weaker isolation, which is why you do not run as root and keep the host patched.

Question 10

What is a Docker volume, and how is it different from a bind mount?

Accepted Answer

Answer: A container's own filesystem is temporary, it is wiped when the container is removed. To keep data (a database, uploaded files) you store it outside the container. Volume: storage that Docker creates and manages in its own area on the host. You refer to it by name. It is the recommended way to persist data, works the same on Linux, Mac, and Windows, and is easy to back up. Bind mount: you map a specific folder on the host straight into the container. Used mostly in development to mount your source code so changes show up live without rebuilding. It ties the container to the host's exact directory layout. tmpfs mount: storage that lives only in memory and never touches disk, for sensitive or purely temporary data. When a container using a named volume is deleted, the volume stays; you remove it separately with docker volume rm or docker volume prune. Analogy: a volume is a storage locker the building manages for you. A bind mount is you handing the tenant a key to a specific room in your own house. In an interview: Container filesystems are temporary, so persistent data goes in a volume, which Docker manages by name and is the recommended, portable option. A bind mount maps a specific host folder in, used mainly for live source code in development. Deleting a container does not delete its named volume.

Question 11

What is Docker Compose, and when do you use it?

Accepted Answer

Answer: Docker Compose runs a multi-container application from a single YAML file. Instead of typing many docker run commands with the right flags, ports, volumes, and network, you describe all the services once in docker-compose.yml and start them with one command. You use it for local development and small deployments: an app that needs a web service, a database, and a cache. Compose creates a shared network so the containers can reach each other by service name (the web service connects to db:5432). Key commands: docker compose up starts everything (add -d to run in the background), docker compose down stops and removes it, docker compose ps shows status, docker compose logs -f follows logs. depends_on sets a start order. For production at scale you move to Kubernetes; Compose is for one machine. Analogy: a docker run command sets up one appliance. Compose is the wiring diagram for the whole kitchen, so you plug it all in at once. In an interview: Docker Compose defines a multi-container app in one YAML file and starts it with docker compose up. It creates a shared network so services reach each other by name. It is for local development and single-machine deployments; Kubernetes takes over at production scale.

Question 12

Reference: the Docker commands you use most.

Accepted Answer

The everyday set. docker and docker compose are the two entry points. In an interview: build and run to create things, ps and logs and exec and stats to inspect, stop/start/rm to manage lifecycle, and system prune to clean up. docker compose up and down for multi-container apps.

Question 13

What does Kubernetes do?

Accepted Answer

Answer: Kubernetes is a container orchestrator. Once you have many containers across many machines, Kubernetes manages them for you. What it handles: scheduling containers onto machines with spare capacity; restarting containers that crash; scaling the number of copies up or down based on load; rolling out a new version gradually and rolling back if it fails; giving each service a stable internal address and load-balancing across its copies; and managing configuration and secrets. You describe the desired state ("I want 5 copies of this service") in YAML, and Kubernetes continuously works to make reality match that. Analogy: an air traffic controller for containers. You say where planes need to go; it decides which runway, reroutes around problems, and brings in more planes when the airport gets busy. In an interview: Kubernetes orchestrates containers across a cluster: scheduling, self-healing restarts, autoscaling, rolling updates and rollbacks, and service discovery with load balancing. You declare the desired state and it reconciles reality to match.

Question 14

What is the difference between Docker Compose, Docker Swarm, and Kubernetes?

Accepted Answer

Answer: They solve the same shape of problem at three different scales. Docker Compose: one machine. Defines and runs a multi-container app locally or on a single server. No clustering, no self-healing across machines. Docker Swarm: Docker's own built-in clustering. Turns several machines into one pool and spreads containers across them, with basic scaling and rolling updates. Simple to set up (it is part of Docker), but limited features and much smaller community now. Kubernetes: the industry standard orchestrator. Runs across many machines with autoscaling, self-healing, advanced networking, storage integration, and a huge ecosystem. More complex to run, but what almost everyone uses at scale. Path most teams take: Compose for development, then Kubernetes (often a managed one like EKS or GKE) for production. Swarm is rarely chosen for new projects. Analogy: Compose is a home kitchen, Swarm is a small catering setup, Kubernetes is an industrial food factory. Same cooking, very different scale and machinery. In an interview: Compose runs a multi-container app on one machine for development. Swarm is Docker's simple built-in multi-machine clustering, now uncommon. Kubernetes is the standard production orchestrator across many machines with autoscaling and self-healing. Teams usually go Compose then Kubernetes.

Question 15

What does a CI/CD pipeline for a web application look like?

Accepted Answer

Answer: CI (continuous integration) checks every change automatically. CD (continuous delivery/deployment) ships it. A typical pipeline, triggered on every push and pull request: 1. Install dependencies (from a lockfile, cached). 2. Lint and type-check. 3. Run unit and integration tests. 4. Build the production bundle (and the Docker image). 5. Run end-to-end tests against the build. 6. On merge to main: deploy to a staging environment, run smoke tests. 7. Deploy to production, often gradually (canary or blue-green), with the ability to roll back. Good practices: fail fast (cheap checks first), keep it under about 10 minutes, block merges on a red pipeline, deploy small changes often, and make rollback one click. Analogy: an assembly line with quality gates. A part that fails inspection at any station never reaches the customer, and the line can be reversed if a defect slips through. In an interview: On every push: install, lint, type-check, test, build, end-to-end test. On merge: deploy to staging, smoke test, then deploy to production gradually with easy rollback. Keep it fast, fail early, and block merges when it is red.

Question 16

What are dev, staging, and production environments, and how do you manage config across them?

Accepted Answer

Answer: Development: your machine or a shared dev environment. Fast to change, fake or small data, verbose logging. Staging: a copy of production as close as you can make it, same infrastructure, similar data volume. This is where you test a release before it goes live. Production: the real thing that users hit. Real data, strict access, alerting. Config across them: never hard-code environment-specific values. Keep them in environment variables (or a secrets manager), with a different set per environment. The same build artifact (the same Docker image) is promoted from staging to production unchanged, only the config differs. Secrets (API keys, DB passwords) go in a secrets manager, never in the repo. Analogy: a play: dev is rehearsal in a room, staging is the dress rehearsal on the real stage, production is opening night with an audience. Same script, different stakes. In an interview: Dev is fast and local, staging mirrors production for release testing, production is the real system. Environment values live in environment variables or a secrets manager, one set per environment, and you promote the same build artifact through the environments changing only config.

Question 17

What is the difference between blue-green and canary deployments, and why not just replace everything at once?

Accepted Answer

Answer: Replacing every server at once ('recreate') means downtime while they restart, and if the new version is broken, every user hits the bug and you have to scramble to roll back. Blue-green: run two identical production environments. 'Blue' is live. Deploy the new version to 'green', test it, then switch all traffic to green at once (a load balancer change). If green is bad, switch back to blue instantly. Costs double the infrastructure during the switch. Canary: deploy the new version alongside the old, and send it a small slice of traffic (say 5 percent). Watch error rates and latency. If it looks good, gradually raise it to 100 percent; if not, route that 5 percent back. Cheaper than blue-green and limits the blast radius, but slower and needs good monitoring. Rolling update (the Kubernetes default) is in between: replace instances a few at a time. Analogy: blue-green is having a spare identical stage and flipping a switch to it. Canary is letting a few audience members watch the new act first before the whole theatre does. In an interview: All-at-once means downtime and every user hits a bad release. Blue-green keeps a parallel environment and flips traffic with instant rollback at double cost. Canary sends a small traffic slice to the new version and ramps up while watching metrics, limiting the blast radius.

Question 18

What is observability, and what are logs, metrics, and traces?

Accepted Answer

Answer: Observability is being able to understand what a running system is doing from the outside, especially when something goes wrong. It rests on three kinds of data: Logs: timestamped text records of individual events ('user 42 logged in', 'payment failed: timeout'). Good for the detail of one request. Searched in a tool like the ELK stack or Loki. Metrics: numbers measured over time (requests per second, error rate, p99 latency, CPU, memory). Cheap to store, good for dashboards and alerts. Prometheus and Grafana are common. Traces: the path of one request across all the services it touched, with timing for each hop. This is how you find which service in a chain is slow. OpenTelemetry, Jaeger, and Datadog do this. Rule: metrics tell you something is wrong and alert you, traces tell you where, logs tell you why. Analogy: a hospital patient monitor. Metrics are the vital-sign numbers and the alarm. Traces are the timeline of everything that happened to the patient. Logs are the detailed nurse's notes. In an interview: Observability is understanding a live system from its outputs. Logs are detailed per-event records, metrics are numeric time series for dashboards and alerts, and traces follow one request across services with per-hop timing. Metrics alert you, traces localise the problem, logs explain it.

Question 19

What does a load balancer do, and what are the common strategies?

Accepted Answer

Answer: A load balancer sits in front of several identical servers and spreads incoming requests across them. It gives you horizontal scaling (add more servers behind it), high availability (it stops sending traffic to a server that fails its health check), and a single stable address for clients. Common strategies for choosing a server: - Round robin: each request to the next server in turn. Simple, assumes requests are roughly equal. - Least connections: send to the server currently handling the fewest requests. Better when request durations vary. - IP hash / sticky sessions: always send a given client to the same server, needed if the server keeps per-user state in memory (better to make servers stateless and avoid this). It works at layer 4 (TCP, just forwarding) or layer 7 (HTTP, can route by path or host and terminate TLS). Analogy: the person at the front of a bank who directs customers to whichever teller is free, and stops sending people to a teller who has gone on break. In an interview: A load balancer distributes requests across identical servers, enables horizontal scaling and failover via health checks, and presents one stable address. Round robin is simple, least connections handles uneven request times, and sticky sessions pin a client to a server, which you avoid by making servers stateless.

Question 20

How do you diagnose and fix a slow backend under load?

Accepted Answer

Answer: Work from data, layer by layer, do not guess. 1. Measure. Look at metrics and traces: which endpoint is slow, at what percentile (p50 vs p99), and where the time goes (app CPU, database, an external call, GC pauses). 2. Find the bottleneck. Common ones: slow database queries (missing index, N+1), lock contention, an undersized connection or thread pool, a slow downstream service, or too little memory causing heavy garbage collection. 3. Fix the biggest one. Add an index, batch the N+1 into one query, add caching for hot reads, increase pool size, add a timeout and circuit breaker on the downstream call, or scale out. 4. Re-measure to confirm, and add an alert so it does not silently regress. Analogy: a doctor does not prescribe before running tests. Metrics and traces are the blood work; you treat what they actually show, not your first hunch. In an interview: Measure first with metrics and traces to find where the time goes and at which percentile. The usual causes are slow queries or N+1, pool exhaustion, a slow downstream call, or GC pressure. Fix the biggest, re-measure, add an alert.

DevOps & deployment interview preparation

Cloud service models

Containers and Docker

Orchestration

Pipelines and deployments

Running in production