AWS solutions architect interview questions and how to answer them

How the interview usually runs

Most AWS-focused architect and cloud engineer loops have the same parts in a different order. A recruiter screen checks salary range, location and whether you can describe your AWS work in plain English. A technical screen, often with an engineer, runs through service fundamentals: VPCs, IAM, storage, databases. A design round gives you a scenario and a whiteboard (or a shared diagram tool) and watches how you ask questions before drawing anything. A behavioural round asks for stories about failures, disagreements and customers. At Amazon itself, behavioural questions map to its published Leadership Principles.

Do not memorise scripts from the answers below. Interviewers follow up on whatever you say, and a memorised paragraph falls apart at the second "why?".

Core services and VPC networking

Testing: whether you can lay out a network from nothing, and whether you think in Availability Zones by default.

Strong answer shape: one VPC with a CIDR block that leaves room to grow, subnets in at least two Availability Zones, and three subnet tiers. Public subnets hold the Application Load Balancer and NAT gateways. Private application subnets hold the EC2 instances or containers. Private data subnets hold the database. Route the public subnets to an internet gateway, and the private subnets to a NAT gateway in the same AZ (one per AZ, so losing an AZ does not cut outbound traffic for the others). Then layer security groups that reference each other: the ALB group allows 443 from the internet, the app group allows traffic only from the ALB group, the database group allows only from the app group.

Testing: a fact every AWS interviewer expects, and whether you understand what stateful means in practice.

Strong answer shape: AWS's own comparison is the cleanest. Security groups work at the instance (network interface) level, support allow rules only, evaluate all rules before deciding, and are stateful, so return traffic is automatically allowed. Network ACLs work at the subnet level, support allow and deny rules, evaluate rules in number order until one matches, and are stateless, so return traffic must be explicitly allowed (which is why custom NACLs need the ephemeral port range open outbound). Add when you use each: security groups as the primary control, NACLs as a coarse subnet guard rail or to block a specific address range.

Testing: methodical troubleshooting along the packet path.

Strong answer shape: follow the traffic outward. Check the private subnet's route table has 0.0.0.0/0 pointing to a NAT gateway. Check that NAT gateway sits in a public subnet whose route table points to an internet gateway. Check the security group allows the outbound traffic, and the NACLs on both subnets allow outbound and the return traffic on ephemeral ports. Check DNS resolution is enabled on the VPC. Confirm with VPC Reachability Analyzer or Flow Logs showing REJECT records.

Testing: whether you know VPC endpoints and see the cost angle.

Strong answer shape: a gateway VPC endpoint for S3, added to the private subnets' route tables. Traffic stays on the AWS network, you can attach an endpoint policy, and the bucket policy can require the aws:SourceVpce condition so the bucket only accepts requests through that endpoint. Mention that it also removes S3 traffic from the NAT gateway, which bills per gigabyte processed. That one sentence tells the interviewer you have seen a real bill.

IAM and security

Testing: whether you would ever put access keys on a server. You would not.

Strong answer shape: attach an IAM role through an instance profile. The SDK picks up temporary credentials from the instance metadata service, and they rotate automatically. Scope the role's policy to the specific actions and resources the app needs (least privilege). For containers on ECS, use a task role; for Lambda, the execution role. Mention requiring IMDSv2 on instances, because it closes off a class of credential-theft attacks through server-side request forgery.

Testing: cross-account access and how policy evaluation combines.

Strong answer shape: two common patterns. Either create a role in your account that the other account's principals can assume (trust policy names their account, permissions policy grants the bucket actions), or add a bucket policy that names the other account's principal. Explain that cross-account access needs permission on both sides: the identity policy in their account and the resource or trust policy in yours. An explicit deny anywhere wins, and service control policies in either organisation can still block the call.

Testing: incident handling under pressure, in the right order.

Strong answer shape: contain, investigate, prevent. Deactivate the key immediately, then delete it once you have confirmed what used it. Search CloudTrail for every call made with that access key ID and look for new IAM users, new keys, launched instances in unusual Regions and changed bucket policies. Revoke or clean up what the attacker created. Then explain prevention: no long-lived user keys for humans (use IAM Identity Center), secret scanning on repositories, and GuardDuty to flag unusual API activity.

Resilience and disaster recovery

Testing: the most common confusion in AWS interviews, and the interviewer knows it.

Strong answer shape: Multi-AZ is for availability. RDS keeps a synchronous standby in another AZ and fails over automatically; AWS says failover for the one-standby deployment completes in as little as 60 seconds, and that standby cannot serve reads. Read replicas are for read scaling. Replication is asynchronous, the replica serves read-only traffic, it can sit in another Region, and you can promote it to a standalone database as part of a disaster recovery plan, accepting some data loss equal to replication lag. The newer Multi-AZ option with two readable standbys blurs the line; mentioning it shows you keep up.

Testing: whether you can connect business requirements to architecture and cost.

Strong answer shape: RPO is how much data loss the business can tolerate, measured back from the failure. RTO is how long it can be down. Then walk the four strategies in AWS's disaster recovery whitepaper from cheapest to most expensive. Backup and restore: back up data and redeploy infrastructure from code when needed, the longest recovery. Pilot light: data replicated continuously to the recovery Region, core infrastructure provisioned, application servers switched off until failover. Warm standby: a scaled-down but fully functional copy running in the recovery Region that can take traffic immediately and scales up. Multi-site active/active: full capacity serving traffic from more than one Region, recovery close to zero for most failures and the highest cost. Finish by asking the interviewer for the RTO and RPO before you pick, and note that data corruption still needs point-in-time backups even in active/active.

Testing: the standard pattern, and whether you know why each piece is there.

Strong answer shape: an Application Load Balancer across at least two AZs, an Auto Scaling group spanning the same AZs with a launch template, ELB health checks so unhealthy instances are replaced, and scaling on a metric tied to load (target tracking on CPU or request count per target). The servers must be stateless, so sessions go to ElastiCache or DynamoDB and uploads go to S3. Name the single points of failure you removed and the one you have left (often the database, handled with Multi-AZ).

Storage and cost

Testing: storage-class knowledge and lifecycle policies.

Strong answer shape: write to S3 Standard. Add a lifecycle rule that transitions objects after a month to Standard-IA or Glacier Instant Retrieval if they still need millisecond access, then to Glacier Flexible Retrieval or Glacier Deep Archive for the long retention, with an expiration action at the end of the retention period. Quote the trade-offs: AWS designs S3 for 11 nines of durability and stores data across a minimum of three AZs by default, One Zone-IA costs 20 percent less than Standard-IA but keeps data in one AZ (only for re-creatable data), and Deep Archive retrieval takes hours, so it suits compliance archives, not anything you might need during an incident. If the access pattern is unknown, S3 Intelligent-Tiering moves objects between tiers automatically for a small monitoring charge. Mention minimum storage duration charges.

Testing: operational cost awareness.

Strong answer shape: open Cost Explorer grouped by service, then by usage type and by tag, and compare month on month to find the line that moved. Check the usual suspects: NAT gateway data processing, inter-AZ and internet data transfer, idle or forgotten resources such as unattached EBS volumes, old snapshots and public IPv4 addresses (AWS now charges for every public IPv4 address, in use or idle; the published rate is $0.005 per hour). Then fix and prevent: rightsizing, Savings Plans for steady compute, lifecycle rules, and AWS Budgets alerts tied to tags so the next jump is caught in days.

Scenario design questions

Testing: event-driven design, decoupling and failure handling.

Strong answer shape: clarify volume, file size and latency first. Then: the client asks an API for a presigned S3 URL and uploads directly to S3, so your servers never carry the file. An S3 event notification goes to an SQS queue; a Lambda function consumes the queue, generates thumbnails and writes them to a second bucket, and records metadata in DynamoDB. A dead-letter queue catches files that fail repeatedly. Serve thumbnails through CloudFront. Then discuss what breaks: very large files (move processing to Fargate) and duplicate events (make processing idempotent).

Testing: migration strategy and cutover planning, very common at AWS partners.

Strong answer shape: decide the strategy per component: rehost (lift and shift with AWS Application Migration Service), replatform (move the database to RDS) or refactor later. For the database, use AWS Database Migration Service with ongoing replication (change data capture) so the target stays in sync while you test. Plan cutover: lower DNS TTLs in advance, freeze writes briefly, let replication catch up, switch Route 53, and keep the old environment ready for rollback.

Testing: judgement. There is no correct pillar; there is a correct way to reason.

Strong answer shape: name all six pillars accurately (operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability). Then give a concrete trade-off: a development environment runs single-AZ with no NAT redundancy because cost matters more than reliability there, while production pays for Multi-AZ. Say who signs off on it. Avoid picking security.

Behavioural questions

Testing: ownership and honesty, and whether you learn from incidents.

Strong answer shape: a real incident, told with the situation, task, action and result (STAR). Spend most of the time on what you did in the first hour and what changed afterwards: a runbook, an alarm, a guard rail in the pipeline. Blameless language, specific numbers if you have them (minutes of downtime, users affected). If you have no production history, use a project incident, and say so plainly.

Testing: the customer-facing half of the architect job.

Strong answer shape: who the person was and what decision they had to make, how you translated the design into cost, risk and time, and what they decided. Bring one sentence you actually used, such as comparing Multi-AZ to a spare generator.

If you are early in your career and the opening question is the hard part, the tell me about yourself answer for IT interviews covers it.

How to prepare in the two weeks before

Use the exam blueprint as a map of what interviewers will probe. The Solutions Architect Associate exam weights secure architectures at 30 percent of scored content, resilient architectures at 26 percent, high-performing at 24 percent and cost-optimised at 20 percent. Spend your preparation in roughly that proportion, with security and resilience first.

Then practise out loud. Draw each diagram on paper and explain it to a timer in under three minutes. Record one run and listen for the moment you hand-wave.

Bring a project. It is far easier to explain a VPC you created than one you read about. Cloud projects for your resume has options ranked by how often they come up in interviews. If you are still landing your first cloud role, getting a job after AWS certification covers which titles to apply for, and the cloud architect career path covers the longer route from engineer to architect.