DevOps Engineering Professional Program interview questions & answers

A VM virtualises 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.