Question 1

How does a Docker image differ from a container?

Accepted Answer

An image is an immutable template: a set of filesystem layers with metadata such as the start command. A container is a running instance of an image with a thin writable layer, its own processes, network and filesystem. Many containers can be started from one image. Data written inside a container disappears with it unless it is moved to a volume.

Question 2

How does a container differ from a virtual machine?

Accepted Answer

A virtual machine has its own guest OS on top of a hypervisor, so it is heavier, starts in minutes and is isolated more strongly. A container shares the host kernel and is isolated by kernel features: namespaces for the view of processes and network, cgroups for resource limits. That is why a container starts in seconds and takes megabytes. The price: all containers depend on one kernel, so isolation is weaker than with a VM.

Question 3

What is CI and why does a team need it?

Accepted Answer

Continuous Integration is the practice where every code change is automatically built and checked on a server: installing dependencies, linter, types, tests, build. A developer learns within minutes that a change broke something, not a week after merging. CI also guarantees the check runs in a clean environment, not only on the author's laptop. It usually runs on every pull request and blocks the merge while checks are red.

Question 4

How does Continuous Delivery differ from Continuous Deployment?

Accepted Answer

Both extend CI: after successful checks the build moves through the pipeline toward a release. In Continuous Delivery the artifact is always ready to ship, but a human decides to press the deploy button. In Continuous Deployment every change that passes all automatic checks reaches production with no manual step. The latter requires very reliable tests, feature flags and fast rollback.

Question 5

What are Docker image layers and how do they affect build speed?

Accepted Answer

Each Dockerfile instruction such as RUN or COPY creates a layer. Docker caches layers: if an instruction and its input did not change, the layer comes from the cache. But a change in one layer invalidates the cache of all following layers. So rarely changing things go first and the application code is copied last: first the dependency file and the install, then the rest.

Question 6

How does a container keep data and how do you reach it from outside?

Accepted Answer

Data that must outlive the container goes into a named volume or bind mount: it lives outside the container's writable layer. A container is network-isolated by default, so a port is published with -p host:container. Containers in the same user-defined network see each other by service name through built-in DNS. Content without a volume disappears when the container is removed.

Question 7

What are a Pod and a Deployment in Kubernetes?

Accepted Answer

A Pod is the smallest unit of execution: one or more containers with shared network and storage. A Pod is temporary: if it dies, nobody restores it on its own. A Deployment describes the desired state: which image and how many replicas. A controller makes sure the actual state matches the desired one, recreates failed Pods and performs rolling updates.

Question 8

Why do you need Service and Ingress in Kubernetes?

Accepted Answer

Pod IP addresses change, so a Service provides a stable name and virtual address that balances traffic across live Pods chosen by a label selector. Service types: ClusterIP only inside the cluster, NodePort and LoadBalancer for external access. Ingress describes HTTP routing rules by host and path and terminates TLS. The rules do nothing without an ingress controller, for example one based on Nginx.

Question 9

Why are config and secrets not hardcoded in code and images?

Accepted Answer

The same image must run in dev, staging and prod, and only the configuration should differ, supplied through environment variables or mounted files. Secrets in code end up in git history, in the image registry and with everyone who has repository access. They are stored in a secrets manager or encrypted CI variables and passed in at runtime. A committed key is considered compromised: it is rotated, not just removed from the repo.

Question 10

What is observability and how do logs, metrics and traces differ?

Accepted Answer

Logs are individual events with context: what exactly happened and with what data. Metrics are numbers over time, cheap to aggregate and alert on: RPS, error rate, latency. A trace shows the path of one request across several services with spans and time in each. A metric says something is wrong, a trace says where, a log says why. They are linked by a shared request id or trace_id.

Question 11

A Node app image weighs over a gigabyte, and every one-line code change reinstalls all dependencies. How do you fix the Dockerfile?

Accepted Answer

Each instruction makes a layer, and a changed layer invalidates the cache of the following ones. If COPY . . comes before npm install, any code edit reinstalls dependencies. First copy package.json with the lock file, run npm ci, and only then the rest of the code. For size, use multi-stage: build in one stage, and only the built code and production dependencies reach the final slim image via COPY --from. Also add .dockerignore, run as a non-root user and pin the image tag instead of latest.

Question 12

A Dockerfile copies a token into the image and the next command deletes the file with rm. Is the token gone, and how should you pass a secret into a build correctly?

Accepted Answer

It is not gone. Layers are only added: rm creates a new layer with a deletion mark, while the COPY layer stays in the image and goes to the registry. Anyone who can pull will unpack the layer and read the token. The right way is a BuildKit secret: RUN --mount=type=secret,id=npmrc together with docker build --secret, so the secret is available only during that command and does not land in a layer. ARG is not suitable either, because values stay in the image history.

Question 13

docker stop on your Node container always waits 10 seconds and then kills it. Why, and what do you do about it?

Accepted Answer

docker stop sends SIGTERM to the process with PID 1 and SIGKILL after the timeout. A PID 1 process in Linux has no default signal handlers, so if the app does not listen for SIGTERM, it does not exit. A common cause is also starting through npm start or the shell form of CMD: the shell gets the signal, not Node. Fix: exec form CMD ["node", "dist/main.js"], a SIGTERM handler that closes the server and connections, and if needed the --init flag or tini.

Question 14

In docker compose the API fails with connection refused to Postgres even though depends_on is set. Why, and how do you fix it?

Accepted Answer

A plain depends_on only controls container start order, not service readiness. The Postgres container is already running, but the database is still initializing. The solution: a healthcheck on the database service (for example pg_isready) and depends_on with the service_healthy condition. Also the app should retry connecting with backoff, because the database can restart in production too.

Question 15

How do liveness, readiness and startup probes differ in Kubernetes?

Accepted Answer

Liveness answers whether the process is alive: on failure the kubelet restarts the container. Readiness says whether the Pod is ready to accept traffic: on failure it is removed from the Service endpoints but not restarted. A startup probe protects a slow start: until it passes, the other probes do not run. A typical mistake is checking an external dependency such as the database in liveness, so its failure restarts all Pods and makes things worse.

Question 16

What are resource requests and limits in Kubernetes and what happens when they are exceeded?

Accepted Answer

A request is the guaranteed minimum the scheduler uses to pick a node. A limit is the ceiling. Exceeding the CPU limit causes throttling, and the process slows down. Exceeding the memory limit causes an OOMKill: the container is killed and restarted. Without requests the scheduler packs nodes blindly, and without limits one Pod can eat its neighbors' resources. The ratio of requests to limits also defines the Pod's QoS class, which determines eviction order.

Question 17

What are ConfigMap and Secret for in Kubernetes, and does a Secret really protect data?

Accepted Answer

A ConfigMap stores non-secret configuration, a Secret is meant for sensitive values. Both can be supplied as environment variables or mounted files. But a Secret is by default only base64-encoded, not encrypted, and is stored in etcd. So you enable etcd encryption at rest, restrict access through RBAC and, for serious cases, connect external stores such as Vault or cloud secret managers. Mounted files update without a restart, environment variables do not.

Question 18

Describe a pipeline for a backend service. What are the stages, how does cache differ from artifacts, and how do you protect the deploy?

Accepted Answer

Typical stages: install dependencies, linter and types, unit tests, image build, integration tests, push to the registry, deploy. A cache speeds up repeated runs (for example downloaded dependencies) and can be lost without harm. An artifact is a build result passed to later stages, and the release uses exactly that so nothing is rebuilt. The deploy is protected by: secrets only in protected variables, production deploy only from the main branch, manual approval or environment protection, and minimal token permissions.

Question 19

How do you secure a workflow in GitHub Actions?

Accepted Answer

Set minimal permissions for GITHUB_TOKEN and use OIDC instead of long-lived cloud keys. Pin third-party actions to a commit SHA, not a movable tag. Do not print secrets in logs or expose them to workflows from forks. The dangerous pull_request_target trigger combined with checking out PR code lets foreign code run with access to secrets, so avoid it. Untrusted input such as a PR title is not interpolated directly into shell commands.

Question 20

What is Infrastructure as Code and how does Terraform work?

Accepted Answer

Infrastructure as Code describes infrastructure as code in a repository, so it can be reviewed, versioned and reproduced. Terraform is declarative: you describe the desired state, terraform plan compares it with the state and shows the changes, and apply carries them out. The state file maps resources to real objects, so it is kept in a remote backend with locking, not in git. Manual changes in the console create drift, which the next plan will show.

Question 21

Compare rolling, blue-green and canary deployments.

Accepted Answer

Rolling gradually replaces old instances with new ones: no downtime and no double resources, but both versions run side by side for a while. Blue-green keeps two full environments and switches traffic at once, rollback is instant, but double infrastructure is needed. Canary sends a small percentage of traffic to the new version and widens it when metrics look fine, which is the lowest risk but needs automatic metric analysis and traffic routing. In all three the database schema must be compatible with both code versions.

Question 22

How do you organize dev, staging and prod, where do config and secrets live, and what do you do when a key was committed to the repo?

Accepted Answer

Environments differ only in configuration, the image is the same. Staging is as close to prod as possible in versions and topology, but with different data and keys. Secrets live in a secrets manager or encrypted CI variables, not in the repo. If a key was committed, revoke and rotate it immediately: rewriting history does not help, because it may already be copied. Then check the key's usage logs and add a secret scanner to pre-commit and CI.

Question 23

How does RED differ from USE? What are SLI, SLO and error budget, and which alerts wake a person at night?

Accepted Answer

RED describes a service from the user's view: Rate, Errors, Duration. USE describes a resource: Utilization, Saturation, Errors, for example for CPU or disk. An SLI is a measured indicator such as the share of successful requests, an SLO is the target value, say 99.9% over 30 days. The error budget is the allowed share of failures, 0.1%, and while it is not exhausted the team can take risks with releases. At night you are paged only for symptoms that affect users or burn the budget quickly, while a disk at 70% becomes a ticket for the morning.

Question 24

What metric types does Prometheus have and why is a histogram almost always used for HTTP latency?

Accepted Answer

A counter only grows (number of requests), a gauge moves both ways (memory, queue), a histogram spreads values across buckets, a summary computes quantiles on the client side. Histograms aggregate across instances: you can sum the buckets of 4 pods and compute the overall p99 with histogram_quantile. Summary quantiles cannot be averaged across instances, the result is wrong. The downside of a histogram is that accuracy depends on the choice of bucket boundaries.

Question 25

A team has 200 alerts a day, everything is red, and nobody reacted to a real incident for 40 minutes. What do you do?

Accepted Answer

This is alert fatigue: people stop trusting the noise. Every alert should require human action right now, otherwise it is deleted or turned into a dashboard or ticket. Alert on user-facing symptoms (errors, latency, SLO), not on every cause. Group and deduplicate in Alertmanager so a host failure does not produce 140 messages. Add a runbook with steps to each alert. Regularly review which alerts fired for nothing and clean them up.

Question 26

How do you set up logging so that one requestId or trace_id finds all lines of a request across all services?

Accepted Answer

Logs are written in a structured form (JSON), not free text. At the request entry you take the identifier from a header such as traceparent, or generate a new one, put it into the context (in Node, AsyncLocalStorage) and add it to every log line automatically. All outgoing calls pass the same identifier on in headers. Then in Loki or Elasticsearch one search by that field shows the whole path of the request. Secrets and personal data do not get into logs, they are masked.

Question 27

The payment service started responding in 30 seconds and the whole API went down. Why is a slow dependency worse than a dead one, and what helps?

Accepted Answer

A dead dependency gives a fast error, while a slow one holds connections, threads and memory until the queue of requests exhausts the resources of the whole service. Protection: short timeouts on all calls, a circuit breaker that opens after a series of failures and fails fast instead of waiting, limiting concurrent calls (bulkhead), and a fallback or degraded functionality. After a pause the breaker lets trial requests through and closes if the dependency recovered.

Question 28

Why are retries at every level of a service chain dangerous during an outage, and how do you configure them correctly?

Accepted Answer

If each of three layers makes 3 attempts, the bottom service gets up to 27 requests for one client request: a retry storm finishes off a dependency that is already degrading. The right way: retry only idempotent operations and only errors that may pass, use exponential backoff with jitter, limit the total retry budget and retry at one level, not at all of them. Dangerous operations such as charging money are protected with an idempotency key.

Question 29

An API runs on a single server. You need 99.9% availability and five times the load headroom. What do you change?

Accepted Answer

Remove the single point of failure: several instances behind a load balancer with health checks, across zones or hosts. The app must be stateless: sessions in Redis or JWT, files in object storage rather than on the instance disk. The database becomes the next bottleneck: read replicas, automatic failover, backups. Add autoscaling on a metric, a cache for hot reads and verify everything with a load test.

Question 30

A nightly pg_dump runs. At 14:03 someone ran DELETE without WHERE. What will such a backup achieve and what would help better?

Accepted Answer

The nightly dump restores the state at 00:00, so all changes over 14 hours are lost. It is better to have continuous WAL archiving together with base backups: then you can do point-in-time recovery and restore to 14:02. Restoration is done on a separate instance, from which the needed data is returned to prod. A backup without a tested restore guarantees nothing, so restores are practiced regularly and RTO and RPO are measured. Copies are kept separate from the main server.

DevOps interview questions and answers

Junior questions

1. How does a Docker image differ from a container?

2. How does a container differ from a virtual machine?

3. What is CI and why does a team need it?

4. How does Continuous Delivery differ from Continuous Deployment?

5. What are Docker image layers and how do they affect build speed?

6. How does a container keep data and how do you reach it from outside?

7. What are a Pod and a Deployment in Kubernetes?

8. Why do you need Service and Ingress in Kubernetes?

9. Why are config and secrets not hardcoded in code and images?

10. What is observability and how do logs, metrics and traces differ?

Middle questions

1. A Node app image weighs over a gigabyte, and every one-line code change reinstalls all dependencies. How do you fix the Dockerfile?

2. A Dockerfile copies a token into the image and the next command deletes the file with rm. Is the token gone, and how should you pass a secret into a build correctly?

3. docker stop on your Node container always waits 10 seconds and then kills it. Why, and what do you do about it?

4. In docker compose the API fails with connection refused to Postgres even though depends_on is set. Why, and how do you fix it?

5. How do liveness, readiness and startup probes differ in Kubernetes?

6. What are resource requests and limits in Kubernetes and what happens when they are exceeded?

7. What are ConfigMap and Secret for in Kubernetes, and does a Secret really protect data?

8. Describe a pipeline for a backend service. What are the stages, how does cache differ from artifacts, and how do you protect the deploy?

9. How do you secure a workflow in GitHub Actions?

10. What is Infrastructure as Code and how does Terraform work?

11. Compare rolling, blue-green and canary deployments.

12. How do you organize dev, staging and prod, where do config and secrets live, and what do you do when a key was committed to the repo?

13. How does RED differ from USE? What are SLI, SLO and error budget, and which alerts wake a person at night?

14. What metric types does Prometheus have and why is a histogram almost always used for HTTP latency?

15. A team has 200 alerts a day, everything is red, and nobody reacted to a real incident for 40 minutes. What do you do?

16. How do you set up logging so that one requestId or trace_id finds all lines of a request across all services?

17. The payment service started responding in 30 seconds and the whole API went down. Why is a slow dependency worse than a dead one, and what helps?

18. Why are retries at every level of a service chain dangerous during an outage, and how do you configure them correctly?

19. An API runs on a single server. You need 99.9% availability and five times the load headroom. What do you change?

20. A nightly pg_dump runs. At 14:03 someone ran DELETE without WHERE. What will such a backup achieve and what would help better?

21. The incident is closed. How do you write a postmortem and what should it contain?

22. How do you make a Docker image and container run more secure?

23. How do you organize a fast release rollback?

Senior questions

1. How do you ship a new API version without downtime if the release also changes the database schema?

2. After a release Prometheus started crashing with OOM, and a label with values like user_id appeared in the metrics. What happened and what do you do?

3. SLO 99.9% over 30 days. The alert error_ratio > 0.001 for 5m wakes people at night over every blip. How do you redo it?

4. At 3 AM an alert fires: 30% of requests return 500, and you are on call. What are your first actions?

5. What is GitOps and how does it differ from deploying from CI?

6. How does horizontal autoscaling work in Kubernetes and what are its pitfalls?

Train these questions

Answer out loud and get graded

Other topics

Explore the platform

2. A Dockerfile copies a token into the image and the next command deletes the file with `rm`. Is the token gone, and how should you pass a secret into a build correctly?

3. `docker stop` on your Node container always waits 10 seconds and then kills it. Why, and what do you do about it?

4. In docker compose the API fails with `connection refused` to Postgres even though `depends_on` is set. Why, and how do you fix it?

16. How do you set up logging so that one `requestId` or `trace_id` finds all lines of a request across all services?

20. A nightly `pg_dump` runs. At 14:03 someone ran `DELETE` without `WHERE`. What will such a backup achieve and what would help better?

2. After a release Prometheus started crashing with OOM, and a label with values like `user_id` appeared in the metrics. What happened and what do you do?

3. SLO 99.9% over 30 days. The alert `error_ratio > 0.001 for 5m` wakes people at night over every blip. How do you redo it?