Cloud, DevOps & SRE Engineer Interview Guide: CI/CD, Kubernetes, Terraform & Incident Response

Kubernetes Objects You Must Explain Without Notes

A Pod is the smallest deployable unit and holds one or more containers sharing network and storage. A Deployment manages ReplicaSets to give declarative rolling updates and rollbacks. A Service gives a stable virtual IP and DNS name to a changing set of Pods. An Ingress routes external HTTP traffic to Services. ConfigMaps and Secrets inject configuration. Liveness probes restart a stuck container; readiness probes remove a Pod from Service endpoints until it is ready. Resource requests drive scheduling while limits cap usage and can trigger OOMKills.

• Debug flow for a CrashLoopBackOff: kubectl describe pod, kubectl logs --previous, check probes, resource limits, config and image tag
• Know the difference between a StatefulSet (stable identity, ordered rollout) and a Deployment
• Explain HPA (scales Pods on metrics) versus Cluster Autoscaler (scales nodes)

Terraform State, Modules and Drift

Terraform describes desired infrastructure declaratively; the state file maps your code to real resources. Store state remotely (for example S3 with DynamoDB locking) so teams cannot corrupt it concurrently. Use modules for reuse, workspaces or separate state per environment for isolation, and run terraform plan in CI so changes are reviewed before apply. Drift occurs when someone changes resources manually; detect it with plan and prevent it with restricted console access.

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan   # reviewed in pull request
terraform apply tfplan       # run by pipeline only

A Calm Incident Response Playbook

Step 1: Acknowledge and declare severity. Step 2: Mitigate first (rollback, failover, feature flag off) before hunting root cause. Step 3: Communicate on a fixed cadence to stakeholders. Step 4: Confirm recovery with the same SLIs that detected the problem. Step 5: Write a blameless post-mortem with timeline, contributing factors and tracked action items.

• Metrics, logs and traces are the three pillars of observability; alerts should fire on symptoms users feel, not every internal cause
• Use the RED method for services (Rate, Errors, Duration) and USE for resources (Utilization, Saturation, Errors)