Rost CAMP

AWS Solutions Architect Interview Questions

By Rostyslav Myronenko, holder of 14 active AWS certifications.
. 10 min read

Most lists of AWS solutions architect interview questions pair each question with a definition. The interviewer already knows the definition. What goes on the scorecard is the reason you give and what you say the choice costs.

Below are eight scenario questions that recur in published AWS interview lists. For each one there's a weak answer and what the interviewer listens for. After them come the gap between exam answers and interview answers, a worked design, and five mistakes that cost strong candidates the offer. Like the system design interview questions post, everything here is graded on five signals: requirements, data model, scaling story, trade-offs and communication. The questions come from published lists, and none is taken from any company's interview loop.

How a solutions architect loop is usually structured

Most published descriptions of solutions architect hiring describe four rounds. Not every company runs all four, and the names vary.

  1. Recruiter screen. Your background, what you're looking for, logistics. Practise a 90-second version of your background instead of reading your CV aloud.
  2. Technical deep dive. One or two engineers probe one area (networking, IAM, storage, data) until they find the edge of what you know. Most of the questions below live here.
  3. Architecture or system design. A vague prompt that you sharpen, then design. It's graded on structure, trade-offs and how you handle a requirement that changes halfway.
  4. Behavioural. "Tell me about a time" stories. Amazon maps them to its published Leadership Principles. Other companies use their own rubric.
A solutions architect loop: screen, technical deep dive, design and behavioural rounds, each grading something differentScreenBackground,motivationDeep diveOne area,to the edgeDesignStructure andtrade-offsBehaviouralStories withevidence
The four rounds most published descriptions of a solutions architect loop share, and what each one mostly grades. Not every company runs all four.

Cloud engineer and cloud architect loops follow much the same pattern. The AWS interview questions post covers the broader set, including the operational questions that cloud engineer roles add.

Eight AWS solutions architect interview questions

Each question below follows the same pattern: the prompt, what a weak answer sounds like, and what gets graded.

1. Trace a request into a private subnet

"You have a load balancer, app servers in private subnets and a database. Walk me through how a request from the internet reaches an instance and how the response gets back."

A weak answer lists the parts (internet gateway, NAT gateway, security groups) without ever tracing a path, and treats a network ACL as if it worked like a security group.

What gets graded is the path, out loud: internet gateway, the Application Load Balancer in the public subnets, the instance's security group, the instance in a private subnet. Candidates separate on the return path. Security groups are stateful, so return traffic is allowed automatically. Network ACLs are stateless, so the response needs its own rule on the client's ephemeral ports, and AWS suggests opening 1024–65535 to cover the different clients (network ACLs). Calls from the instance out to the internet go through a NAT gateway. A zonal NAT gateway sits in one Availability Zone, so you need one per zone to survive a zone failure. A regional NAT gateway spreads across zones by itself (regional NAT gateways).

2. Give a Lambda function access to one S3 prefix

"A Lambda function needs to read objects under one prefix in an S3 bucket. How do you set that up?"

The weak answer: create an IAM user, generate an access key, attach AmazonS3FullAccess. An interviewer will read that as someone who has never owned a production account.

What gets graded: an execution role, so there are no long-lived keys to leak or rotate. A policy that allows s3:GetObject on that prefix's ARN, with no wildcard the job doesn't need. Then how evaluation works. Inside one account, an allow in either the role's policy or the bucket policy is enough. Across accounts, both have to allow it (cross-account evaluation), and an explicit deny anywhere wins. Mentioning IAM Access Analyzer or permissions boundaries helps only if you can say what problem each one solves (IAM best practices).

3. Store 400 TB of logs that almost nobody reads

"A team keeps 400 TB of logs they almost never open. Design the storage."

The weak answer: "Put it in S3 Standard. S3 is cheap."

What gets graded is a lifecycle policy with a reason behind each step: S3 Standard while the logs are fresh, then Standard-IA, then one of the Glacier classes depending on how fast someone might need the data back. The strong answer knows the minimums. Standard-IA bills at least 30 days, Glacier Instant Retrieval and Flexible Retrieval 90, and Deep Archive 180. Standard-IA and Glacier Instant Retrieval bill any object under 128 KB as 128 KB (storage classes). Moving millions of small log files too early can cost more than it saves. The transitions themselves are lifecycle rules (lifecycle management). If nobody knows the access pattern, S3 Intelligent-Tiering is an honest answer.

4. EC2, Lambda or containers for a steady internal API

"You're moving an internal API with steady traffic to AWS. EC2, Lambda or containers?"

The weak answer: "Lambda. It's serverless, so it's cheaper and it scales."

What gets graded is a workload profile before a service: requests per second, how long each request runs, the latency target, how much a cold start matters. Lambda bills per request and per unit of duration (Lambda pricing), so it tends to win on spiky, low traffic. For steady high traffic, a container or an instance can come out cheaper. The strong answer then separates ECS on Fargate, which means no servers to manage, from EKS, which you choose when you actually need Kubernetes and its tooling. It also says what would make you switch.

5. RDS or DynamoDB for spiky traffic

"Design the data layer for an app with unpredictable traffic spikes and single-digit-millisecond reads."

The weak answer: "DynamoDB, because it scales."

What gets graded: access patterns first. With DynamoDB, the partition key decides whether the table scales at all, and one hot key gets throttled however much capacity you buy. RDS fits joins, multi-row transactions and ad hoc reporting. Then availability, which candidates often blur. A Multi-AZ DB instance keeps a synchronous standby that serves no reads, and failover typically takes 60–120 seconds (RDS failover). A read replica is asynchronous and exists to serve reads (Multi-AZ deployments).

6. Survive a Region outage

"The CEO wants the application to survive a full Region outage. What's the plan, and what does it cost?"

The weak answer: "Turn on Multi-AZ and add a replica in another Region."

What gets graded: Multi-AZ protects against a zone failure, not a Region failure. Next come RTO and RPO as numbers, and then the four strategies AWS describes: backup and restore, pilot light, warm standby, and multi-site active/active (disaster recovery options). Aurora Global Database replicates to secondary Regions with latency typically under a second (Aurora Global Database). Route 53 health checks can drive the failover. Finish on cost: warm standby and active/active run a second copy of the system every month, and the interviewer wants you to say so before they ask.

7. Cut 30% from the bill without hurting reliability

"You need to take 30% off an AWS bill without making the system less reliable. Where do you start?"

The weak answer: "Buy Reserved Instances."

What gets graded is an order of work. First find where the money goes, with Cost Explorer and the Cost and Usage Report. Then rightsize, and only then commit, with Savings Plans for flexibility. Storage lifecycle and idle resources come next. Cost optimization is one of the six Well-Architected pillars, alongside reliability (the pillars), so the strong answer looks for reliability the system pays for and doesn't need, and leaves the rest alone. The AWS cost optimization post sets out that order in full.

8. Decide what happens to 200 on-premises VMs

"You inherit 200 virtual machines in a data centre. How do you decide what moves, and how?"

The weak answer: "Lift and shift everything, then optimise later."

What gets graded is applying the 7 Rs to the estate: retire, retain, rehost, relocate, repurchase, replatform, refactor (migration strategies). Retire what nobody uses, retain what can't move yet, repurchase where a SaaS product replaces it, and refactor only where it pays back. AWS's own guidance for large migrations is to rehost, relocate or replatform first and modernise afterwards, because refactoring during the move is the most complex option. Then cover discovery, dependency mapping and moving in waves.

Certification answers vs interview answers

The exam rewards recall: which service does which job. The interview rewards judgement. Here is one topic asked both ways.

The exam asks: "Which storage class is cheapest for long-term archive?" Deep Archive. Correct, next question.

The interview asks: "Compliance data has sat in Deep Archive for a year. Legal needs 500 GB of it by tomorrow morning. What happens?"

There's no single fact to recall here. Deep Archive has no Expedited retrieval. A Standard retrieval typically finishes within 12 hours and Bulk within 48 (retrieval options), so Standard meets the deadline if the request goes in now. The restore creates a temporary copy for the number of days you set, and you pay for both the archive and the copy while it exists (restoring objects). Then comes the prevention: if Legal can ever need this data within hours, the lifecycle rule should have kept it in Glacier Flexible Retrieval or Instant Retrieval.

The interview moves you from "which service" to "what happens when it goes wrong, what it costs, and what you'd change", and an exam never asks that. If you're still choosing which exam to sit, the AWS certification path lists them by level and role.

A worked design: photo upload and viewing

"Design a service where users upload photos and other users view them." Split the round the way the 45-minute time budget does.

  • Requirements. Mobile or web? How many daily users? What's the read-to-write ratio? How fast must a photo load? How long are photos kept? Two or three of these answers change the design.
  • Estimate. Say 500,000 uploads a day at about 2 MB each. That's about 1 TB a day and 30 TB a month, which points straight at S3.
  • High level. The client asks the API for a pre-signed URL and uploads the original to S3. An S3 event goes to SQS, a Lambda function makes thumbnails, DynamoDB holds the metadata, and CloudFront serves the reads.
  • Deep dive. Pre-signed URLs keep upload traffic off your API. The queue between upload and processing means a failed thumbnail never loses the photo. Metadata is keyed so one popular account doesn't become a hot partition. CloudFront keeps most reads away from S3.
  • Trade-offs. What breaks if the Region goes down? What does this cost at ten times the traffic? When would thumbnailing move to containers?

The interviewer grades whether you drove the problem, put numbers on it and named what you'd give up, and a mock system design interview is where you practise that.

Five mistakes that cost strong candidates the offer

  1. Answering the question instead of the problem. "What is a NAT gateway?" is really a question about egress, cost and zone failure.
  2. Listing services instead of choosing one. "You could use Lambda, Fargate or EC2" is not an answer. Pick one, say why, and say what would change your mind.
  3. Assuming the scale. Designing for a billion users when the brief said five thousand is as wrong as the reverse. Ask, then size.
  4. Never naming a failure mode or a cost. Every real architecture has a weak point and a bill.
  5. Vague behavioural stories. "We collaborated well" scores nothing. Give the situation, what you did yourself and the result you measured. Two or three sharp stories beat ten loose ones.

FAQ

What AWS questions come up in a solutions architect interview?

Mostly short design scenarios: making a web application highly available, choosing between S3, EBS and EFS or between DynamoDB and RDS, designing a VPC, cross-account access with IAM roles, SQS, SNS or EventBridge, multi-Region disaster recovery, and cutting the cost of an architecture. Each answer is graded on the reason you give for the service you pick.

How many questions are in an AWS solutions architect technical round?

Fewer than the long lists suggest. A deep dive usually covers a handful of topics, and each one gets follow-ups that go two or three layers down. Ten questions you can defend under follow-ups are worth more than a hundred you can recite.

Do I need the AWS Solutions Architect – Associate certification to get hired?

It helps you past a CV screen, but the interview tests something else. The exam checks that you know what each service does. The interview checks whether you can choose between services for one workload and say what the choice costs.

How do senior solutions architect interviews differ from junior ones?

Junior rounds ask how a service works and when you'd use it. Senior rounds ask you to defend a decision against the alternatives, with cost, compliance and failure modes in the picture, and to say what you'd change with hindsight.

How long should my answers be?

Thirty to sixty seconds for a direct question, then stop and let the interviewer steer. A two-minute answer to a question nobody asked eats the time you need for the follow-ups.

Practising the answers out loud

Answers get fluent when you say them out loud. Pick three questions, answer each out loud for five minutes, record it, and note every place you waved your hands. The system design interview prep post has a four-week plan and a rubric for scoring yourself.

In a coaching mock I run an architecture round against the clock, score it on the five signals and send you the written scorecard within a day. Sessions run on weekday evenings and at weekends, in English or Ukrainian.

More on interviews and exams