Sitonce
Country: US
Show exams for United States Hong Kong
Sign in

AWS Solutions Architect Associate Exam Domains

Updated 8 min read
Key takeaway

The exam has four scored-content domains: Design Secure Architectures (30%), Design Resilient Architectures (26%), Design High-Performing Architectures (24%), and Design Cost-Optimized Architectures (20%).

  • The current guide gives task statements and service references; use them to practise architecture tradeoffs rather than memorize product lists.
On this page8 sections
  1. Current domain weights
  2. Domain 1: Design Secure Architectures
  3. Domain 2: Design Resilient Architectures
  4. Domain 3: Design High-Performing Architectures
  5. Domain 4: Design Cost-Optimized Architectures
  6. The domains overlap in real designs
  7. Study from the exam guide
  8. One workload can test several domains Imagine a media service that stores user uploads, generates previews, and makes them available to customers around the world. Security asks who can upload or read each object and how access is protected. Resilience asks what happens if a component or location fails and how an accidental deletion is recovered. Performance asks how to deliver popular content with acceptable latency. Cost asks whether storage classes and data transfer match access patterns. A good design cannot optimize each domain independently. A cache can reduce repeated origin requests and improve response time, but stale content and invalidation matter. Replication may improve recovery options, but it adds transfer and storage cost. Strong encryption and logging support security, but access to keys and operational ownership also matter. The exam's best answer usually balances the stated priority with other constraints that cannot be ignored. Use a decision table when comparing choices. List each option against the requirement, operational effort, failure behavior and cost effect. Cross out an option that violates a must-have condition before comparing secondary benefits. This avoids choosing a familiar service simply because it appears in the question. Read task statements as observable choices The outline's tasks describe what a candidate may need to do, such as designing secure access, selecting a resilient solution, choosing a performant component, or optimizing cost. Turn each verb into a practice action. For “design,” draw the components and data flow. For “select,” compare alternatives under a fixed constraint. For “determine,” identify the evidence the scenario supplies and what conclusion follows. For example, a high-performing design for read-heavy data may use a read strategy that reduces pressure on the primary store. That choice may add consistency or operational considerations. If the prompt requires the freshest possible value, a cached copy may not satisfy the requirement. A candidate who identifies freshness before naming a service is more likely to select a suitable architecture. Weights are useful for study allocation, not exact question predictions. Security has the highest share at 30 percent, but the candidate still needs a working grasp of resilience, performance and cost. A design question can touch multiple areas, and the score report's domain labels do not turn percentages into a guaranteed count of items.

Current domain weights

DomainWeight of scored contentTypical design focus
Design Secure Architectures30%Identity, network boundaries, data protection, application security
Design Resilient Architectures26%Availability, backup, recovery, fault isolation, scaling
Design High-Performing Architectures24%Compute, storage, database, and network fit
Design Cost-Optimized Architectures20%Resource use, purchasing, storage lifecycle, and operational tradeoffs

These weights apply to scored content. The exam also contains unscored evaluation questions, so a candidate should not convert the percentages into a guaranteed number of displayed items. The exam guide includes detailed task statements and in-scope and out-of-scope services. Use that guide as the boundary for preparation.

Domain 1: Design Secure Architectures

Security is the largest domain. It covers designing secure access, network configurations, application architectures, and data protection. Core reasoning includes identifying the principal that needs access, scoping permissions to the task, separating public-facing and internal components, and protecting sensitive information at rest and in transit.

A common scenario asks how an application should access stored data without exposing broad credentials. Prefer an application role or service identity with least privilege over credentials embedded in source code. Keep data services in appropriate network boundaries and apply logging and encryption controls that fit the requirement.

Security choices also have limits. A private subnet does not by itself create correct authorization; an encrypted object can still be exposed through a permissive policy. A firewall rule does not compensate for an overprivileged identity. Read which layer the question is testing and select controls that work together.

Domain 2: Design Resilient Architectures

Resilience asks how a solution tolerates failures and recovers. Understand Availability Zones, multi-AZ patterns, load balancing, scaling, backups, replication, and recovery objectives. Distinguish keeping a service available during infrastructure failure from restoring data after deletion or corruption.

A design with compute spread across zones may still depend on a single-zone database. A replica can support availability or read scaling but may copy logical errors. A backup is useful only if it can be restored within the required time and with acceptable data loss. Tie the service choice to failure type, recovery time, and recovery point requirements.

Domain 3: Design High-Performing Architectures

Performance design begins with workload behavior: latency, throughput, request patterns, growth, consistency, and data size. Choose compute, database, storage, and networking that suit those characteristics. Caching can reduce repeated reads, but it introduces freshness and invalidation choices. A managed or serverless service can reduce operations, but limits or execution patterns may affect the design.

Storage choices are not interchangeable. Object storage suits durable unstructured objects, block storage supports attached volumes, and shared file storage addresses file-system access by multiple clients. A relational database supports structured relationships and transactions; a key-value database can suit low-latency access by key. Use the stated access pattern rather than choosing the most familiar product.

Domain 4: Design Cost-Optimized Architectures

Cost optimization considers how resources are used and purchased while still meeting business requirements. Compare predictable baseline load with variable demand, storage frequency and duration, data transfer, managed-service operations, and licensing. A cheap option that misses recovery requirements is not optimized for the stated objective.

Storage lifecycle policies can transition data that is rarely accessed to lower-cost classes if retrieval and availability needs permit. Flexible or interruptible capacity can suit workloads that can tolerate interruption; it is a poor fit for a component that must remain continuously available. Commitment options may help predictable use when the terms match actual demand.

The domains overlap in real designs

Consider a photo-sharing service with growing uploads, low-latency browsing, and a requirement to survive a zone failure. Security concerns include private object access, scoped application roles, and data protection. Resilience concerns include redundant application capacity and recoverable metadata. Performance concerns include caching and image delivery. Cost concerns include storage lifecycle and transfer patterns.

The best design depends on the exact constraints. If new images are rarely revisited, a lifecycle policy may reduce storage cost after a defined period. If older images must be retrieved immediately, the lowest-cost archival tier may be unsuitable. A cache can improve browsing speed but should not be treated as the durable source of truth. A multi-zone application with a single-zone metadata database remains vulnerable to that database’s failure.

This is how to approach exam scenarios: identify the primary requirement, find the limiting condition, compare the architecture choices, and reject options that solve one domain while breaking another. A cost improvement that creates unacceptable latency is not the best answer when response time is mandatory.

Study from the exam guide

Use the current AWS exam guide’s task statements and service references. It identifies technologies and services in scope as well as those outside the exam boundary. Service coverage changes over time, so avoid relying on old lists copied into notes or third-party course pages without checking their alignment.

For each task, write one architecture decision and its tradeoff. For example, compare multi-AZ versus multi-region recovery; object storage versus shared file storage; relational versus key-value data; on-demand versus committed or interruptible compute. Include what requirement would make the alternative better. This makes practice more transferable than a service flashcard alone.

One workload can test several domains Imagine a media service that stores user uploads, generates previews, and makes them available to customers around the world. Security asks who can upload or read each object and how access is protected. Resilience asks what happens if a component or location fails and how an accidental deletion is recovered. Performance asks how to deliver popular content with acceptable latency. Cost asks whether storage classes and data transfer match access patterns. A good design cannot optimize each domain independently. A cache can reduce repeated origin requests and improve response time, but stale content and invalidation matter. Replication may improve recovery options, but it adds transfer and storage cost. Strong encryption and logging support security, but access to keys and operational ownership also matter. The exam's best answer usually balances the stated priority with other constraints that cannot be ignored. Use a decision table when comparing choices. List each option against the requirement, operational effort, failure behavior and cost effect. Cross out an option that violates a must-have condition before comparing secondary benefits. This avoids choosing a familiar service simply because it appears in the question. Read task statements as observable choices The outline's tasks describe what a candidate may need to do, such as designing secure access, selecting a resilient solution, choosing a performant component, or optimizing cost. Turn each verb into a practice action. For “design,” draw the components and data flow. For “select,” compare alternatives under a fixed constraint. For “determine,” identify the evidence the scenario supplies and what conclusion follows. For example, a high-performing design for read-heavy data may use a read strategy that reduces pressure on the primary store. That choice may add consistency or operational considerations. If the prompt requires the freshest possible value, a cached copy may not satisfy the requirement. A candidate who identifies freshness before naming a service is more likely to select a suitable architecture. Weights are useful for study allocation, not exact question predictions. Security has the highest share at 30 percent, but the candidate still needs a working grasp of resilience, performance and cost. A design question can touch multiple areas, and the score report's domain labels do not turn percentages into a guaranteed count of items.

Common questions

Which domain is largest?

Design Secure Architectures at 30 percent of scored content.

Are the percentages exact question counts?

No. They are scored-content weights, not fixed counts on an individual form.

Does the guide list in-scope services?

Yes. It includes in-scope and out-of-scope service references.

Do I need to pass each domain?

No. AWS uses an overall compensatory scoring model.