Cloud Support / DevOps Engineer Interview Experience at AWS – 2025

Standard recruiter screen covering background, current role, and motivation for the move. Recruiters typically ask candidates to walk through their last two years in chronological order, focusing specifically on which parts of the infrastructure they owned end to end versus which they supported as part of a larger team. Recruiters also ask directly why the candidate is looking to leave their current role, and push back on generic answers ('looking for growth'), asking for one specific thing the current company cannot offer that AWS can. This is consistent with what most candidates report as a straightforward but not purely conversational first step at AWS - the recruiter is screening for specificity, not just enthusiasm.

A mix of AWS core-service multiple choice questions and a scripting problem, timed at 60 minutes total. The MCQ section covers roughly 20 questions spanning EC2 instance types and pricing models, S3 storage classes and lifecycle rules, and IAM policy evaluation logic (specifically, how an explicit deny in one policy overrides an allow in another attached to the same role). The scripting problem asks candidates to write a Bash script that scans a directory of log files, extracts all lines matching a 5xx HTTP status code, and outputs a count grouped by the originating service name embedded in the filename. A clean solution combines grep, awk, and sort | uniq -c; a common pitfall is an off-by-one error in field extraction on the first attempt.

This round opens with VPC architecture questions: how a private subnet actually reaches the internet through a NAT gateway versus why a public subnet only needs an internet gateway, and what specifically breaks if a route table is missing the 0.0.0.0/0 route. From there the interviewer moves into a live-style Docker and Kubernetes troubleshooting scenario: a pod described as CrashLoopBackOff, with candidates asked to walk through their diagnostic order - checking `kubectl describe pod` for events first, then container logs, then confirming whether the issue is an application crash versus a failed liveness probe misconfigured with too short a timeout. The round closes with CI/CD pipeline design questions, specifically how to structure a pipeline so that a failed integration test blocks deployment to production but does not block deployment to a staging environment.

The hardest round of the loop. It opens with a Terraform scenario: two engineers running `terraform apply` on the same state file within minutes of each other, and candidates are asked to explain exactly what happens without remote state locking (a corrupted or inconsistent state file, potentially silently) versus with an S3 backend plus DynamoDB-based locking (the second apply blocks until the first completes). The interviewer then pushes into a real incident management scenario: a service is returning elevated 5xx errors during a traffic spike, and candidates must talk through the full response - checking CloudWatch dashboards for CPU, memory, and ALB error rates first, considering whether to manually bump Auto Scaling Group desired capacity as an immediate lever, and only then investigating root cause once the immediate customer impact is contained. Candidates are specifically asked to justify the order they chose, not just list the steps.