What AWS Knowledge Do DevOps and Platform Engineering Interviews Really Test?

Some interviewers absolutely still ask questions such as the difference between Fargate and EC2, ECS and EKS, or how a packet moves through a VPC. Others use live troubleshooting, architecture diagrams, or Terraform reviews. You may even encounter irrelevant coding exercises, so broad preparation is sensible.

For networking, focus on a repeatable debugging process: confirm DNS, inspect the source and destination, check route tables, security groups, network ACLs, gateways, and application-level behavior. For IAM, understand role assumption, workload credentials, trust relationships, and least privilege. For design questions, connect every choice to reliability, security, scalability, operability, and cost.

Expect both practical scenarios and some trivia. Interview quality varies, so it is worth preparing for direct service questions while prioritizing the ability to apply those services in real designs.

A typical discussion might start with an application and ask where it runs, how traffic enters, how TLS and DNS work, how deployments and rollbacks happen, where logs and metrics go, how permissions are granted, and what happens during a failure. You may also be asked about encryption at rest and in transit, KMS, maintenance windows, Infrastructure as Code, or the five AWS services you know best.

You do not need to know every AWS feature. Be honest about gaps, ask clarifying questions, and explain how you would find the answer. Interviewers often value sound judgment and practical familiarity more than pretending to know everything.

A useful design exercise is to host a containerized web application with a frontend, backend, and MySQL database in a resilient way. Explain the public entry point, DNS, TLS, load balancing, private and public subnets, container platform, database placement, scaling, secrets, IAM, monitoring, deployment strategy, and rollback plan.

Then challenge your own design: what happens if an instance or availability zone fails, how would you avoid a single database failure, and what would you change to reduce cost? The goal is not to choose the fanciest service. It is to show that you can build something reliable and maintainable while understanding the trade-offs.

At the mid-level, strong interviews usually focus on scenario-based reasoning rather than memorizing service limits. You might be given a broken architecture and asked what fails first, how you would make it multi-AZ, or what changes at ten times the traffic.

IAM is often examined in more depth because mistakes there are dangerous. Be ready to explain STS and role assumption, how workloads obtain credentials, why long-lived keys are risky, and how trust policies differ from permission policies.

Networking questions are commonly framed as debugging: traffic cannot get from one component to another, so explain how you would inspect routes, security groups, network ACLs, subnet placement, and NAT. Cost and operational trade-offs also matter, such as choosing Fargate versus EC2 or ECS versus EKS.

The best answers explain how you would investigate and validate assumptions, not just recite facts. Prepare one incident or production problem you handled from detection through resolution. Since your background is in Azure, clearly explain equivalent concepts such as VNet and VPC or VM Scale Sets and Auto Scaling Groups; that demonstrates transferable understanding.