SAA-C03 Design High-Performing Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Add Aurora Replicas to scale out read traffic across multiple database instances.

  Why this is correct

  Aurora Replicas are independent database instances in the same Aurora cluster that share the underlying storage volume, allowing them to serve read traffic without replicating data changes at the instance level. You can add up to 15 replicas, which adds CPU, memory, and connection capacity for concurrent SELECT queries, effectively scaling out the database layer horizontally. Because the storage is shared, replicas also offer near-zero replication lag, making them suitable for read-heavy workloads that need fresh data.

• ✓

  Send read queries to the Aurora reader endpoint so they are distributed across the replicas.

  Why this is correct

  The reader endpoint is a cluster-level DNS name that resolves to all available Aurora Replica endpoints, and connections made through it are load-balanced across those replicas. This lets the application use the capacity of multiple replicas without hard-coding any individual instance hostname, which is essential for maintaining a consistent connection string as replicas are added or removed. Note that the endpoint distributes connections, not individual SQL statements, so for optimal spreading of read load, the application should open multiple short-lived connections or use connection pooling.

• ✗

  Point all queries to the writer endpoint so Aurora can balance reads and writes internally.

  Why it's wrong here

  The writer endpoint always resolves to the primary instance, which is the only instance in an Aurora cluster that can accept write operations such as INSERT, UPDATE, and DDL. If the application sends all reads to the writer endpoint, it forces the primary to handle both the write workload and the read workload, creating CPU and I/O contention that can increase write latency and block failover-related maintenance. Aurora does not internally distribute reads to replicas based on the endpoint you use; load balancing only occurs when you connect via the reader endpoint or a custom endpoint.

• ✗

  Enable Multi-AZ standby for the cluster to increase the number of read-only connections.

  Why it's wrong here

  Enabling a Multi-AZ standby in a traditional RDS deployment creates a passive failover replica that does not serve any reads, so it provides zero additional read capacity. In Aurora, high availability is built into the storage layer with six copies across three AZs, and failover is performed by promoting one of the active Aurora Replicas, not by a separate standby. Even if you explicitly provision a single-instance cluster with no replicas, enabling Multi-AZ does not increase read throughput; to scale reads you must add active Aurora Replicas and route traffic to the reader endpoint.

• ✗

  Move the database to a single larger instance class instead of adding replicas.

  Why it's wrong here

  A larger instance may improve the performance of one node, but it does not provide the horizontal scaling needed for a read-heavy workload. The question asks for more read throughput without changing the application design, which is exactly what replicas and the reader endpoint provide.

Go deeper

Related to this question