AWS interview questions: how to prepare properly

The typical shape of a cloud interview

Most AWS-adjacent interview processes follow a recognisable arc, even though every company dresses it differently. It usually opens with a screening call — a recruiter or hiring manager checking your background matches the advert and that you can talk coherently about what you have done. Then comes a technical or scenario round, where an engineer asks you to explain concepts and reason through situations. Senior processes add an architecture or troubleshooting discussion — a whiteboard-style conversation where you design something or diagnose a described failure. And almost every process includes a behavioural round about how you work: outages you have handled, mistakes you have made, disagreements you have navigated.

Knowing the shape matters because each round rewards different preparation. The screening call rewards a clear, honest account of your experience. The technical round rewards fundamentals explained in plain language. The architecture discussion rewards trade-off reasoning and asking clarifying questions before answering. The behavioural round rewards specific true stories, prepared in advance so you are not improvising them under pressure.

The four categories of question, with real examples

Nearly every technical question you will meet falls into one of four categories, and practising by category is far more efficient than practising random questions. Examples worth writing out answers to:

• Fundamentals — “Explain the shared responsibility model.” “What is an Availability Zone, and why does it matter where you place resources?” “What is the difference between scaling up and scaling out?” These check you understand the platform’s basic physics.
• Scenario and design — “How would you make this application highly available?” “How would you reduce this workload’s cost without hurting performance?” “A team wants to serve users in another continent — what changes?” These check you can apply fundamentals to a situation.
• Troubleshooting — “An EC2 instance is unreachable — how do you diagnose it?” “Users report the site is slow but the servers look healthy — where do you look?” These check whether you have a method, not whether you guess the culprit.
• Behavioural — “Tell me about an outage you were involved in.” “Tell me about a mistake you made and what changed afterwards.” “Describe a time you disagreed with a technical decision.” These check honesty, ownership and how you operate with other people.

How to answer well: requirement, trade-off, choice, monitoring

Strong answers to scenario questions share a structure, and it is learnable. First, state the requirement — restate what actually matters before proposing anything (“high availability here means surviving the loss of an Availability Zone without users noticing”). Second, name the trade-off — every real design decision costs something, and saying so out loud is what separates reasoning from recitation (“running in multiple zones improves resilience but raises cost and complexity”). Third, justify the choice for this situation, not in the abstract. Fourth, mention what you would monitor — saying how you would know the design is working signals operational maturity that trivia answers never do.

For troubleshooting questions, the equivalent structure is a method: check the layers in order, say what you would look at and what each finding would tell you, and narrow systematically rather than leaping to a favourite cause. Interviewers are listening for the process. An answer that works through “is it network reachability, is it the security group, is it the instance itself, is it the application” calmly beats one that happens to guess the right cause immediately.

The questions candidates fluff

The questions that most reliably expose thin preparation begin with “why did you choose”. Why did you choose that database? Why serverless rather than containers? Why that region? Memorised answers collapse here, because the honest answer requires having actually made the decision — or at least having thought it through as though you did. If your project used a service because a tutorial did, say so, and then show you have since understood the decision: what the alternative was, what would have made you pick it instead. That recovery is genuinely impressive; bluffing is genuinely obvious.

The other common stumble is the negative-space question: “What are the downsides of the approach you just described?” Candidates who have only rehearsed advantages freeze. Practise attacking your own designs — every architecture you can describe, you should also be able to criticise. If you cannot name a weakness in your own project, an interviewer will conclude you do not understand it deeply, and they will usually be right.

Projects are where answers come from

The single best interview preparation is having built something, because a real project converts abstract questions into concrete ones you have already answered. “How would you secure an S3 bucket?” is a memory test until you have actually locked one down, at which point it becomes a story: what you configured, what you got wrong first, how you checked it. Behavioural questions work the same way — “tell me about a mistake” is easy when you genuinely broke something in your own environment and fixed it.

Before the interview, walk back through whatever you have built — work systems or personal projects — and write down the decisions inside them: what you chose, what you rejected, what it cost, what you would do differently now. That document is your answer bank. Our guide on AWS portfolio projects that get you hired covers what to build; the interview-preparation point is that building it is only half the value — being able to narrate the decisions is the other half.

Prepare questions to ask them

The interview ends with “do you have any questions for us?”, and having none reads as indifference. Good questions also work in your favour twice: they show how you think, and they surface information you genuinely need before accepting an offer. Ask about the things that will define your working life — how the team deploys and how often, who carries on-call and how incidents are run, what the current architecture’s biggest pain point is, how the team decides between building and buying, and what a successful first six months in the role looks like.

Avoid questions whose answers are on the company website, and avoid saving compensation negotiation for this moment — that conversation belongs with the recruiter. One honest closing note: interview processes vary enormously between companies, and no article can promise you the exact questions. What the categories, the structure and a well-understood project give you is the ability to handle whatever variant arrives — which is precisely the skill the interview is testing.