Free AWS SAA-C03 Practice Questions: Design High-Performing Architectures

Topic snapshot

How to use this topic drill

Use this page to isolate Design High-Performing Architectures for AWS SAA-C03. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.

Pass	What to do	What to record
First attempt	Answer without checking the explanation first.	The fact, rule, calculation, or judgment point that controlled your answer.
Review	Read the explanation even when you were correct.	Why the best answer is stronger than the closest distractor.
Repair	Repeat only missed or uncertain items after a short break.	The pattern behind misses, not the answer letter.
Transfer	Return to mixed practice once the topic feels stable.	Whether the same skill holds up when the topic is no longer obvious.

Blueprint context: 24% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official AWS questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.

Question 1

Topic: Design High-Performing Architectures

An analytics team uses Amazon Athena to query 2 years of CSV log files stored in an Amazon S3 data lake. Each query filters on an event_date column and selects only a few columns out of more than 200, but queries are slow and scan large amounts of data. Producers must continue writing CSV files to S3, and the company does not want to run database servers. Which solutions will meet these requirements and significantly improve query performance? (Select THREE.)

Options:

• A. Use an AWS Glue ETL job to convert the CSV files in S3 into Snappy-compressed Parquet files partitioned by event_date in a new S3 prefix, and create a new Athena table over the Parquet data.

• B. Use AWS Glue to convert the CSV files in S3 into JSON files in S3, and update Athena to query the JSON data instead of the CSV files.

• C. Load the CSV files from S3 into an Amazon RDS for PostgreSQL DB instance, create indexes on frequently filtered columns, and run analytic queries against the RDS database instead of Athena.

• D. In Amazon Athena, run a CREATE TABLE AS SELECT (CTAS) query on the existing CSV table to materialize the data as Snappy-compressed, event_date-partitioned Parquet files in S3, and have analysts query the new Parquet table.

• E. Continue querying the CSV files in S3 with Athena, but request a higher Athena query concurrency limit and use larger workgroups to reduce query run times.

• F. Run an Amazon EMR cluster with Apache Spark to read CSV files from S3 and write them back as compressed, event_date-partitioned Parquet files in S3, then point Athena to the Parquet location for analytics queries.

Correct answers: A, D and F

Explanation: The scenario describes wide tables (more than 200 columns), analytical queries that filter on event_date, and a need to keep data in an S3 data lake while leaving existing CSV-producing applications unchanged. The core performance problem is that Athena must scan entire CSV rows on every query, even when only a handful of columns are needed.

Columnar formats such as Parquet store data by column instead of by row. When combined with compression and partitioning (for example, by event_date), columnar storage allows Athena to read only the relevant columns and partitions. This can dramatically reduce the number of bytes scanned and improve query latency and cost.

The best answers are the options that convert the existing CSV data in S3 into compressed, partitioned Parquet files, while keeping producers unchanged and avoiding database servers.

• ✔ Use an AWS Glue ETL job to convert CSV in S3 to compressed, partitioned Parquet and query with Athena.
• ✔ Use an Amazon EMR Spark job to rewrite CSV to compressed, partitioned Parquet in S3 and query with Athena.
• ✔ Use Athena CTAS to materialize the CSV table as compressed, partitioned Parquet in S3 and query the new table.
• ✖ Load CSV into Amazon RDS for PostgreSQL and query there.
• ✖ Increase Athena concurrency and workgroup size while continuing to query CSV.
• ✖ Convert CSV to JSON in S3 and query JSON with Athena.

---

Question 2

Topic: Design High-Performing Architectures

Which of the following statements about building an Amazon S3–based data lake using AWS Lake Formation and the AWS Glue Data Catalog are true? (Select THREE.)

Options:

• A. The AWS Glue Data Catalog stores schema metadata (tables, columns, and partitions) for data in Amazon S3 so multiple analytics services can query the same data without copying it.

• B. Using AWS Lake Formation requires routing all access to the S3 data lake through a single Lake Formation–managed VPC endpoint; direct S3 access from other networks is not supported.

• C. Storing data in open, columnar formats such as Apache Parquet and partitioning S3 objects by commonly filtered fields (for example, date) can significantly improve query performance and reduce scan costs for services like Amazon Athena.

• D. AWS Lake Formation can enforce fine-grained permissions (such as table- and column-level access) for integrated services like Amazon Athena and Amazon Redshift Spectrum, reducing the need to manage complex S3 bucket policies for those datasets.

• E. To enable Lake Formation and the AWS Glue Data Catalog, you must migrate all existing S3 data into a new, dedicated data lake account that is managed exclusively by Lake Formation.

Correct answers: A, C and D

Explanation: An S3-based data lake on AWS typically uses Amazon S3 for durable object storage, the AWS Glue Data Catalog for centralized metadata, and AWS Lake Formation for governance and fine-grained access control. Analytics services such as Amazon Athena, Amazon Redshift Spectrum, AWS Glue ETL jobs, and Amazon EMR then query or process the data directly from S3 using the shared catalog.

Lake Formation builds on the Glue Data Catalog by adding a permissions model for databases, tables, columns, and data filters. Integrated services call Lake Formation to check whether a given principal is authorized to access specific tables or columns, rather than relying solely on complex S3 bucket policies for fine-grained controls. S3 policies are still used to provide coarse-grained access to buckets and prefixes, but table- and column-level authorization is managed centrally by Lake Formation.

The AWS Glue Data Catalog stores schemas and partition information for S3 data, allowing multiple tools to share a consistent view of the datasets. Because these services operate on the same underlying S3 objects, there is no need to maintain multiple physical copies of data for each analytics engine.

Performance and cost efficiency in an S3 data lake are improved by using open, columnar formats such as Apache Parquet or ORC and organizing data into partitions based on common filter keys (for example, partitioning by date or region). Columnar formats reduce the amount of data read when only some columns are needed, and partitions allow query engines like Athena or Redshift Spectrum to skip whole directories or prefixes, reducing the volume of scanned data and improving query latency and cost.

Lake Formation does not impose a specific network topology or require a new account. You can enable it in an existing account, register current S3 locations, and integrate it with your chosen VPC and connectivity model. A multi-account strategy can be used for governance, but it is an architectural choice, not a strict requirement of the service.

---

Question 3

Topic: Design High-Performing Architectures

A company runs an Amazon RDS for MySQL DB instance with a write-intensive primary. To scale a read-intensive reporting workload, the company will send all read traffic to RDS read replicas only. Each read replica can handle 5,000 read requests/second. Peak read traffic is estimated at 18,000 read requests/second. Assuming traffic is evenly balanced and you must round up to the next whole instance, how many read replicas are required to meet the peak read load?

Options:

• A. 2 read replicas

• B. 5 read replicas

• C. 4 read replicas

• D. 3 read replicas

Best answer: C

Explanation: This scenario focuses on scaling a read-intensive workload by offloading reads from the primary Amazon RDS for MySQL instance to read replicas. Read replicas are designed to horizontally scale read throughput by adding additional instances that serve read-only queries.

The stem specifies that all read traffic (18,000 read requests/second at peak) will be sent to read replicas, and each replica can handle 5,000 read requests/second. The primary is assumed to handle only writes, so its read capacity is not counted.

To determine the number of replicas, divide the required read throughput by the per-replica capacity and then round up to the next whole instance, because you cannot provision a fraction of a replica and you must ensure capacity meets or exceeds the requirement.

Using the numbers provided:

• Required read throughput: 18,000 read requests/second
• Per-replica capacity: 5,000 read requests/second

Number of replicas needed is:

\[ \text{replicas} = \left\lceil \frac{18{,}000}{5{,}000} \right\rceil = \left\lceil 3.6 \right\rceil = 4 \]

Thus, four read replicas are required to meet the peak read demand while keeping the primary focused on write operations. This design aligns with the performance efficiency pillar by right-sizing capacity and using RDS read replicas to support a read-intensive workload without overprovisioning.

---

Question 4

Topic: Design High-Performing Architectures

Which THREE statements about using Amazon ElastiCache to improve database performance are true? (Select THREE.)

Options:

• A. ElastiCache for Redis supports features like key TTLs and rich data structures, which can be used for patterns such as session caching, leaderboards, and fine-grained cache expiration.

• B. A common pattern is for the application to check ElastiCache first and, on a cache miss, read from the database and then populate the cache with the result.

• C. After adding ElastiCache in front of a database, indexing and query optimization on the database are no longer important, because all reads will be served from the cache.

• D. Caching frequently accessed read data in Amazon ElastiCache reduces latency for those requests and offloads read traffic from the primary database.

• E. ElastiCache clusters are designed to be the primary, durable system of record for transactional data, so a separate relational or NoSQL database is usually unnecessary.

Correct answers: A, B and D

Explanation: Amazon ElastiCache (for Redis or Memcached) is an in-memory caching layer that sits alongside your primary database. For read-heavy workloads, you can use ElastiCache to store hot, frequently accessed data in memory. This reduces the number of read operations hitting the database, which improves end-to-end latency and can significantly increase the throughput the system can handle.

The most common integration pattern is cache-aside (also called read-through at the application level): the application checks the cache first, and only if the data is not found does it query the database, then populates the cache with the new value. The database remains the durable system of record, and the cache is a transient performance optimization.

ElastiCache for Redis offers richer capabilities such as per-key TTL expiration and advanced data structures, which make it useful for scenarios like session management, leaderboards, and fine-grained cache invalidation strategies. However, because ElastiCache is in-memory and can evict or lose data, it is not suitable as the sole system of record for critical transactional data, and you still need to design and tune your underlying database appropriately.

---

Question 5

Topic: Design High-Performing Architectures

A company runs several on-premises applications built around Apache Kafka APIs. During migration to AWS, they must avoid changing client code and require detailed control over broker configuration and upgrades. Which reasons would justify choosing Amazon MSK instead of Amazon Kinesis Data Streams? (Select TWO.)

Options:

• A. The team needs granular control over Kafka broker configuration, topic settings, and the schedule for Kafka version upgrades.

• B. The team wants AWS to abstract away partitions and capacity management by automatically scaling a fully serverless streaming service.

• C. The team prefers an AWS-native streaming API so they can publish and read records only through the AWS SDK using PutRecord and GetRecords operations.

• D. The applications must keep using existing Kafka producers, consumers, and Kafka-based frameworks without code changes.

• E. The team wants built-in support for enhanced fan-out consumers with dedicated throughput per consumer application without managing brokers.

Correct answers: A and D

Explanation: Amazon MSK is a managed service that runs Apache Kafka clusters on AWS. It is best suited when you need Kafka protocol compatibility and operational control, but still want AWS to handle underlying infrastructure tasks such as provisioning instances, replacing failed brokers, and patching.

In this scenario, the company already has Kafka-based applications and wants to avoid code changes. They also want detailed control over broker configuration and upgrade timing. Those are strong indicators for choosing Amazon MSK over Amazon Kinesis Data Streams.

Amazon Kinesis Data Streams is a fully managed, serverless streaming service with its own AWS-native APIs (PutRecord/GetRecords, KCL, enhanced fan-out). It simplifies operations and capacity management, but requires using Kinesis APIs and offers less low-level configuration control. That makes it ideal for greenfield designs that do not depend on Kafka, but less suitable when you must preserve an existing Kafka ecosystem and tuning model.

---

Question 6

Topic: Design High-Performing Architectures

An operations team uses an Amazon QuickSight dashboard to review API health in daily standups. The exhibit shows current metrics and targets.

[Exhibit: API health metrics]

Which dashboard change should the solutions architect prioritize to surface the most urgent operational risk?

Options:

• A. Create a line chart of error rate over time with a threshold band at 1.0%.

• B. Add a detailed table of request volume per endpoint to identify the busiest APIs.

• C. Add a KPI visual for P95 latency with conditional red formatting when the value exceeds 200 ms.

• D. Replace latency metrics with a bar chart of request volume by day to highlight traffic growth.

Best answer: C

Explanation: The exhibit highlights that only one metric is currently outside its target: the P95 latency. The line P95 latency | 200 ms | 260 ms | ↑15% shows that latency is higher than the 200 ms target and is worsening over the last 7 days. In contrast, Error rate | <1.0% | 0.4% | ↓5% is below its threshold and improving, and Request volume | ≥100k/day | 130k/day | ↑10% exceeds the target and is growing.

In an operational dashboard, the main goal is to surface risks and breaches quickly for stakeholders, not just show more data. A QuickSight KPI visual with conditional formatting (for example, turning red when the value exceeds the target) is specifically designed to highlight out-of-bounds metrics at a glance. Prioritizing such a visual for P95 latency ensures that the team immediately notices the SLO breach and can investigate its cause during daily standups.

Focusing visuals on healthy metrics like error rate or volume misreads the exhibit and can lead to a false sense of security, while the real issue (latency) keeps getting worse.

---

Question 7

Topic: Design High-Performing Architectures

Which of the following design choices help ensure that an AWS network architecture can scale to meet future demand? (Select THREE.)

Options:

• A. Use AWS Transit Gateway instead of many individual VPC peering connections to connect dozens of VPCs and on-premises networks.

• B. Use AWS PrivateLink to expose central internal services to many consumer VPCs without adding VPC-wide routes or exposing full VPC CIDR blocks.

• C. Prefer point-to-point VPC peering connections in a full mesh between all VPCs; this design scales better than a hub-and-spoke Transit Gateway.

• D. Allocate larger, non-overlapping CIDR blocks (for example, /16) to VPCs up front so you can add more subnets later without renumbering.

• E. Reuse the same RFC1918 CIDR ranges in multiple VPCs in the same Region to reduce IP address planning effort; AWS networking automatically handles overlapping ranges.

• F. To conserve IP addresses for growth, create very small subnets (for example, /28) for each Availability Zone and add more /28 subnets as traffic grows.

Correct answers: A, B and D

Explanation: Designing a high-performing, scalable network on AWS starts with good IP address planning and the right connectivity primitives. VPC CIDR blocks should be large enough and non-overlapping so that the environment can add subnets, AZs, and services without disruptive renumbering. For connectivity, AWS provides services like AWS Transit Gateway and AWS PrivateLink that are specifically engineered to scale to many VPCs and accounts, avoiding the operational complexity of ad hoc meshes of peering connections and custom routing.

Transit Gateway acts as a central hub for routing between VPCs and on-premises environments, simplifying route management as the number of networks grows. AWS PrivateLink provides service-level connectivity using interface endpoints, allowing you to share specific applications across many VPCs without exposing entire CIDR ranges or managing complex route tables. In contrast, relying on overlapping CIDRs, large meshes of VPC peering, or very small subnets makes it difficult to scale cleanly.

---

Question 8

Topic: Design High-Performing Architectures

Which TWO statements about configuring Amazon Kinesis Data Streams to handle a high-throughput ingestion workload are true? (Select TWO.)

Options:

• A. Setting very low batch sizes on consumer applications always improves both end-to-end latency and overall throughput.

• B. Reducing the number of shards during peak traffic helps avoid throttling by consolidating writes onto fewer shards.

• C. Configuring all producers to use the same partition key maximizes shard utilization and overall stream throughput.

• D. Increasing the number of shards in a stream increases its maximum aggregate write throughput and consumer parallelism.

• E. For producers sending many small records, batching them with the PutRecords API improves throughput and reduces per-record overhead.

Correct answers: D and E

Explanation: Kinesis Data Streams capacity and performance are primarily controlled by how many shards the stream has, how data is partitioned across those shards, and how producers and consumers batch records.

Each shard provides a fixed amount of write and read capacity. To handle higher sustained ingest throughput or increase consumer parallelism, you add shards. Producers can further improve performance by batching records using the PutRecords API, which reduces per-request overhead when sending many small records.

By contrast, concentrating all data on a single partition key or reducing shard count during peak traffic both create hotspots and reduce total capacity. Similarly, using very small consumer batch sizes may reduce latency but generally lowers throughput and efficiency because of more frequent I/O and processing overhead.

---

Question 9

Topic: Design High-Performing Architectures

Which TWO of the following statements about using Amazon ElastiCache to improve database performance are INCORRECT? (Select TWO.)

Options:

• A. Caching relatively static, frequently accessed query results in ElastiCache is especially effective for read-heavy workloads.

• B. Storing the only copy of critical application data in an ElastiCache cluster is acceptable and removes the need for a durable database.

• C. ElastiCache for Memcached is commonly used as a simple key-value cache layer in front of relational databases to reduce read load.

• D. Using ElastiCache as a read-through cache for hot keys can reduce latency and offload repeated read traffic from the database.

• E. It is a best practice to cache every database query result in ElastiCache to maximize the cache hit ratio.

Correct answers: B and E

Explanation: Amazon ElastiCache (Redis or Memcached) is designed as an in-memory cache layer that sits in front of durable data stores like Amazon RDS, Aurora, or DynamoDB. By serving frequently accessed data directly from memory, it reduces round-trips to the underlying database, improving latency and offloading read-heavy workloads.

Effective caching focuses on the right data: hot, frequently reused, and not too volatile. Caching every possible query is not a best practice, because some data changes too often, is user-specific, or is rarely reused. Over-caching wastes memory and complicates cache invalidation.

Equally important, ElastiCache must not be treated as the primary system of record. Because it is an in-memory cache, data can be evicted or lost (for example, during node failures). Critical application data must be stored in a durable, persistent store. ElastiCache then acts as a performance optimization, not a replacement for durable storage.

---

Question 10

Topic: Design High-Performing Architectures

A global web application has users in us-east-1 and eu-west-1. Requirements: sub-100ms local reads in both Regions, strongly consistent writes in us-east-1, Regional DR with RPO<5 minutes and RTO<15 minutes, and minimal operational overhead. The team is flexible on database engine. Which database deployments meet these needs? (Select THREE.)

Options:

• A. Deploy Amazon RDS for PostgreSQL Multi-AZ in us-east-1 with a cross-Region read replica in eu-west-1; direct EU reads to the replica and promote it during Regional failover.

• B. Use DynamoDB global tables with replicas in us-east-1 and eu-west-1, allowing local reads and writes in each Region and relying on global table replication for multi-Region availability.

• C. Run self-managed MySQL on EC2 in us-east-1 with asynchronous replication to an EC2 instance in eu-west-1; use custom scripts and DNS updates for Regional failover.

• D. Deploy a single Aurora MySQL Multi-AZ cluster in us-east-1 only and use Amazon CloudFront to cache dynamic responses for eu-west-1 users.

• E. Use Amazon Aurora Global Database (MySQL-compatible) with the primary cluster in us-east-1 and a secondary Region cluster in eu-west-1; direct regional reads to local readers and use managed global failover for DR.

Correct answers: A, B and E

Explanation: The question focuses on choosing database deployment strategies that use AWS’s global infrastructure (Regions and Availability Zones) to deliver both high performance and robust cross-Region disaster recovery.

To satisfy sub-100ms local reads in both us-east-1 and eu-west-1, the database (or replicas) must be deployed in both Regions, not just fronted by a cache. Strongly consistent writes in us-east-1 require a primary or writer in that Region. The DR target of RPO<5 minutes and RTO<15 minutes rules out slow, snapshot-only restore approaches and favors managed multi-Region replication that can be promoted quickly.

Managed services such as Amazon Aurora Global Database, DynamoDB global tables, and Amazon RDS with Multi-AZ plus cross-Region read replicas are designed to provide multi-AZ durability and multi-Region read performance with relatively low operational overhead.

Summary of the options:

• ✔ Aurora Global Database with primary in us-east-1 and secondary cluster in eu-west-1 gives low-latency local reads, strong writes in us-east-1, very low replication lag, and fast managed failover.
• ✔ DynamoDB global tables deployed in both Regions provide local, single-digit millisecond reads/writes, multi-Region HA, and typically sub-minute replication lag, all fully managed.
• ✔ RDS Multi-AZ in us-east-1 with a cross-Region read replica in eu-west-1 supports strong writes in us-east-1, local EU reads, and manual promotion for DR within the stated RPO/RTO.
• ✖ A single-Region Aurora cluster plus CloudFront does not address dynamic query latency for European users because the database remains only in us-east-1.
• ✖ Self-managed MySQL on EC2 with custom failover scripts can be made to work but clearly fails the minimal operational overhead requirement compared to managed multi-Region database offerings.

Continue in the web app

Use IT Mastery for interactive AWS SAA-C03 practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try AWS SAA-C03 on Web

Related focused pages

• Free AWS SAA-C03 Full-Length Practice Exam
• Design Secure Architectures
• Design Resilient Architectures
• Design Cost-Optimized Architectures