SAA-C03 (SAA-C03) — Questions 601–675

The issue is not ALB capacity or backend scaling; it's about excessive requests and latency due to lack of caching and compression. Increasing ALB size and instances doesn't reduce request volume or compress assets.

Route 53 latency-based routing directs users to the nearest ALB, but the problem is that the ALB receives far more requests than expected due to cacheable content not being cached. Latency routing alone does not reduce ALB load or compress text assets automatically.

An NLB does not support caching, compression, or HTTP-level features like image/CSS/JS optimization; it operates at Layer 4 and cannot reduce request volume or compress text assets.

When the website experiences high CPU/memory utilization on the ALB and backend instances, and the primary bottleneck is compute capacity rather than request volume or latency, scaling out the ALB and targets is appropriate.

In a scenario where you have multiple ALBs deployed in different AWS regions and users experience high latency because they are being routed to a distant region, Route 53 latency-based routing would be the correct answer to direct each user to the closest ALB, reducing latency.

If the question required handling millions of UDP or TCP connections with ultra-low latency and no need for HTTP features (e.g., a real-time gaming server or IoT device traffic), replacing an ALB with an NLB would be appropriate.

Candidates often default to scaling solutions when they see performance issues, without diagnosing the root cause (lack of caching/compression).

Candidates may think that reducing network latency by routing users to the nearest ALB will solve the slow page loads, but they overlook that the core issue is excessive requests hitting the ALB due to lack of caching and compression, which latency routing does not address.

Candidates may think NLB reduces latency because it is faster at the transport layer, but they overlook that the bottleneck here is cacheable content and compression, which require Layer 7 features.

Storing the password in a plain environment variable violates the requirement that the password must never be stored in plaintext. Manual updates during maintenance windows are not secure and do not provide automated rotation or retrieval at runtime.

Using an IAM user access key inside the container violates the principle of not storing secrets in the image or code, and access keys are long-lived credentials that increase security risk. The correct approach is to use IAM roles for tasks to obtain temporary credentials.

In a non-production environment with no security compliance requirements, where the password is static and the application reads it from an environment variable set at container launch, and manual updates are acceptable for testing purposes.

In a scenario where an application needs to authenticate to an external API that requires long-lived access keys and the application is running on an EC2 instance without IAM roles support, embedding an IAM user access key in a secure configuration file (not in code) might be acceptable if encrypted and rotated regularly.

Candidates may think environment variables are a simple and acceptable way to pass secrets, overlooking the explicit requirement to avoid plaintext storage and the need for runtime retrieval without hardcoding.

Candidates may think that IAM access keys are a standard way to grant programmatic access, and they might not fully understand that ECS tasks can assume IAM roles, eliminating the need to embed keys.

Weighted routing distributes traffic across multiple resources based on assigned weights, but it does not automatically fail over to a standby site when the primary fails; it requires manual weight adjustment or health checks to redirect traffic.

Geolocation routing directs traffic based on the user's geographic location, not on the health of the primary site. It cannot automatically fail over to a standby region when the primary fails.

Latency-based routing directs users to the region with the lowest latency, not to a primary site with automatic failover to a standby site. It does not support health checks to detect primary failure.

A company wants to send 10% of traffic to a new application version for testing while sending 90% to the stable version, using Route 53 to distribute traffic based on weights.

A company needs to route users to different endpoints based on their country or continent, e.g., users in Europe go to eu-west-1, users in North America go to us-east-1, and they want to serve localized content or comply with data residency requirements.

A company wants to route users to the AWS region that provides the lowest latency for each user, without a fixed primary/standby setup. For example, a global application serving users worldwide should use latency-based routing to minimize response times.

Candidates may think weighted routing can be used to send all traffic to the primary by setting its weight to 100 and the standby to 0, but this does not provide automatic failover without health checks.

Candidates may confuse geolocation with geographic failover, thinking that routing based on location can also handle failover, or they may assume that 'geolocation' implies awareness of site health.

Candidates may think latency-based routing can automatically redirect users when the primary fails, confusing performance optimization with disaster recovery failover.

Option B does not enforce MFA; it restricts the role to principals from a specific AWS Organization, which is unrelated to MFA requirements.

This option denies AssumeRole based on the role session name containing 'dev', which does not enforce MFA. The question specifically asks for an MFA enforcement condition, not a naming restriction.

Requiring HTTPS (aws:SecureTransport) ensures encrypted transport but does not enforce MFA. The question specifically asks for MFA enforcement, so this condition does not address the requirement.

This option would be correct if the question asked: 'Which condition restricts role assumption to principals belonging to a specific AWS Organization?'

In a scenario where an organization wants to restrict role assumption to only developers (e.g., by requiring the session name to include 'dev' as a naming convention), a condition like this could be used in the trust policy to allow or deny based on session name.

A question asks: 'You need to ensure that all API calls to assume a role are made over encrypted connections. Which condition should you add to the trust policy?' In that case, aws:SecureTransport would be the correct answer.

Candidates may confuse organizational controls with security requirements like MFA, or think that restricting by organization inherently includes MFA enforcement.

Candidates might think that restricting session names is a way to control access, but they overlook that the question explicitly requires MFA enforcement, not naming conventions.

Candidates may confuse security best practices (like using HTTPS) with specific MFA requirements, or think that transport encryption implies authentication strength.

Multi-AZ RDS automatically fails over to the standby in the same Region without manual intervention, so the database does not remain unavailable until an admin acts.

Read replicas in another Region are for read scaling and disaster recovery, not automatic failover. Multi-AZ failover uses a standby in the same Region, not a cross-Region read replica.

In a Multi-AZ RDS MySQL configuration, the standby instance is in a different Availability Zone, not in another Region, and the failed primary does not continue serving traffic; RDS automatically fails over to the standby.

This would be correct if the question described a Single-AZ RDS deployment without Multi-AZ or automated failover, where an administrator must manually restore from a snapshot or create a new instance.

If the question were about disaster recovery using Amazon RDS cross-Region read replicas and asked how to promote a read replica to a primary for continuity after a regional failure, then traffic could be routed to the promoted read replica.

This option would be correct if the question described a scenario where RDS is configured with a Multi-Region read replica and the primary fails, but the application is designed to use the read replica for reads only, not for failover. However, for write continuity, a manual promotion would be needed.

Candidates may confuse Multi-AZ with Single-AZ deployments or assume that any database failure requires manual recovery, overlooking RDS's automated failover feature.

Candidates may confuse read replicas with Multi-AZ standby instances, assuming any replica can serve as a failover target, and may overestimate the automatic failover capabilities of cross-Region replicas.

Candidates may confuse Multi-AZ failover with read replica promotion, or incorrectly assume that the primary can still serve traffic during a failure if the standby is synchronizing.

AWS does not replicate data across Regions automatically or immediately; cross-Region replication is asynchronous, so active-active writes cannot guarantee strong consistency.

Active-active writes without coordination cannot guarantee strong consistency for order status transitions; retries and application-level conflict resolution are insufficient to prevent two regions from simultaneously accepting conflicting transitions (e.g., 'Paid' to 'Shipped' in both regions).

Blocking cross-Region writes at the API layer with different IAM roles does not prevent concurrent writes from being accepted in both regions before the API layer can reject them, so it cannot guarantee strong consistency for order status transitions.

A question stating that the application uses a single AWS Region with multi-AZ deployment and requires strong consistency for all reads and writes, where synchronous replication within a Region can provide immediate consistency.

In a scenario where the workload can tolerate eventual consistency and the application is designed to handle conflicts (e.g., using last-writer-wins or CRDTs), and the business requirement is high availability with low latency rather than strong consistency for specific transitions.

If the question required preventing cross-Region writes for security reasons (e.g., to enforce data sovereignty) and consistency was not a concern, then using different IAM roles to block writes at the API layer would be a valid approach.

Candidates may mistakenly believe that AWS handles cross-Region replication synchronously, similar to within-Region services like DynamoDB global tables or Aurora Global Database, which are actually asynchronous.

Candidates may assume that retries and application logic can resolve all conflicts, underestimating the difficulty of ensuring strong consistency across regions without a centralized coordinator or locking mechanism.

Candidates may think that IAM-based API restrictions can enforce write ordering across regions, but IAM cannot coordinate the timing of concurrent requests in a distributed system.

Option B uses long-lived access keys stored in Lambda environment variables, violating the security requirement to avoid long-lived credentials. Additionally, revoking access requires deleting or rotating the keys in Account B, which is less straightforward than removing a role trust policy.

Security groups control network traffic at the instance level, not S3 bucket access. They cannot grant or deny API-level permissions to write objects; S3 uses IAM policies, bucket policies, or ACLs for authorization.

SCPs are used to centrally control permissions for all accounts in an AWS Organization, not to grant cross-account access to a specific Lambda function. They can only deny or allow permissions at the account level, not to individual resources like a Lambda function.

This option would be correct if the question stated that the Lambda function must use long-lived credentials (e.g., for legacy system compatibility) and the security requirement to avoid them was absent. It might also be acceptable in a single-account scenario where IAM users are the only option.

A question where a Lambda function needs to access an S3 bucket in the same account, and the concern is network-level restriction (e.g., VPC endpoint). Then attaching a security group to the Lambda function (via VPC configuration) to allow outbound traffic to the S3 VPC endpoint would be correct.

An SCP would be correct if the question asked how to prevent all accounts in an organization from writing to a specific S3 bucket, or to enforce a policy that restricts S3 bucket access across multiple accounts for compliance reasons.

Candidates may think storing keys in environment variables is acceptable because it avoids hardcoding, and they may overlook the 'no long-lived access keys' constraint. The simplicity of creating an IAM user and directly using its keys can seem easier than setting up cross-account roles.

Candidates may confuse network access control (security groups) with identity-based access control (IAM), thinking that allowing outbound traffic to the bucket's IP range is sufficient to grant write permissions.

Candidates may confuse SCPs with IAM policies, thinking they can grant fine-grained permissions to individual resources, or they may overestimate the scope of SCPs as a tool for cross-account access.

Partition PGs distribute instances across separate hardware racks to reduce rack-failure impact. Instances in different partitions have higher inter-node latency. Designed for distributed databases (Hadoop, Cassandra, Kafka), not tightly coupled HPC.

Spread PGs place each instance on a distinct hardware rack for maximum isolation. Instances are intentionally spread further apart, increasing latency — the opposite of what HPC requires.

Multi-AZ Auto Scaling distributes instances across AZs for availability. Cross-AZ networking has higher latency than within-AZ. For HPC requiring sub-microsecond inter-node communication, all instances must be in the same AZ within a Cluster PG.

Increasing desired capacity in the same subnet does not add fault tolerance across Availability Zones; the web tier remains vulnerable to a single AZ outage.

Replacing the Application Load Balancer with a Network Load Balancer does not address the single-Availability Zone failure; the web tier would still be in us-west-2a only, so an outage of that AZ would still cause unavailability.

Increasing the health check grace period only delays instance deregistration during an outage, but does not address the root cause: the web tier is in a single Availability Zone. Instances in us-west-2a will still become unhealthy and eventually be terminated, causing unavailability.

If the question asked how to handle increased traffic without changing AZ architecture, increasing desired capacity would be correct to distribute more instances within the existing subnet.

If the question required handling sudden traffic spikes with minimal latency and the application could tolerate connection draining, a Network Load Balancer might be chosen for its higher throughput and static IP support, but only if the architecture already spans multiple AZs.

A question where instances are being prematurely terminated due to transient health check failures (e.g., brief CPU spikes) and the goal is to avoid unnecessary instance replacement without changing architecture. The correct answer would be to increase the grace period to allow recovery.

Candidates may think more instances automatically improve resilience, overlooking that all instances are in the same AZ and thus share the same failure domain.

Candidates may think a Network Load Balancer is inherently more resilient, but resilience comes from multi-AZ deployment, not the load balancer type.

Candidates may think that giving instances more time to recover will prevent them from being marked unhealthy during a short outage, but they overlook that a full AZ outage is not recoverable by extending the grace period.

This option fails to meet the requirement that backups must be retained for 2 years, as it deletes them after only 30 days.

Keeping all backups in S3 Standard for 2 years incurs high storage costs for data that is rarely accessed after 30 days, making it not cost-effective.

Moving backups to Glacier Deep Archive immediately after creation would incur retrieval costs and delays for restores during the first 30 days, when restores are common, making it less cost-effective and operationally unsuitable.

If the requirement were to only retain backups for 30 days with no longer-term retention needed, then deleting after 30 days would be the most cost-effective strategy.

If the requirement was to restore backups instantly at any time during the 2-year period with no retrieval delays, and cost was not a primary concern, then keeping all data in S3 Standard would be correct.

If the requirement stated that backups are never restored within the first 30 days and must be retained for 2 years with the lowest possible storage cost, then moving them immediately to S3 Glacier Deep Archive would be the most cost-effective strategy.

Candidates may focus solely on cost savings and overlook the explicit 2-year retention requirement, assuming that rare restores justify immediate deletion.

Candidates may think S3 Standard is the default safe choice and overlook the cost savings of transitioning to lower-cost storage classes for rarely accessed data.

Candidates may assume that the cheapest storage class is always best, overlooking the need for quick and frequent access during the initial 30-day period.

A spread placement group places instances on separate hardware to reduce correlated failures, but it does not minimize inter-node latency; in fact, it may increase latency due to physical separation.

Moving instances into different Availability Zones increases inter-node latency due to physical separation, which contradicts the goal of reducing latency.

A partition placement group spreads instances across logical partitions, each on separate racks, to reduce correlated failures for large distributed workloads like HDFS or Cassandra. It does not minimize inter-node latency, which requires the low-latency, high-bandwidth network of a cluster placement group within a single AZ.

When the question emphasizes high availability and fault tolerance, such as avoiding simultaneous failures from a single rack or hardware, and latency is not the primary concern.

When the requirement is to maximize fault tolerance and high availability, such as for a multi-AZ deployment of a critical application that must survive an AZ failure, even at the cost of higher latency.

For a large-scale distributed data processing workload (e.g., Hadoop, Kafka) that needs to tolerate rack-level failures while maintaining high throughput, a partition placement group would be correct. The question would emphasize fault isolation across racks rather than minimizing latency.

Candidates may confuse 'separate hardware' with 'closer proximity,' assuming that spreading instances reduces network hops, but spread groups actually increase physical distance between instances.

Candidates may confuse fault tolerance with performance optimization, or assume that distributing across AZs always improves reliability without considering latency trade-offs.

Candidates may confuse partition placement groups with cluster placement groups, thinking that 'partition' implies grouping instances together for performance, or they may overvalue fault tolerance features without recognizing the primary latency requirement.

A spread placement group distributes instances across distinct hardware to reduce correlated failures, but it does not provide the low latency and high bandwidth needed for tightly coupled, latency-sensitive distributed training. It can actually increase network jitter due to greater physical separation.

Default EC2 scheduling does not guarantee low latency or low jitter because instances may be placed on different physical hardware, increasing network hops and variability, which is unacceptable for a latency-sensitive distributed training job requiring consistent performance.

When the requirement is to maximize availability and fault tolerance by ensuring instances are on separate hardware, such as for a critical application that must survive hardware failures, and low latency is not the primary concern.

A solutions architect is deploying a web application across multiple Availability Zones for high availability, and the application can tolerate moderate network latency. In this case, default scheduling is sufficient and avoids placement group constraints that could limit instance availability.

Candidates may mistakenly think that spreading instances reduces jitter by avoiding resource contention, but for latency-sensitive workloads requiring frequent small messages, proximity is more important than hardware diversity.

Candidates may assume that default scheduling provides adequate performance for most workloads, underestimating the strict low-latency and low-jitter requirements of tightly coupled HPC or distributed training jobs.

ALB does not support UDP listeners; it only supports HTTP, HTTPS, and WebSocket protocols. Additionally, ALB cannot provide static IP addresses or perform TLS passthrough without terminating TLS.

Amazon API Gateway WebSocket API does not support UDP traffic; it uses WebSocket protocol over TCP, and it cannot provide static IP addresses for firewall allowlisting. The requirement for UDP and static IPs makes this option invalid.

Classic Load Balancers do not support UDP listeners; they only handle TCP/SSL traffic. Multiplexing UDP over TCP would break real-time gameplay requirements by introducing TCP overhead and latency.

When the requirement is for HTTP/HTTPS traffic with path-based routing, host-based routing, or WebSocket support, and TLS termination at the load balancer is acceptable. For example, a web application needing advanced routing and SSL offloading.

This option would be correct for a real-time chat or notification service that requires persistent bidirectional communication with low latency, where clients connect via WebSocket and the service does not need static IPs or UDP transport.

If the question required load balancing legacy HTTP/HTTPS traffic with basic round-robin routing and no need for UDP or static IPs, a Classic Load Balancer would be a valid, cost-effective option.

Candidates may mistakenly think ALB supports UDP because it handles WebSocket traffic, or they confuse ALB's TLS termination with the ability to pass through TLS without decryption.

Candidates may confuse WebSocket's low-latency, full-duplex communication with UDP's real-time capabilities, and overlook that WebSocket runs over TCP and lacks static IP support.

Candidates may think Classic Load Balancers can be adapted to support UDP via workarounds, or they confuse Classic Load Balancers with Network Load Balancers, assuming both support UDP.

Permission boundaries apply to IAM roles and users, not just users. The developer can create a role without a boundary, so attaching a policy to the user does not restrict the role's permissions.

SCPs apply to all accounts in an AWS Organization but do not replace or enforce IAM permission boundaries on individual roles; permission boundaries must be explicitly set on each role during creation.

Permission boundaries cannot be modified by the user they restrict; only the boundary's creator (e.g., security team) can update it. Granting the developer permission to add a deny statement would violate the boundary's purpose and is not a valid corrective action.

If the question asked how to restrict a developer's own permissions (not roles they create), attaching an AWS-managed policy to the user would be correct.

In a question where the goal is to enforce a maximum permission baseline across all accounts in an AWS Organization, and the requirement is to prevent any IAM entity from exceeding a defined set of actions, an SCP would be the correct answer.

In a scenario where a developer needs to implement additional restrictions on a role they manage, and the security team has delegated authority to modify a custom boundary policy for specific use cases, allowing the developer to add deny statements could be correct if explicitly authorized.

Candidates may think permission boundaries are only for users, or that a user's attached policy limits all actions they perform, including role creation.

Candidates may confuse SCPs with permission boundaries because both can restrict permissions, but they operate at different levels (account vs. entity) and have different enforcement mechanisms.

Candidates may think that adding a deny statement to the boundary policy would block privilege escalation, misunderstanding that permission boundaries are set by an admin and cannot be altered by the user they constrain.

Manual promotion via runbook after CloudWatch alarms still requires human intervention, which does not meet the goal of 'least operational intervention' and will not reduce outage duration as effectively as automatic failover.

Cross-Region read replicas are asynchronous and do not support automatic failover; promoting them requires manual intervention and takes longer than Multi-AZ failover, so they do not improve resilience with the least operational intervention during an AZ failure.

Increasing the application retry count does not address the root cause of the outage (AZ failure) and does not improve resilience; it only masks the symptom and may lead to degraded user experience or timeouts.

This option would be correct in a scenario where the database must remain in a single-AZ configuration due to cost constraints or compliance, but the organization can tolerate a slightly longer outage and wants to minimize manual steps by automating the promotion process with a runbook triggered by CloudWatch alarms.

This option would be correct if the question required resilience against a Region-wide outage (not just an AZ failure) and the application could tolerate eventual consistency, as cross-Region replicas provide disaster recovery across geographic regions.

In a scenario where the database is already resilient (e.g., Multi-AZ) but transient network blips cause brief connection drops, increasing the retry count can help the application recover without manual intervention.

Candidates may think automating the runbook reduces operational effort, but they overlook that manual promotion still requires human action, which is slower and more error-prone than automatic failover.

Candidates may think cross-Region replicas offer faster promotion because they are in a different location, but they overlook the asynchronous replication lag and lack of automatic failover, which actually increases outage duration.

Candidates may think that retries can compensate for any failure, underestimating the need for infrastructure-level high availability and overestimating application-level fault tolerance.

Increasing on-demand table limits does not reduce read latency; it only prevents throttling. The observed latency is likely due to repeated reads of the same hot data, which DAX caching addresses directly.

A GSI on tenantId does not reduce read latency for repeated reads of the same data; it only helps with query flexibility. The observed latency is likely due to hot partitions or throttling, which DAX's caching directly addresses.

Moving dashboard data to S3 and using Lambda to read it on demand would likely increase read latency due to cold starts and S3's higher latency for small, frequent reads compared to DAX. It also adds complexity and cost without addressing the root cause of high read latency on DynamoDB.

This option would be correct if the question described a scenario where the application is experiencing ProvisionedThroughputExceededException errors due to insufficient read capacity, and the workload is unpredictable, making on-demand capacity the appropriate solution.

If the question described a scenario where read traffic is evenly distributed across many distinct tenantId values and the goal is to improve query performance by avoiding full table scans, then adding a GSI on tenantId would be correct.

This option would be correct if the question involved large, infrequently accessed dashboard data (e.g., historical reports) where cost savings from S3's lower storage cost outweigh latency concerns, and the Lambda function can be optimized with provisioned concurrency to minimize cold starts.

Candidates may assume that increasing capacity limits will improve performance, confusing throughput with latency, or they may not understand that DynamoDB's on-demand scaling handles capacity but not caching or hot-key issues.

Candidates may think that distributing load across partitions via a GSI will reduce latency, but they overlook that GSIs don't cache data and that the bottleneck is likely from repeated reads of the same items, not partition distribution.

Candidates may think S3 is always faster or cheaper for any data, or they might overestimate Lambda's ability to reduce latency without considering cold starts and network overhead.

Increasing Aurora storage autoscaling does not prevent failovers; it only adjusts storage capacity. Failovers occur due to instance-level issues, not storage limits, so this change does not address the application's connection errors after failover.

The reader endpoint is intended for read-only traffic and does not handle write operations; pointing writes to it would cause failures. Moreover, the reader endpoint resolves to multiple reader instances, not the current writer, so it does not ensure connectivity to the writer after failover.

Disabling failover capability prevents the cluster from switching to a healthy instance during a failure, which would cause prolonged downtime instead of resolving the connection errors. The question asks for improving resilience, and disabling failover directly undermines that goal.

A question where an application experiences write failures due to storage capacity limits on an Aurora cluster. The correct solution would be to enable storage autoscaling to automatically increase storage when thresholds are reached, preventing write disruptions.

In a scenario where the application only performs read operations and needs to distribute load across replicas while maintaining a single DNS name that automatically adjusts to available instances, using the reader endpoint would be correct. For example, a reporting application that queries read replicas and must remain available during failover.

In a scenario where the application cannot tolerate any connection interruption and the database must remain on a specific instance for compliance or licensing reasons, disabling failover might be chosen to avoid automatic failover, accepting the risk of manual recovery.

Candidates may mistakenly believe that storage autoscaling can eliminate the need for failovers by preventing resource exhaustion, but failovers are triggered by instance health, not storage.

Candidates may think that using a single endpoint simplifies DNS resolution and avoids the connection errors seen in the question, but they overlook that the reader endpoint is not designed for write traffic and does not point to the writer instance.

Candidates may think that disabling failover eliminates the need for the application to reconnect, thus avoiding connection errors, but they overlook that this removes the cluster's high availability and would cause extended downtime if the primary fails.

The workload is interruption-intolerant, so Spot Instances are unsuitable because they can be terminated with little notice, risking service disruption.

A Standard Reserved Instance locks to a specific instance type, which conflicts with the requirement to change instance families and sizes during planned optimizations.

The workload is steady and interruption-intolerant, so Auto Scaling to reduce capacity when utilization is low would not provide the lowest cost for the steady baseline usage, and On-Demand pricing is more expensive than a Compute Savings Plan for predictable workloads.

A question where the workload is fault-tolerant, can handle interruptions (e.g., batch processing, data analysis), and cost reduction is the top priority, with no requirement for steady, uninterruptible compute.

A company has a predictable, steady-state workload that uses a specific instance type for 1-3 years, with no plans to change instance families or sizes, and seeks the maximum discount over On-Demand.

A company has a variable workload that experiences predictable low-usage periods (e.g., nightly or seasonal drops) and can tolerate scaling down capacity during those times. The goal is to minimize costs by paying only for what is used, without upfront commitments.

Candidates see 'largest discount' and assume Spot is always best for cost savings, overlooking the critical requirement of interruption intolerance.

Candidates may assume Reserved Instances always offer the best savings without considering the flexibility constraint, or they overlook the requirement to change instance types.

Candidates may think Auto Scaling always reduces costs by matching capacity to demand, but they overlook that On-Demand pricing is still higher than savings plans for steady usage, and the question explicitly seeks the lowest cost.

Disabling synchronous replication compromises data durability and is not supported for RDS PostgreSQL; increasing storage throughput does not address the root cause of heavy SELECT queries impacting OLTP writes.

Amazon S3 is an object storage service, not a relational database, and cannot execute SQL queries or replace the transactional and query capabilities of RDS PostgreSQL. The dashboard requires live querying of the same data, not cached results from S3.

Moving the primary database to a different AWS Region does not address the performance impact of heavy SELECT queries on the same instance; it only changes the geographic location, potentially increasing latency for writes and reads.

An exam scenario where the database is experiencing I/O bottlenecks due to insufficient throughput for both reads and writes, and the question allows modifying replication settings to prioritize write performance at the cost of durability.

A question where the requirement is to store and serve large amounts of static or semi-static data for a dashboard that can tolerate eventual consistency, and the dashboard queries are simple key-value lookups or use Athena/Redshift Spectrum for analytics on data stored in S3.

This option would be correct if the question stated that the primary database is in a region far from the application servers, causing high latency for all operations, and the goal is to reduce network latency by relocating the database closer to the application.

Candidates may think that increasing resources or reducing replication overhead can solve performance issues, without understanding that read replicas are the proper solution for offloading read traffic without affecting writes.

Candidates may think S3 is a cost-effective solution for dashboards because it can store large datasets and integrate with analytics services, but they overlook that S3 is not a database and cannot handle complex SQL queries or transactional workloads.

Candidates may think that moving to a different region can reduce latency for the dashboard, but they overlook that the primary database still handles all queries, and the dashboard's heavy SELECTs remain on the same instance, not solving the performance issue.

Deleting the message immediately after receive prevents redelivery but also eliminates the ability to retry if processing fails, which violates the requirement of allowing safe retries.

Increasing the visibility timeout to a very large value does not guarantee that a consumer won't crash or timeout, and it can delay processing of other messages, leading to potential bottlenecks and still allowing duplicate charges if the consumer fails after processing but before deleting the message.

Single-threading does not prevent duplicate charges because the same message can still be redelivered after a timeout, even with one worker; the core issue is at-least-once delivery, not concurrency.

If the question required exactly-once processing with no retries and the consumer could guarantee successful processing upon receipt, deleting immediately would be correct.

This option would be correct in a scenario where the queue is used for time-sensitive tasks that must not be processed concurrently, and the consumer is highly reliable with minimal failure risk, such as processing a single critical job that should not be retried quickly.

This option would be correct in a scenario where the queue guarantees exactly-once delivery but the consumer needs to maintain strict ordering and avoid race conditions from multiple concurrent workers.

Candidates may think that eliminating redelivery directly solves duplicate charges, overlooking the need for retries in case of failures.

Candidates may think that a larger visibility timeout prevents message redelivery during normal processing, overlooking that failures or timeouts can still occur, and that this approach does not address the root cause of duplicate processing due to at-least-once delivery semantics.

Candidates may think that processing messages sequentially eliminates duplicates, but they overlook that at-least-once delivery can still cause redelivery of the same message to a single-threaded consumer.