The AWS Solutions Architect Professional is not a knowledge exam, it is a judgement exam. The questions are long, multi-paragraph scenarios that span multiple accounts, large migrations, and the whole AWS platform, and the defining feature is that several of the offered answers will actually work. Your task is almost never to find the one solution that functions; it is to find the one that best satisfies the priority the scenario stated - lowest cost, highest availability, fastest migration, tightest security, or simplest operations. That is why memorising services gets you nowhere near a pass and why real design experience does. This guide is a full, self-study course. It works through each domain in depth, teaches the architecture patterns the exam leans on, drills the technique of reading a scenario for its binding requirement, and then turns all of it into a study plan and a final-preparation routine. It is original teaching material only, with no real or simulated exam questions, and you should confirm the current domains, weights, and scoring against AWS’s own exam page before you book.
Chapter 1: Exam overview and how to use this guide
What the Professional measures, and how it differs from the Associate
The Professional measures whether you can make sound architecture decisions across an entire organisation’s AWS estate, under realistic constraints, when more than one path is defensible. The contrast with the Associate is the key to your preparation. The Associate validates that you can design a solid single system and tends to have a cleaner right answer. The Professional assumes all of that and adds breadth and ambiguity: multiple accounts under one organisation, migrations of whole portfolios, governance and cost and security at scale, and the continuous improvement of systems already in production. Where the Associate asks “which service solves this?”, the Professional asks “given these competing requirements, which design is best, and what are you trading away?”.
Because the scenarios are long and the answers are close, the exam is as much a test of reading and time management as of architecture. A single question can run to a paragraph or two of context, several requirements, and four full-sentence options. The skill that carries you through is disciplined elimination against the requirement that binds, which this guide returns to repeatedly because it is the technique that separates a pass from a near-miss.
The shape of the exam
The exam is 75 multiple-choice and multiple-response questions in 180 minutes, with a pass mark of 750 / 1000 on a scaled scoring system. That is an average of well under two and a half minutes per question, against questions that take longer than that to read carefully, so pacing is a genuine constraint and not an afterthought. There is no longer a requirement to hold the Associate first, but the Associate-level material is assumed throughout, and AWS recommends a couple of years of hands-on experience designing and deploying on AWS before you attempt it. Confirm the current question count, time, and pass mark on the AWS page, since these details are set per exam version.
The four domains
AWS organises the exam into four domains, and the weights tell you where to invest:
- Design Solutions for Organizational Complexity (26%) - designing across multiple accounts: AWS Organizations, cross-account networking, centralised governance, security, and billing, and hybrid connectivity to on-premises.
- Design for New Solutions (29%) - the largest. Turning business requirements into architectures that are reliable, performant, secure, and cost-optimised, including deployment strategies.
- Continuous Improvement for Existing Solutions (25%) - operational excellence and improving the security, reliability, performance, and cost of systems that are already running.
- Accelerate Workload Migration and Modernization (20%) - choosing migration strategies and tools, and modernising toward managed and serverless services.
The two largest domains, new-solution design and organisational complexity, together make up more than half the exam, so they deserve the most study, but the spread is deliberately even and you cannot safely skip any of the four.
The Well-Architected Framework as the scoring rubric
Underpinning every domain is the AWS Well-Architected Framework, and you should treat it as the implicit rubric behind the “best” answer. Its pillars - operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability - are the dimensions the exam trades off against each other. When a scenario prioritises cost, the cost-optimisation pillar is the lens; when it prioritises uptime, reliability is. Much of the exam is really asking which pillar the scenario has made paramount and which design honours it without needlessly sacrificing the others. Holding the pillars in mind is what turns “all of these would work” into a defensible single choice.
How to use this course
Read the chapters in order once. The new-solutions and organisational-complexity chapters establish the patterns - multi-account governance, hybrid networking, resilient design - that the improvement and migration chapters then apply to existing and moving workloads. The technique chapter on reading for the binding requirement is the connective tissue and is worth re-reading before your mocks. The final chapters turn the content into a schedule, a final-preparation routine, and a description of exam day. Worked examples appear where a trade-off is easy to misjudge; none are exam questions, they are teaching illustrations of how to reason.
Chapter 2: Design Solutions for Organizational Complexity (26%)
This domain is about architecture above the level of a single application: how you structure, govern, secure, connect, and pay for many workloads across many accounts. It is one of the two heaviest domains and the one that most clearly separates Professional-level thinking from Associate-level thinking.
What it is, and the multi-account building blocks
At scale, AWS is operated as many accounts rather than one, and the tools to know are the ones that impose order on that sprawl. AWS Organizations is the container that groups accounts and lets you manage them centrally, including consolidated billing. Service Control Policies (SCPs) are organisation-wide guardrails that set the maximum permissions an account can have - they do not grant access, they cap it, which is a distinction the exam tests. AWS Control Tower sets up and governs a secure multi-account landing zone with sensible defaults baked in. For identity at scale, centralised access through AWS IAM Identity Center and cross-account roles lets people and services assume permissions in other accounts without separate credentials everywhere. The recurring design question is how to give teams autonomy in their own accounts while the organisation retains central control over security, compliance, and cost.
Connecting these accounts and the outside world is the networking half of this domain. AWS Transit Gateway is the hub that interconnects many VPCs and on-premises networks without a tangle of peering connections. Hybrid connectivity to on-premises comes through AWS Direct Connect, a dedicated private link, or a VPN over the internet, and the exam expects you to choose between them on bandwidth, latency, consistency, and cost.
Why it matters
This domain matters because organisational complexity is what makes enterprise AWS hard, and it is precisely where good architecture saves an organisation from chaos and breach. Centralising guardrails, security, and billing while preserving team autonomy is a real and difficult balance, and the exam rewards designs that strike it. It is also where the largest, most expensive mistakes live, which is why a quarter of the exam probes it.
How to study it
Study the multi-account patterns until you can place each tool by its job: Organizations and SCPs for structure and guardrails, Control Tower for a governed baseline, Identity Center and cross-account roles for access, Transit Gateway for interconnecting networks, Direct Connect or VPN for hybrid links. Practise reasoning about who should own what: shared services and security tooling often live in dedicated central accounts, while workloads live in their own. As a teaching example: if a scenario needs every account in an organisation to be prevented from using a disallowed Region, the right instrument is a Service Control Policy applied at the organisation or organisational-unit level, because SCPs cap permissions org-wide, whereas an IAM policy in a single account would not bind the others.
Common pitfalls
The first trap is confusing SCPs with IAM policies - SCPs limit the ceiling of what is possible, IAM policies grant specific permissions, and a question will hinge on that difference. The second is reaching for VPC peering when the scenario describes many networks that all need to talk, where Transit Gateway is the scalable answer. The third is forgetting the hybrid trade-off: Direct Connect gives consistent, private bandwidth but takes time and money to provision, while a VPN is quick and cheap but rides the public internet, and the scenario’s emphasis on consistency or speed-to-deploy tells you which it wants.
Chapter 3: Design for New Solutions (29%)
This is the largest domain. It is about taking a set of business requirements and producing an architecture that is reliable, performant, secure, and cost-optimised - in other words, applying the Well-Architected pillars to a fresh design under stated constraints.
What it is, and the design dimensions
A new-solution question gives you requirements and asks for the best architecture, so the work is to satisfy the binding one without breaking the others. Reliability draws on the mechanisms you must know cold: spreading across Availability Zones and, when a Region-wide failure is in scope, across Regions; using load balancing and Auto Scaling for self-healing and elasticity; and choosing data stores with appropriate replication. Performance efficiency is about matching the service to the access pattern - the right compute model (virtual machines, containers, or serverless), the right database for the data shape, caching where reads dominate, and content delivery for global users. Security means least-privilege IAM, encryption at rest and in transit, and network isolation by design. Cost optimisation means choosing the pricing model and service tier that fit the workload’s pattern, and not over-provisioning. Deployment strategies - how new versions are rolled out safely, for instance gradually rather than all at once - also sit here.
Why it matters
This domain matters because designing well from requirements is the core of the architect’s job, and the exam puts the most weight on it for that reason. The difficulty, and the discipline it teaches, is resisting the most powerful or feature-rich option in favour of the one that fits. A design that is more available than the requirement asks, at higher cost, is wrong on this exam just as surely as one that is too fragile, because it fails the cost requirement the scenario set.
How to study it
Practise mapping a requirement to a design dimension and then to a service. “Must handle unpredictable spikes” points to elasticity and serverless or Auto Scaling; “global low latency” points to CloudFront and edge; “strict data residency” points to Region choice and isolation; “lowest cost for steady load” points to a commitment-based pricing model. Train yourself to identify which pillar the scenario has prioritised, because that decides the answer. As a teaching example: if a scenario asks for the most cost-effective design for a workload that runs only a few times a day for short bursts, a serverless approach that charges per execution typically beats keeping instances running, because the binding requirement is cost for an intermittent pattern, and idle servers fail it.
Common pitfalls
The biggest trap is choosing the technically grandest option when the scenario quietly prioritised cost or simplicity. Another is ignoring the deployment and operational angle - a design that cannot be rolled out or operated safely is not the best answer even if it would run. A third is defaulting to one compute model out of habit; the exam expects you to choose virtual machines, containers, or serverless on the merits of the workload, not preference.
Chapter 4: Continuous Improvement for Existing Solutions (25%)
This domain shifts from greenfield design to systems that already run. It is about operational excellence and about improving the security, reliability, performance, and cost of live workloads - the work of making something that exists better rather than building something new.
What it is, and the improvement levers
The questions here describe a running system with a problem or a missed opportunity and ask for the best improvement. The levers mirror the Well-Architected pillars applied to an existing estate. For operational excellence, this means better observability and automation: the monitoring, logging, and automated-remediation tooling that lets an organisation see and fix issues without manual toil. For security, it is closing gaps on live systems - tightening over-broad permissions, adding encryption, centralising audit. For reliability, it is removing single points of failure and adding the redundancy or recovery the current design lacks. For performance, it is finding and relieving the bottleneck - adding caching, changing an instance family, or re-architecting a hot path. For cost, it is right-sizing against real utilisation and choosing pricing models that fit the now-known usage.
Why it matters
This domain matters because most real architecture work is improving what exists, not drawing on a blank page, and the exam reflects that with a full quarter of its weight. It rewards the judgement to diagnose the actual weakness in a running system and apply the proportionate fix, rather than proposing a rebuild when a targeted change would do. That restraint - improve, do not over-rebuild - is exactly what the marks favour.
How to study it
Practise diagnosing before prescribing. For each scenario, name the pillar the current system is failing - is it insecure, unreliable, slow, or wasteful? - and then choose the improvement that addresses that pillar with the least disruption. Lean on the operational tooling: when the gap is visibility or manual effort, the answer usually involves monitoring and automation; when it is drift or compliance, configuration tracking. As a teaching example: if an existing application is reliable and secure but its cloud bill has grown because instances are barely utilised, the right improvement is to right-size against the utilisation data and adopt a pricing model suited to the steady workload, not to re-platform the whole application, because the binding problem is cost efficiency, not architecture.
Common pitfalls
The first trap is over-engineering the fix - proposing a full re-architecture when the scenario’s problem is narrow. The second is treating every problem as the same kind; a performance bottleneck and a cost overrun need different levers, and the exam checks that you diagnose correctly. The third is forgetting that “improve operations” often means adding automation and observability rather than changing the application itself.
Chapter 5: Accelerate Workload Migration and Modernization (20%)
This domain is about moving workloads onto AWS and bringing them up to date once there. It is the smallest of the four but a reliable source of marks if you know the migration vocabulary and the tools, because the questions are pattern-based.
What it is, and the 7 Rs
The framework to know is the 7 Rs, the standard set of migration strategies, and the exam expects you to match a workload to the right one. Rehost (“lift and shift”) moves an application as-is, fastest but least optimised. Replatform makes a few cloud optimisations on the way, such as moving to a managed database. Repurchase swaps to a different, often SaaS, product. Refactor re-architects the application to be cloud-native, slowest but most transformative. Retire decommissions what is no longer needed. Retain leaves a workload where it is for now. Relocate moves infrastructure (such as VMware workloads) without changing it. Each represents a different balance of speed, cost, and long-term benefit, and the scenario’s emphasis tells you which fits.
The tools round out the domain. AWS Application Migration Service handles lift-and-shift of servers, the AWS Database Migration Service (DMS) moves databases (and can convert between engines with the Schema Conversion Tool), AWS DataSync moves large volumes of data, and the AWS Snow Family ships data physically when the network would be too slow. Modernisation then means moving from self-managed to managed and serverless services - for instance, containers on a managed platform, or functions instead of servers - to cut operational burden.
Why it matters
This domain matters because migration is one of the most common reasons organisations hire Professional-level architects, and getting the strategy wrong is expensive in time and money. The exam rewards matching ambition to constraint: a tight deadline favours rehosting, while a mandate to reduce long-term operational cost favours replatforming or refactoring toward managed services. Knowing the tools lets you turn a chosen strategy into a concrete plan.
How to study it
Memorise the 7 Rs by their trade-off, not just their names, and practise placing scenarios on the spectrum from fastest-and-least-optimised to slowest-and-most-transformative. Learn which tool moves what: servers, databases, bulk data, or physical-shipment cases. As a teaching example: if a scenario needs to migrate a large datacentre to AWS quickly with minimal change to the applications, rehosting with the Application Migration Service fits, because the binding constraint is speed with low disruption, whereas refactoring every application would blow the timeline even though it would modernise them more.
Common pitfalls
The first trap is defaulting to refactoring because it is the most “cloud-native” answer, when the scenario’s deadline or budget clearly calls for a faster rehost. The second is misallocating the tools - using a database tool for bulk file transfer, or a network transfer when the data volume and timeline really demand the Snow Family. The third is treating migration and modernisation as one step; sometimes the right answer is to migrate now and modernise later, and the scenario will signal which phase it is asking about.
Chapter 6: Reading the scenario and managing time
The single skill that most determines a Professional result is reading a long scenario for its binding requirement and eliminating against it, fast enough to finish. This chapter is the technique, and it is worth as much as any domain.
Find the binding requirement
Every scenario sets a priority, sometimes openly and sometimes buried in a clause, and that priority is what makes one workable answer better than the others. So read the whole scenario before looking hard at the options, and as you read, hunt for the words that bind: “most cost-effective”, “highest availability”, “least operational overhead”, “fastest”, “most secure”, “with minimal changes”. That phrase is the rubric. Once you have it, the question stops being “which of these works?” and becomes “which of these works and best satisfies this requirement?”, which is a far easier question to answer cleanly.
Eliminate, then choose on the pillar
With the binding requirement in hand, eliminate any option that violates it outright - a costly option when cost is paramount, a single-AZ option when surviving a datacentre failure is required, a slow migration when speed is the constraint. Eliminating to two is usually achievable and turns a four-way guess into a coin you can reason about. Between the survivors, choose the one that best honours the relevant Well-Architected pillar without needless sacrifice elsewhere. As a teaching example of the pattern: when a scenario stresses “least operational overhead”, a fully managed or serverless option usually beats a self-managed one that would also work, because the binding requirement is operational burden and the managed option carries less of it.
Manage the clock
With 75 long questions in 180 minutes, time is a real adversary. Average under two and a half minutes per question, but spend it unevenly on purpose: read efficiently, decide quickly where the answer is clear, and refuse to sink five minutes into one stubborn question early on. Flag the ones you are unsure of, commit a best answer, and move on, returning at the end with whatever time remains. The most common avoidable failure on this exam is not running out of knowledge but running out of clock, so practising at full length until the pace feels natural is not optional. Multiple-response questions state how many answers to select, so honour the count rather than guessing the number.
Chapter 7: Study plan and timeline
With the domains and the technique understood, the work is pacing them realistically on top of the experience this exam assumes. Three things drive the plan: your starting level, the even spread of the domains, and the need to practise long scenarios under time, not just to read.
Be honest about the starting line
This is not a first certification. The realistic path assumes Associate-level knowledge and around two years of hands-on AWS design and deployment experience. With that base, a focused two months of study is a common and reasonable target: an intensive six weeks at roughly twelve hours a week for those who can push, or a ten-week balanced run at around eight hours a week for most. If you are not yet at Associate level, the right move is to build the Solutions Architect Associate and real hands-on time first, because attempting the Professional without that foundation turns the long, judgement-heavy questions into guesswork. Trying to learn the platform and pass this exam at once stretches both too thin.
Work the domains, weighting design and complexity
Spread your hours across all four domains, but weight them toward the two largest - new-solution design (29%) and organisational complexity (26%) - while giving real time to continuous improvement (25%) and a solid pass over migration and modernisation (20%). A balanced shape works through one domain area at a time: new-solution design first, then organisational complexity, then continuous improvement and migration together, then full-length timed mocks and weak-area review. Throughout, ground the patterns in experience: if you can, build a small multi-account setup, connect a network with Transit Gateway, and try a managed-service modernisation, so the patterns are familiar rather than theoretical. To turn whichever timeline you pick into dated weeks for your own start date, use the free study-plan generator.
Practise long scenarios from early, not late
Because the exam is won on reading and judgement, start working long scenario questions as soon as you have covered a domain, not only in the final fortnight. For each one, practise the technique deliberately: find the binding requirement, eliminate against it, and articulate why the best survivor honours the relevant pillar. That reasoning, repeated over weeks, is what builds the speed and judgement the exam rewards. If you are weighing this against the equivalent Azure architecture path before committing, the AWS SA Professional versus Azure AZ-305 comparison sets out how the two architect tracks differ.
Chapter 8: Final preparation, exam day, and format
Final preparation
In the last two to three weeks, shift almost entirely to full-length, timed practice, because pacing across 75 long questions is half the challenge and can only be built by doing it. Treat each mock as both a stamina session and a diagnosis: note which domain leaks marks and which kind of trade-off you misread, then go back and shore up the reasoning rather than only re-reading services. Aim to be scoring comfortably clear of 750 / 1000 on fresh material before you book, and build that from genuine understanding and practice; the exam rewards judgement, and there is no shortcut around having reasoned through many scenarios.
Prerequisites and booking
There is no formal prerequisite - AWS removed the requirement to hold the Associate first - but the Associate-level knowledge and a couple of years of hands-on design experience are genuinely assumed, and the exam is very hard without them. When you book, confirm the current fee (indicatively US$300), the question count, the time, and the pass mark on AWS’s certification page, since these are set per version. The credential is valid for three years, after which you recertify by passing the then-current version or a qualifying exam.
Exam day and format
On the day, you face 75 multiple-choice and multiple-response questions in 180 minutes, taken at a Pearson VUE test centre or through online proctoring, with government-issued identification required. Apply the technique you practised: read each scenario to the end, find the word or clause that binds, eliminate the options that break it, and choose the survivor that best honours the relevant Well-Architected pillar. Watch the clock deliberately - flag and move past the stubborn questions, and return with leftover time rather than letting one question drain your margin. Honour the stated count on multiple-response questions. Having practised at full length until the pace and the length feel ordinary, the format will be familiar rather than punishing, which is exactly the advantage the weeks of scenario practice were meant to build.