Technical screening questions
Ask for one example per question and listen for specifics.
- How do you design a VPC with public and private subnets? A good answer: Route tables, NAT gateway, security groups and network ACLs.
- How does IAM evaluate permissions? A good answer: Explicit deny, least privilege and roles over long-lived keys.
- How would you reduce an AWS bill? A good answer: Right-sizing, savings plans, storage tiers and removing idle resources.
- How do you make an application highly available? A good answer: Multiple availability zones, load balancing and health checks.
- When do you choose Lambda over EC2? A good answer: Event-driven, short-lived workloads versus long-running services.
Quick screening questions
Use these when you have only a few minutes.
- How do you design IAM for least privilege?
- Describe a VPC layout you designed.
- How do you control cloud cost?
What separates the levels
Match the level to the requirement before you submit.
- Junior: runs resources from templates.
- Mid: builds environments in code.
- Senior: designs multi-account architecture and governance.
Red flags
Any of these is a reason to probe further.
- Console-only experience, no infrastructure as code.
- Cannot explain IAM roles.
- No cost awareness.
Tools you should hear mentioned
An AWS cloud engineer with real experience usually names several of these without prompting.
- EC2, S3, RDS
- VPC and IAM
- CloudFormation or Terraform
- Lambda
- CloudWatch
- Route 53
Run the call well
Ask for the last project first, then dig into the second or third question. Take notes on versions, team size and outcomes, and record them with the submission so the vendor’s later technical interview does not surprise you.
Frequently asked questions
How long should an AWS cloud engineer screening call take?
Fifteen to twenty minutes is enough to cover the project, three technical questions and availability, rate and work authorization.
Do recruiters need to know the technology?
Working vocabulary is enough. Use the sourcing guide for the role and listen for specifics instead of judging technical depth yourself.