DevOps Engineering Professional Program interview questions

A VM virtualizes hardware and runs a full guest OS, so it is heavier and slower to start. A container shares the host kernel and isolates only the process, filesystem and network namespaces, so it is lightweight, starts in milliseconds and packs densely. Containers trade the stronger isolation of a VM for speed and efficiency.

Use a minimal or distroless base, multi-stage builds so build tools do not ship in the final image, a .dockerignore, pinned versions, and run as a non-root user. Combine layers sensibly, scan the image (Trivy/Grype), and do not bake secrets into layers — pass them at runtime.

The API server validates and stores the desired state in etcd. The Deployment controller creates/updates a ReplicaSet, which creates Pods; the scheduler assigns each Pod to a node by resources and constraints; the kubelet on that node tells the container runtime to pull images and start containers, and reports status back. Controllers continuously reconcile actual state toward the declared state.

kubectl describe pod for events (image pull, OOMKilled, failed probes) and kubectl logs --previous for the crashed container's output. Check the command/args, env and config, resource limits (OOM), and liveness-probe settings that may be killing a slow starter. Fix the root cause rather than just restarting.

A Service gives stable in-cluster access (ClusterIP); for external traffic use a LoadBalancer service or, more commonly, an Ingress with an ingress controller to route HTTP(S) by host/path and terminate TLS. The pattern is Pods → Service → Ingress → users, so Pods can churn without changing the external endpoint.

Both inject configuration, but Secrets are for sensitive values and are only base64-encoded, not encrypted, by default. Enable encryption at rest in etcd, restrict access with RBAC, avoid committing them to git, and prefer an external manager (Vault, cloud secrets, External Secrets operator) for production.

Fast feedback (build + unit tests on every commit), fail-early quality gates (lint, tests, security/image scans), immutable build artifacts promoted unchanged through environments, and automated deploys with an easy rollback. It should be reproducible and defined as code, so the pipeline itself is versioned and reviewable.

Rolling replaces instances gradually — simple, minimal extra capacity, but a bad release reaches everyone slowly. Blue-green keeps two full environments and flips traffic at once — instant rollback, but double the resources. Canary sends a small percentage to the new version and watches metrics before widening — safest for risky changes, but needs good traffic routing and monitoring.

IaC (Terraform, Ansible) makes infrastructure versioned, reviewable and repeatable instead of hand-clicked and undocumented. Idempotent means applying the same definition repeatedly converges to the same state without duplicating or breaking resources — so you can re-run safely, and drift is corrected rather than compounded.

Metrics (trends and alerting — Prometheus), logs (what happened in detail), and traces (a request's path across services). You alert on metrics, then drill into traces to find the slow or failing hop, then read that service's logs for the exact cause. One without the others leaves blind spots.

kubectl describe pod shows the event: not enough CPU or memory on any node for the requests, a node selector, taint or affinity that no node matches, or a PersistentVolumeClaim that is not bound. Fix the requests, add capacity or adjust the scheduling rules.

What they are checking: Reading scheduler events.

Likely follow-up: What is the difference between taints and node affinity?

Use a slim or distroless base image, multi-stage builds so build tools stay out of the final image, combine and clean up package installs in one layer, and add a .dockerignore so the build context does not copy logs or node_modules.

What they are checking: Practical image hygiene.

Likely follow-up: Why do smaller images also improve security?

Restore service first: roll back (kubectl rollout undo or redeploy the previous version), confirm recovery with monitoring, tell people, then find the cause from logs and the diff, and add a test or check so it cannot happen again. Blameless review afterwards.

What they are checking: Restore first, then root cause.

Likely follow-up: How do canary releases reduce this risk?

The four golden signals: latency, traffic, errors and saturation, plus logs and traces for debugging. Alert on symptoms users feel (error rate, slow responses) rather than every CPU spike, and define SLOs.

What they are checking: SRE basics.

Likely follow-up: What is an error budget?

Make the safe path the easy path: templates, self-service pipelines and clear guardrails. Listen to their pain points, share on-call, and measure improvements such as deploy frequency and lead time together.

What they are checking: DevOps culture.

Likely follow-up: What are the four DORA metrics?