DevOps Interview Questions (with real STAR answers)

Continuous integration means every change is merged often and automatically built and tested. Continuous delivery adds that every change that passes is ready to release, but a person still approves the release. Continuous deployment removes that manual step - every change that passes the pipeline goes to production automatically.

A virtual machine runs a full guest operating system on a hypervisor. A container shares the host's kernel and isolates only the process, using Linux namespaces and cgroups. Containers start faster and use less memory; virtual machines give stronger isolation.

Use a multi-stage build so build tools stay out of the final image, start from a slim or distroless base image, add a .dockerignore file, combine related RUN steps and clean package caches in the same step, and copy only the files the app needs.

ENTRYPOINT sets the program that always runs. CMD sets the default arguments, and anything passed to docker run replaces CMD. A common pattern is ENTRYPOINT for the binary and CMD for default flags. Use the exec form (a JSON array) so the process is PID 1 and receives signals like SIGTERM.

State is Terraform's record of which real resources match which resources in your code. Terraform compares code, state, and the real world to build a plan. In a team, store state in a remote backend with locking (for example S3 with locking) so two people cannot change it at the same time, and never edit it by hand.

502 Bad Gateway: the proxy reached the upstream but got an invalid response or the connection was refused, often a wrong port or a crashed app. 503 Service Unavailable: no healthy upstream is available or the service is overloaded. 504 Gateway Timeout: the upstream did not answer in time.

Blue-green runs two full environments and switches all traffic from the old one to the new one at once, so rollback is one switch. Canary sends a small share of traffic to the new version first, watches error rate and latency, and increases the share step by step.

Never put secrets in the repository or in the image. Store them in a secrets manager (Vault, AWS Secrets Manager, SSM Parameter Store) or the CI system's encrypted secrets, give each job only the secrets it needs, prefer short-lived credentials such as OIDC roles, mask them in logs, and rotate them.

Running the same playbook or script many times leaves the system in the same state as running it once. In Ansible this means using modules that describe a desired state (package present, file with this content) instead of shell commands that change things every run.

Start with the four golden signals: latency, traffic, errors, and saturation (CPU, memory, disk, connections). Alert on symptoms users feel, such as high error rate or latency, and use logs and traces to find the cause.

A unit file in /etc/systemd/system describes how to start the process (ExecStart), which user runs it, when to restart it (Restart=on-failure), and what it depends on (After=, Wants=). Use systemctl daemon-reload after editing, systemctl enable --now to start it, and journalctl -u name to read its logs.

Confirm with df -h (and df -i for inodes), then find the large paths with du -sh /* and narrow down. Common causes are logs, old Docker images, and core dumps. Clean safely (logrotate, journalctl --vacuum-size, docker system prune), and check lsof +L1 for deleted files still held open by a process. Then add an alert on disk usage.

Reduce user impact first: roll back to the last good version or switch off the feature flag. Tell the team what is happening. When the service is stable, find the cause from logs, metrics, and the diff, then write a blameless postmortem with actions so it does not happen again.

Run systemctl status and journalctl -u service to read the error. Check that the config is valid, that the port is free (ss -tlnp), that file permissions and the run user are correct, and that dependencies like the database are reachable. Change one thing at a time and restart.

Expect behavioral questions (tell me about a time you...), technical questions on CI/CD, Linux, containers, infrastructure as code, and monitoring, and troubleshooting scenarios such as a full disk or a broken deploy. Many companies also give a hands-on task. The questions on this page cover all three types.

Use STAR: Situation, Task, Action, Result. Keep it concrete - a specific incident, what you owned, what you did, and the result. The answers above are all structured this way.