DevOps Engineer Interview Prep Guide

Structure by stages: 1) Source: monorepo with path-based triggers (only build changed services), 2) Build: Docker multi-stage builds with layer caching, push to container registry with semantic versioning, 3) Test: unit tests per service, integration tests using docker-compose, contract tests between services, 4) Deploy to staging: ArgoCD with GitOps (merge to main updates manifests), blue-green or canary with Flagger, 5) Promotion to prod: manual approval gate, canary rollout with automatic rollback if error rate exceeds SLO, 6) Post-deploy: smoke tests, synthetic monitoring. Discuss branch strategy: trunk-based development with feature flags vs GitFlow.

Show systematic K8s debugging: 1) kubectl get pods to check status and restart count, 2) kubectl describe pod to check events (ImagePullBackOff? OOMKilled? FailedScheduling?), 3) kubectl logs pod-name --previous to see crash logs, 4) Check resource limits: is the container being OOMKilled (exit code 137)? 5) Check liveness/readiness probes: are they misconfigured (wrong port, too aggressive timing)? 6) Check the container image: does it exist? Is the tag correct? 7) exec into the container: kubectl exec -it pod-name -- /bin/sh to investigate filesystem, environment variables, DNS resolution. Cover common causes: misconfigured ConfigMap/Secret, missing environment variables, database connection failures, and insufficient resource requests.

Explain GitOps principles: Git as the single source of truth, declarative desired state, automated reconciliation, and drift detection. Architecture: separate repos for application code and infrastructure manifests. Use ArgoCD or Flux for continuous reconciliation. Environment promotion: dev auto-syncs from main, staging promoted via PR from dev manifests, production promoted via PR with required reviewers. Discuss: Helm vs Kustomize for environment-specific configuration, sealed secrets or external secrets operator for secret management, and how to handle emergencies (break-glass procedures when you need to bypass the GitOps flow).

Walk through all four layers: 1) Cloud: IAM roles with least privilege, VPC network isolation, security groups, encrypted storage, 2) Cluster: RBAC with namespace-scoped roles, network policies (deny-all default, explicit allow), pod security standards (restricted profile), audit logging enabled, 3) Container: scan images for CVEs (Trivy/Snyk), use non-root users, read-only root filesystem, minimal base images (distroless/alpine), 4) Code: secrets management (external secrets operator, never in Git), dependency scanning, SAST/DAST in CI pipeline. Discuss specific tools you have used and how you enforce these policies in production.

Follow the incident response framework: 1) Acknowledge the alert and assess severity (how many users affected? Is there data loss?), 2) Check recent deployments (was there a release in the last 2 hours? Rollback if yes), 3) Check dashboards: the four golden signals across all services, 4) If not deployment-related, check dependencies (database, external APIs, DNS, certificate expiry), 5) Communicate to stakeholders (status page update, Slack incident channel), 6) Mitigate first, diagnose second (scale up, enable circuit breakers, redirect traffic), 7) After resolution: write a blameless postmortem with timeline, root cause, and action items. Discuss SLO/SLI: what is your error budget and has this incident burned through it?

Cover the full lifecycle: 1) Development: .env files in .gitignore, never committed to Git, 2) CI/CD: secrets injected as environment variables from pipeline secret store (GitHub Actions secrets, GitLab CI variables), 3) Production: HashiCorp Vault or AWS Secrets Manager with dynamic secrets that rotate automatically, 4) Kubernetes: External Secrets Operator syncing from Vault/AWS to K8s secrets, mounted as volumes (not env vars for security), 5) Application: SDK reads from mounted secrets file, supports hot-reload on rotation. Discuss: rotation policies (90-day max for static secrets), access auditing, break-glass procedures, and the anti-pattern of storing secrets in ConfigMaps or environment variables visible in kubectl describe.

Terraform: most popular, multi-cloud, large ecosystem of providers, HCL language is approachable. Best for: multi-cloud environments, teams that need provider portability. Pulumi: infrastructure in real programming languages (TypeScript, Python, Go), better for teams that want loops, conditionals, and testing in familiar languages. Best for: teams with strong programming backgrounds who want to avoid HCL. CloudFormation: native AWS integration, no state management needed, supports drift detection natively. Best for: AWS-only environments that want native support and do not want to manage Terraform state. Discuss state management: Terraform remote state in S3 with DynamoDB locking, state file security, and workspace strategies for environments.

Use the STAR format with technical depth: "During a traffic spike on Black Friday, our Kubernetes pods were being OOMKilled because the JVM heap was set to 80% of the container memory limit, leaving no room for non-heap memory. I identified this from container exit codes (137) and Grafana dashboards showing memory climbing linearly. Immediate fix: increased memory limits from 1Gi to 2Gi. Long-term: set JVM MaxRAMPercentage to 50%, added memory pressure alerts at 70%, implemented Horizontal Pod Autoscaler based on memory utilization, and documented JVM-in-container best practices for the team. We added this scenario to our game day exercises."