Can You Answer These 5 SAA-C03 Questions on Design High-Performing Architectures?
This set covers Design High-Performing Architectures, one of the domains of the AWS Solutions Architect – Associate (SAA-C03) exam. About 24% of the exam comes from this domain. Try each question first, then open the answer to see why every option is right or wrong.

AWS Solutions Architect – Associate (SAA-C03) · Design High-Performing Architectures · 5 questions with answers and explanations
📊 Set profile
Exam: SAA-C03 · 65 questions · 130 minutes · passing score 720
This set: 3 advanced, 2 applied · 3 scenario, 1 comparison, 1 troubleshooting
Topics: Amazon CloudFront, AWS Lambda, Amazon DynamoDB, Amazon FSx for Lustre, Amazon S3, Amazon EBS, Amazon Quick Sight
🧭 What these questions look for
This domain hands you a workload with a performance target (a latency budget, a throughput figure, an access pattern) and asks which storage, database, network or analytics service meets it. The wrong options are usually real services that would work, only slower, costlier or built for a different pattern.
Three things to look for
• Read the access pattern before the service names: large sequential reads, a shared POSIX file system and per-request edge logic each point to a different family.
• When a table throttles while its total capacity looks fine, suspect how the keys spread the load rather than the capacity setting.
• Prefer the lightest option that meets the target. If no extra capability is asked for, the simpler and cheaper service is often the intended answer.
Question 1 of 5
A company serves millions of requests per second through Amazon CloudFront. For every request it must rewrite legacy URLs to new paths and add security headers such as Strict-Transport-Security to responses. The logic is simple JavaScript with no network calls. Which solution provides the lowest latency and cost?
Show answer
✅ Answer: C
Difficulty: applied · Topic: Amazon CloudFront, AWS Lambda
Two ways to run code in CloudFront
• CloudFront Functions: JavaScript runtime in all CloudFront edge locations. Viewer request and viewer response events only. Sub-millisecond execution, no network or file system access, small size limits, very low price.
• Lambda@Edge: Node.js or Python in regional edge caches. Viewer and origin events. Up to seconds of runtime, network access, access to the request body.
Which event
• Viewer request/response: runs for every request, including cache hits.
• Origin request/response: runs only when CloudFront goes to the origin (cache misses).
Example
A viewer request function maps /old/article.php?id=42 to /articles/42. A viewer response function adds strict-transport-security: max-age=63072000. For static headers alone, a response headers policy needs no code at all.
Why each option works or fails
• ✗ A. Lambda@Edge on viewer events: it works functionally, but runs in regional edge caches with higher latency and price per request. Its extra power (network calls, longer runtime) is not needed here.
• ✗ B. Lambda@Edge on origin events: origin events run only on cache misses and the result is cached, so this can work, but Lambda@Edge is priced higher per request and per duration than CloudFront Functions and adds more latency to each invocation.
• ✓ C. CloudFront Functions (correct): they run lightweight JavaScript in the edge locations closest to viewers, start in under a millisecond, scale to millions of requests per second, and cost much less than Lambda@Edge. URL rewrites and header changes without network access are their main use case. Security headers can also be added with a response headers policy.
• ✗ D. ALB listener rules: the work happens at the origin, so every request that needs it must first travel from the edge to the Region, and the ALB adds its own processing charges. Code at the edge is closer to viewers and cheaper at this volume.
🎯 Key idea: Simple, high-volume viewer-side changes fit CloudFront Functions; use Lambda@Edge only when you need network access, larger payloads or longer run time.
Question 2 of 5
A DynamoDB table storing daily transaction logs uses the transaction date, such as 2026-09-15, as the partition key. During peak hours, the table experiences frequent ProvisionedThroughputExceededException errors even though the table's overall provisioned capacity has headroom. What is the MOST likely cause?
Show answer
✅ Answer: D
Difficulty: applied · Topic: Amazon DynamoDB
How DynamoDB spreads data
DynamoDB hashes the partition key to decide which physical partition stores an item. Each partition can serve about 3,000 read units and 1,000 write units per second, no matter how much capacity the table has overall.
If most traffic uses one key value, it all lands on one partition. That partition throttles with ProvisionedThroughputExceededException while the others sit idle, which is called a hot partition. Adaptive capacity helps uneven traffic, but it cannot push one key past the per-partition limit.
Fixing a hot key
• Choose a high-cardinality partition key, such as transactionId or accountId.
• Or use write sharding: append a suffix such as 2026-09-15#7 (a random or calculated number from 0 to 9), and query all suffixes when reading a day.
Why each option works or fails
• ✗ A. Regional capacity: DynamoDB does not run out of capacity for a Region in this way. Throttling while the table has headroom points to how the traffic is distributed across keys.
• ✗ B. Streams not enabled: Streams only records item changes for consumers. It plays no part in where items are stored or how writes are spread across partitions.
• ✗ C. Missing sort key: placement is decided by the partition key alone. A sort key orders items inside a partition key value, so adding one would not spread a single date's writes.
• ✓ D. One hot partition key (correct): with the date as the key, every write for the day goes to the single value 2026-09-15, so one partition hits its limit while the table as a whole still has unused capacity.
🎯 Key idea: Throttling with spare table capacity means a hot partition key; use a high-cardinality key or write sharding.
Question 3 of 5
A genomics team runs HPC jobs on hundreds of Linux instances that need a shared POSIX file system with hundreds of GB/s throughput. Input data lives in S3, and results must be written back to S3. Which storage fits BEST?
Show answer
✅ Answer: D
Difficulty: advanced · Topic: Amazon FSx for Lustre, Amazon S3
Amazon FSx for Lustre for HPC
Lustre is a parallel POSIX file system used in high performance computing. FSx for Lustre is the managed version: data is striped across many storage servers, so hundreds or thousands of Linux clients can read and write at the same time with aggregate throughput of hundreds of GB/s and sub-millisecond latency.
S3 integration
An FSx for Lustre file system can be linked to an S3 bucket with a data repository association:
• Objects in S3 appear as files; their content is loaded into the file system on first access (lazy loading) or preloaded.
• New or changed files can be exported back to S3 automatically or on demand.
Example: genome files in s3://genomics-input/ are read through /fsx/input, jobs write to /fsx/results, and results are exported to S3 when the run finishes.
Why each option works or fails
• ✗ A. EBS Multi-Attach: it works only with io1/io2 volumes, attaches to a limited number of instances in one AZ, and needs a cluster-aware file system; it cannot serve hundreds of instances.
• ✗ B. FSx for Windows File Server: it provides SMB shares for Windows workloads, has no native S3 linking, and is not built for Linux HPC throughput at hundreds of GB/s.
• ✗ C. EFS Max I/O with provisioned throughput: EFS is a scalable NFS file system, but it is not designed for hundreds of GB/s aggregate throughput and has no built-in S3 import and export.
• ✓ D. FSx for Lustre linked to S3 (correct): it delivers a shared POSIX file system with the parallel throughput HPC needs and reads inputs from and writes results back to S3 natively.
🎯 Key idea: Linux HPC with massive parallel throughput and S3 data in and out means FSx for Lustre with a data repository association.
Question 4 of 5
A big data job reads large files sequentially from block storage at high throughput, and cost matters. Which EBS type fits?
Show answer
✅ Answer: B
Difficulty: advanced · Topic: Amazon EBS
Throughput versus IOPS
• IOPS counts input/output operations per second and matters for many small random reads and writes, such as databases.
• Throughput measures megabytes per second and matters for large sequential reads, such as scanning log files or big data sets.
The EBS HDD types
• Throughput Optimized HDD (st1): low-cost HDD for frequently accessed, throughput-heavy sequential workloads such as big data, data warehouses and log processing; up to 500 MiB/s per volume.
• Cold HDD (sc1): the lowest cost per GB, for infrequently accessed data; up to 250 MiB/s per volume with lower baseline throughput.
SSD types (gp3, io2) can also be fast, but you pay SSD prices per GB for performance a sequential job does not need.
Why each option works or fails
• ✗ A. Cold HDD (sc1): it is meant for rarely accessed data; its lower baseline throughput makes a job that reads heavily and regularly slower than on st1.
• ✓ B. Throughput Optimized HDD (st1) (correct): it is built for frequently accessed, large sequential reads at high throughput and costs much less per GB than SSD.
• ✗ C. General Purpose SSD (gp3): it works but costs more per GB than st1, and its strength is balanced IOPS rather than cheap sequential throughput for large data sets.
• ✗ D. Provisioned IOPS SSD (io2): it is the most expensive type and pays for random IOPS that a sequential big data job does not use.
🎯 Key idea: Large, frequent sequential reads at low cost means st1; sc1 is for cold data and SSD types pay for IOPS you do not need.
Question 5 of 5
Business users need interactive dashboards on data in Athena and Redshift. Which service fits?
Show answer
✅ Answer: C
Difficulty: advanced · Topic: Amazon Quick Sight
Where BI dashboards fit in an analytics stack
Data is collected (Kinesis, SQS), transformed (Glue), stored and queried (S3 with Athena, Redshift), and finally visualized for business users. The last step needs a business intelligence (BI) tool.
Amazon Quick Sight
Amazon Quick Sight is AWS's managed, serverless BI service.
• It connects directly to data sources such as Athena, Redshift, RDS, S3 and many SaaS sources.
• Data can be queried live or imported into SPICE, its in-memory engine, for fast interactive filtering.
• Authors build analyses and publish dashboards; readers open them in the browser with filters, drill-downs and scheduled reports.
• Dashboards can be embedded in applications and include natural-language questions.
Example: a sales dashboard reads daily order totals from Redshift and clickstream data from Athena, and regional managers filter it by region and week without writing SQL.
Why each option works or fails
• ✗ A. Kinesis Data Streams: it ingests and stores real-time records for consumer applications. It has no visualization or dashboard features.
• ✗ B. Amazon SQS: SQS is a message queue that decouples producers and consumers. It holds messages temporarily and cannot display or analyze data.
• ✓ C. Amazon Quick Sight (correct): a managed BI service that connects to Athena and Redshift and gives business users interactive, shareable dashboards.
• ✗ D. AWS Glue jobs: Glue jobs transform and move data in batch. They prepare data for analysis but provide no interface for business users to explore it.
🎯 Key idea: Dashboards for business users on Athena and Redshift means Quick Sight; Kinesis, SQS and Glue move or prepare data but do not visualize it.
🔗 Keep practicing on this blog
• Can You Answer These 5 SAA-C03 Questions on Design Secure Architectures?
• All SAA-C03 practice sets
• Every exam on this blog
📚 Keep studying SAA-C03
More SAA-C03 questions: https://hyunhp.github.io/cert-bank/#exam=SAA-C03
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=SAA-C03
These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.
Original practice questions written for this blog, not exam dumps.
Comments
Post a Comment