CCNA Design Resilient Architectures Questions

Multi-Selectmedium

A production Amazon RDS database already has automated backups enabled. At 10:45 UTC, the team discovers that a faulty migration corrupted rows in a table at 10:30 UTC. The business wants the database restored to exactly the state it had at 10:30 UTC with minimal risk. Which two actions should the team take? Select two.

Select 2 answers

A.Restore the database to a new instance using point-in-time restore for 10:30 UTC.

B.Validate the restored database, then switch the application endpoint to the restored database.

C.Restore the most recent manual snapshot because it will include the 10:30 UTC state.

D.Overwrite the existing database instance in place so the application keeps the same storage volume.

E.Wait for automated backups to complete again, then replay the migration to restore the missing rows.

AnswersA, B

Correct. Point-in-time restore is the RDS recovery method for returning to a specific moment before the corruption occurred. Restoring to a new instance gives the team a clean database copy at the desired timestamp without risking the current production instance.

Why this answer

Amazon RDS Point-in-Time Restore (PITR) allows you to restore a DB instance to any second within the backup retention period, including 10:30 UTC. This uses automated backups and transaction logs to reconstruct the exact database state at that specific time, providing a precise recovery point with minimal data loss.

Exam trap

The trap here is that candidates may think manual snapshots can be used for point-in-time recovery, but they only capture a single moment and cannot roll forward to a specific time like automated backups can.

Practice this question →

MCQmedium

A payments platform requires disaster recovery across Regions. Requirements: RPO of 15 minutes and RTO of about 1 hour. The business cannot afford full duplicate capacity in both Regions all the time, but the team wants automated readiness so failover is mostly operationally guided rather than a slow rebuild. Which DR strategy is the best fit?

A.Backup and restore only, relying on scheduled snapshots and manual restores during incidents.

B.Pilot light, keeping only minimal infrastructure in the secondary Region and starting full services after failover.

C.Warm standby, keeping core infrastructure and a partially provisioned environment ready in the secondary Region with frequent data replication.

D.Active/active, routing production traffic to both Regions continuously and accepting dual-region complexity.

AnswerC

Warm standby balances cost and readiness by keeping enough capacity and services running to shorten recovery time while meeting RPO needs.

Why this answer

Warm standby is the best fit because it maintains a partially provisioned environment in the secondary Region with core infrastructure (e.g., a smaller EC2 Auto Scaling group, a standby database with synchronous or asynchronous replication) and frequent data replication, enabling an RPO of 15 minutes and an RTO of about 1 hour. This approach balances cost and automated readiness, as the team can scale up the standby environment during failover without the expense of full duplicate capacity, while still meeting the recovery objectives through automated replication (e.g., Amazon RDS Multi-AZ cross-Region or DynamoDB global tables).

Exam trap

The trap here is that candidates often confuse pilot light with warm standby, assuming minimal infrastructure is sufficient for a 1-hour RTO, but pilot light's need to provision and configure full services after failover typically pushes RTO beyond 1 hour, whereas warm standby's partially provisioned environment allows faster scaling.

Why the other options are wrong

Backup and restore with scheduled snapshots cannot meet the RPO of 15 minutes (snapshots are typically less frequent) and the RTO of about 1 hour (manual restores are slow and unpredictable).

Pilot light requires starting full services after failover, which typically takes more than 1 hour (RTO) due to provisioning and scaling, and may not meet the 15-minute RPO if data replication is not continuous.

Active/active requires full duplicate capacity in both Regions at all times, which contradicts the requirement that the business cannot afford full duplicate capacity in both Regions all the time.

Practice this question →

MCQmedium

Your order-processing system uses EventBridge rules to send events to a Lambda function that updates order status. Over the last week, some events fail with a transient database timeout, and the Lambda retries intermittently but then the events are lost (no alerts after failures). You want at-least-once processing, bounded retries, and a way to inspect unprocessable events for later reprocessing. Which architecture change best meets these requirements?

A.Send EventBridge events to an SQS queue, configure a redrive policy to move messages to a dead-letter queue (DLQ) after a defined receive count, and make the Lambda processing idempotent.

B.Invoke Lambda directly from EventBridge in asynchronous mode, and increase the Lambda timeout to reduce failures.

C.Use SNS topics with Lambda subscriptions, but remove all retry and DLQ configuration to minimize duplicate events.

D.Store failed events only in CloudWatch logs, and have operators manually copy log entries back into the database for reprocessing.

AnswerA

EventBridge-to-SQS provides buffering and decoupling; SQS redrive with a DLQ bounds retries and preserves failed events for analysis and replay.

Why this answer

It introduces an SQS queue between EventBridge and Lambda, which provides a durable buffer for events. The redrive policy moves events to a dead-letter queue (DLQ) after a defined number of failed processing attempts, ensuring bounded retries and preserving unprocessable events for later inspection and reprocessing. Making the Lambda idempotent guarantees at-least-once processing even if duplicate events occur.

Exam trap

The trap here is that candidates may think increasing Lambda timeout or relying on asynchronous invocation retries alone is sufficient, but they overlook the need for a DLQ to capture and inspect events that persistently fail, which is a key requirement for operational visibility and reprocessing.

Why the other options are wrong

Asynchronous Lambda invocation from EventBridge has limited retry (0-2 attempts) and no DLQ support, so events lost after transient failures cannot be inspected or reprocessed, failing the requirement for bounded retries and inspectability.

Removing retry and DLQ configuration prevents at-least-once processing and makes it impossible to inspect unprocessable events, directly contradicting the requirements.

Storing failed events only in CloudWatch logs and manually reprocessing them does not provide automated retries, bounded retries, or a systematic way to inspect and reprocess unprocessable events, violating the requirements for at-least-once processing and automated reprocessing.

Practice this question →

MCQeasy

A inventory service exposes a static website from S3 and CloudFront. Users should still receive cached pages if the S3 origin has a short outage. Which feature helps most? The architecture review board prefers a managed AWS-native control.

A.CloudFront caching with appropriate TTLs

B.AWS Backup Vault Lock

C.IAM Access Analyzer

D.S3 Select

AnswerA

CloudFront can serve cached content from edge locations when the origin is temporarily unavailable.

Why this answer

CloudFront caching with appropriate TTLs allows cached responses to be served to users even when the S3 origin is temporarily unavailable. By setting a minimum TTL (e.g., 0 seconds for fresh content, but a higher default or maximum TTL for stale content), CloudFront can continue delivering previously cached pages from edge locations during an S3 outage, ensuring high availability and resilience. This is a managed AWS-native feature that aligns with the architecture review board's preference.

Exam trap

The trap here is that candidates may confuse data protection features (like Backup Vault Lock) or data retrieval tools (like S3 Select) with caching and origin resilience, overlooking that CloudFront's TTL-based caching is the direct AWS-managed solution for serving content during origin outages.

How to eliminate wrong answers

Option B (AWS Backup Vault Lock) is wrong because it is a data protection feature for backup vaults that prevents deletion of backups, not a mechanism to serve cached content during an origin outage. Option C (IAM Access Analyzer) is wrong because it analyzes resource-based policies to identify unintended public access, not to cache or serve static content. Option D (S3 Select) is wrong because it is a query-in-place feature that retrieves subsets of data from objects using SQL expressions, and it does not provide caching or resilience against origin outages.

Practice this question →

MCQeasy

Based on the exhibit, a web application must stay available if one Availability Zone fails. What is the best change to improve resilience?

A.Increase the desired capacity to 8 instances in the same subnet.

B.Add a subnet in another Availability Zone to the Auto Scaling group and keep the ALB spanning both AZs.

C.Replace the Application Load Balancer with a Network Load Balancer.

D.Move the instances to a larger instance type with more CPU and memory.

AnswerB

This places application instances across multiple Availability Zones, which protects the stateless tier from a single-AZ failure. The ALB already spans two AZs, so the missing piece is the Auto Scaling group using subnets in more than one AZ. That allows AWS to replace unhealthy instances and continue serving traffic from the surviving Zone.

Why this answer

Adding a subnet in another Availability Zone (AZ) to the Auto Scaling group and keeping the ALB spanning both AZs ensures that if one AZ fails, the ALB can route traffic to healthy instances in the other AZ. This is the standard pattern for building multi-AZ resilient architectures with Auto Scaling and ALB, as it eliminates the single point of failure at the AZ level.

Exam trap

The trap here is that candidates often focus on scaling up (more instances or larger instances) or changing the load balancer type, missing the fundamental requirement of distributing resources across multiple Availability Zones to achieve AZ-level resilience.

How to eliminate wrong answers

Option A is wrong because increasing the desired capacity to 8 instances in the same subnet does not protect against an AZ failure; all instances remain in a single AZ, so if that AZ goes down, all instances become unavailable. Option C is wrong because replacing the ALB with a Network Load Balancer does not inherently improve resilience against AZ failure; both ALB and NLB can span multiple AZs, but the key issue is the lack of multi-AZ instance placement, not the load balancer type. Option D is wrong because moving to a larger instance type with more CPU and memory improves performance but does not address AZ-level fault tolerance; a single AZ failure would still take down all instances regardless of size.

Practice this question →

Multi-Selectmedium

A retail API runs on Amazon EC2 instances behind an Application Load Balancer and stores orders in an Amazon RDS for PostgreSQL database. A test that stopped one Availability Zone caused the API to return errors because all application servers were in the same AZ and the database was single-AZ. Which two changes should the architect make to continue serving traffic during a single-AZ failure? Select two.

Select 2 answers

A.Increase the EC2 instance size and keep all application servers in the same subnet.

B.Configure the Auto Scaling group to launch instances across private subnets in at least two Availability Zones.

C.Replace the Application Load Balancer with a Network Load Balancer in a single Availability Zone.

D.Convert the RDS for PostgreSQL database to a Multi-AZ deployment.

E.Add an Amazon RDS read replica and point the application to the replica endpoint.

AnswersB, D

Spreading the application tier across multiple AZs preserves healthy capacity if one AZ fails and lets the load balancer keep serving requests.

Why this answer

Distributing EC2 instances across private subnets in at least two Availability Zones (AZs) ensures that if one AZ fails, the Auto Scaling group can continue serving traffic from instances in the remaining AZs. This eliminates the single point of failure for the application tier. Option D is correct because converting the RDS for PostgreSQL database to a Multi-AZ deployment automatically provisions a standby replica in a different AZ, enabling automatic failover during an AZ outage and preserving database availability.

Exam trap

The trap here is that candidates often think a read replica can serve as a high-availability solution for writes, but read replicas are asynchronous and do not support automatic failover for the primary database.

Why the other options are wrong

Increasing EC2 instance size and keeping all servers in one subnet does not provide fault tolerance across Availability Zones; a single AZ failure would still take down all application servers.

A Network Load Balancer (NLB) in a single AZ cannot provide cross-AZ failover; the question requires serving traffic during a single-AZ failure, which demands multi-AZ architecture. An NLB alone does not address the lack of application server redundancy.

A read replica does not provide automatic failover; the application would need to manually switch to the replica endpoint, which does not address the single-AZ failure of the primary database. The question requires continued serving traffic during a single-AZ failure, which Multi-AZ provides by automatic failover.

Practice this question →

Matchingmedium

Match the disaster recovery strategy to the recovery posture it best fits for a Regional outage.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Lowest cost option where the environment is rebuilt from backups and hours of downtime are acceptable.

Keep only the critical core running in the secondary Region, then scale out after failover.

Run a scaled-down but functional environment in another Region for faster cutover.

Serve production traffic from more than one Region at the same time for the fastest recovery.

Why these pairings

These pairs match disaster recovery strategies to their recovery postures, aligning with AWS DR strategies where RTO and RPO define the recovery objectives.

Practice this question →

MCQeasy

A team uses an S3 bucket to store important customer-generated exports. They need protection against accidental overwrites and also want copies of the data in another AWS Region for disaster recovery. Which S3 configuration best satisfies both requirements?

A.Enable S3 lifecycle policies to automatically move objects to Glacier after 30 days only.

B.Enable S3 versioning and configure Cross-Region Replication to a destination bucket in another Region.

C.Disable all versioning and rely on AWS Backup to restore objects from a scheduled backup window.

D.Enable S3 Block Public Access and SSE-S3 encryption, without using versioning or replication.

AnswerB

Versioning preserves previous object states against overwrites and deletes, while replication provides an additional Region copy for recovery.

Why this answer

Enabling S3 versioning protects against accidental overwrites by preserving previous versions of objects, and configuring Cross-Region Replication (CRR) automatically replicates objects to a destination bucket in another AWS Region, providing disaster recovery. This combination meets both requirements without manual intervention.

Exam trap

The trap here is that candidates may think AWS Backup alone can handle both accidental overwrites and disaster recovery, but it does not provide continuous versioning protection or real-time cross-region replication, and disabling versioning removes the ability to recover from overwrites.

How to eliminate wrong answers

Option A is wrong because lifecycle policies to Glacier only manage storage tier transitions and do not protect against accidental overwrites or provide cross-region replication for disaster recovery. Option C is wrong because disabling versioning removes the ability to recover from accidental overwrites, and relying solely on AWS Backup for scheduled restores does not provide real-time protection or continuous replication to another region. Option D is wrong because enabling Block Public Access and SSE-S3 encryption addresses security and encryption, but does not protect against accidental overwrites (no versioning) nor replicate data to another region (no replication).

Practice this question →

Multi-Selectmedium

A customer portal must recover from a regional outage within a few hours. The business wants lower ongoing cost than a fully active second Region and does not want to rebuild everything from scratch during the outage. Which two DR patterns best fit that goal? Select two.

Select 2 answers

A.Backup and restore

B.Pilot light

C.Warm standby

D.Multi-site active-active

E.Single-AZ deployment

AnswersB, C

Pilot light keeps only core components running in the secondary Region, which lowers cost while reducing recovery time.

Why this answer

Pilot light is correct because it maintains a minimal core infrastructure (e.g., database, networking) in the secondary Region that can be quickly scaled up during a disaster, meeting the recovery time objective (RTO) of a few hours while keeping ongoing costs lower than a fully active second Region. It avoids rebuilding everything from scratch by having critical data and configurations already in place, allowing compute resources to be launched on demand.

Exam trap

AWS often tests the distinction between pilot light and warm standby—the trap here is that candidates may confuse pilot light with backup and restore, not realizing that pilot light maintains a live, minimal environment (e.g., database replicas) rather than just backup files, enabling faster recovery without full rebuild.

Why the other options are wrong

Backup and restore typically has a Recovery Time Objective (RTO) of hours to days, which may not meet the 'within a few hours' requirement, and it often involves rebuilding infrastructure from backups, which the question explicitly wants to avoid.

Multi-site active-active requires fully active resources in two regions simultaneously, which incurs higher ongoing costs than a fully active second Region, contradicting the requirement for lower cost.

Single-AZ deployment does not provide any cross-region recovery capability; a regional outage would cause complete downtime, contradicting the requirement to recover within hours.

Practice this question →

Multi-Selectmedium

A solutions architect is designing a highly available and resilient architecture for a critical internal application that processes financial transactions. The application runs on Amazon EC2 instances inside an Auto Scaling group. The database layer uses an Amazon Aurora MySQL cluster. The company requires that if an entire AWS Availability Zone (AZ) fails, the application must remain operational with minimal impact and automatically recover without manual intervention. Which combination of architectural decisions will meet these requirements? (Choose four.)

Select 4 answers

.Configure the Auto Scaling group to span at least three Availability Zones in the same AWS Region.

.Deploy the Aurora cluster with a single DB instance to reduce complexity and cost.

.Configure the Aurora cluster to include at least one Aurora Replica in a different Availability Zone than the primary instance.

.Use an Application Load Balancer (ALB) to distribute traffic across EC2 instances in multiple Availability Zones.

.Place the EC2 instances in a single Availability Zone to ensure data locality with the primary database.

.Set up an Amazon RDS Proxy to manage database connections and provide connection pooling for improved resilience.

Why this answer

Configuring the Auto Scaling group to span at least three Availability Zones ensures that if one AZ fails, the remaining AZs have sufficient capacity to handle the load, and the Auto Scaling group can automatically launch new instances in the healthy AZs. Deploying the Aurora cluster with at least one Aurora Replica in a different AZ than the primary instance provides automatic failover to a replica in under 30 seconds, ensuring database resilience without manual intervention. Using an Application Load Balancer (ALB) to distribute traffic across EC2 instances in multiple AZs allows the ALB to automatically route traffic away from failed AZs and only to healthy targets, maintaining application availability.

Setting up an Amazon RDS Proxy manages database connections by pooling and reusing them, which reduces the load on the database during failover and improves resilience by providing seamless connection handling across AZ failures.

Exam trap

The trap here is that candidates often think a single Aurora instance with multi-AZ storage is sufficient, but without an Aurora Replica in a different AZ, automatic failover is not possible; similarly, they may assume that placing all EC2 instances in one AZ simplifies data locality, but this sacrifices availability for a false sense of performance optimization.

Practice this question →

MCQmedium

A claims workflow uses an RDS MySQL database and must remain available during an Availability Zone failure with minimal application changes. What should the architect enable?

A.S3 Cross-Region Replication

B.Multi-AZ deployment for the RDS DB instance

C.EBS snapshots every hour

D.Read replicas only

AnswerB

Multi-AZ provides synchronous standby replication and automatic failover within a Region.

Why this answer

Multi-AZ deployment for RDS MySQL automatically provisions and maintains a synchronous standby replica in a different Availability Zone. In the event of an AZ failure, Amazon RDS automatically fails over to the standby, providing high availability with minimal application changes (the application simply reconnects to the same endpoint). This meets the requirement for availability during an AZ outage without requiring code modifications.

Exam trap

The trap here is that candidates often confuse read replicas (which are for read scaling and manual promotion) with Multi-AZ (which provides automatic failover and high availability), leading them to select 'Read replicas only' as a cheaper but incorrect alternative.

How to eliminate wrong answers

Option A is wrong because S3 Cross-Region Replication is designed for object-level replication across AWS regions, not for database high availability within a region, and it does not provide automatic failover for an RDS MySQL database. Option C is wrong because EBS snapshots every hour provide point-in-time backup and recovery, not automatic failover; restoring from a snapshot requires manual intervention and results in data loss for transactions after the last snapshot. Option D is wrong because read replicas only provide read scaling and asynchronous replication; they do not support automatic failover for write operations, and promoting a read replica to a primary requires manual action and potential data loss.

Practice this question →

Multi-Selecteasy

A developer accidentally corrupts part of a production Amazon RDS database, and the issue is discovered 45 minutes later. The team needs to restore the database to the state immediately before the change. Which two actions should be part of the recovery plan? Select two.

Select 2 answers

A.Enable automated backups with a retention period that covers the recovery window.

B.Perform a point-in-time restore to a new database instance.

C.Convert the database to a single-AZ deployment for faster restores.

D.Delete the corrupted rows manually and continue without restoring.

E.Use a read replica as the only recovery source for all deletions.

AnswersA, B

AWS RDS automated backups are foundational for Point-in-Time Recovery (PITR), capturing daily snapshots and continuously archiving transaction logs. A sufficient retention period is crucial, as it dictates how far back in time a database can be restored. If the corruption occurred outside the defined retention window, the specific recovery point before the incident would be unavailable, rendering PITR ineffective for that event.

Why this answer

Automated backups must be enabled to allow point-in-time recovery (PITR) within the retention window. Since the corruption occurred 45 minutes ago, the retention period must cover at least that duration to restore to the state immediately before the change. Option B is correct because PITR restores the database to a specified time (down to the second) within the backup retention period, creating a new DB instance that reflects the state just before the corruption.

Exam trap

The trap here is that candidates may think a read replica can be used for point-in-time recovery, but it only provides read scaling and asynchronous replication, not a restore point before the corruption occurred.

Practice this question →

MCQeasy

Based on the exhibit, the database must fail over automatically if the primary Availability Zone goes down. Which solution should the architect choose?

A.Create a read replica in the same Availability Zone as the primary database.

B.Convert the database to a Multi-AZ RDS deployment.

C.Increase the backup retention period to 35 days.

D.Move the database to an EC2 instance with an attached EBS volume.

AnswerB

A Multi-AZ RDS deployment keeps a synchronous standby in another Availability Zone and automatically fails over when the primary fails. This matches the requirement for minimal manual intervention and preserves the same database endpoint, so the application does not need connection string changes. It is the standard AWS choice for resilient relational databases.

Why this answer

A Multi-AZ RDS deployment automatically synchronously replicates data to a standby instance in a different Availability Zone. If the primary AZ fails, Amazon RDS automatically performs a failover to the standby, ensuring high availability without manual intervention. This meets the requirement for automatic failover when the primary AZ goes down.

Exam trap

The trap here is that candidates often confuse read replicas (which are for read scaling and require manual promotion) with Multi-AZ deployments (which provide automatic failover), leading them to incorrectly select Option A.

Why the other options are wrong

A read replica in the same Availability Zone does not provide automatic failover if the primary AZ goes down; it is designed for read scaling, not high availability.

Increasing the backup retention period to 35 days does not provide automatic failover; it only extends the point-in-time recovery window. The question requires automatic failover when the primary Availability Zone fails, which Multi-AZ RDS provides.

Moving the database to an EC2 instance with an attached EBS volume does not provide automatic failover; you would need to manually manage failover or implement custom scripting, which does not meet the requirement for automatic failover when the primary Availability Zone goes down.

Practice this question →

MCQmedium

A global application experiences frequent writes and must survive a full Regional outage with near-zero data loss. The product team also requires that users can continue to write during the incident using the closest Region. Which approach is most aligned with these requirements?

A.Use an active/active design with multi-Region data replication (for example, global tables for the write-heavy datastore) and route traffic to multiple Regions based on health and latency.

B.Use warm standby with periodic backups of the primary write datastore every 24 hours.

C.Use pilot light where the secondary Region runs only infrastructure templates and starts data replication only after detecting failure.

D.Use a single-writer model in one Region and deploy read-only replicas in the other Region for continuity.

AnswerA

Active/active supports writing in multiple Regions and reduces the blast radius of a Regional failure while enabling continued operations.

Why this answer

An active/active design with multi-Region data replication, such as DynamoDB global tables, allows writes to occur in any Region and replicates data asynchronously across Regions with sub-second latency. This ensures near-zero data loss (RPO of seconds) and continuous write availability during a full Regional outage, while Route 53 latency-based routing directs users to the closest healthy Region.

Exam trap

The trap here is that candidates often confuse 'read-only replicas' (which cannot accept writes) with 'multi-Region write replicas' (which can), leading them to choose Option D despite its inability to support writes during an outage.

How to eliminate wrong answers

Option B is wrong because warm standby with 24-hour periodic backups cannot achieve near-zero data loss; the RPO would be up to 24 hours, and writes would stop during failover. Option C is wrong because pilot light starts data replication only after failure detection, leading to minutes of data loss and write unavailability during the replication setup. Option D is wrong because a single-writer model with read-only replicas prevents writes during a Regional outage, violating the requirement that users continue to write during the incident.

Practice this question →

MCQhard

A claims workflow uses Amazon SQS. Poison messages are repeatedly failing and blocking useful retries. What should the architect configure? The architecture review board prefers a managed AWS-native control.

A.A FIFO queue without a redrive policy

B.Short polling instead of long polling

C.A dead-letter queue with an appropriate maxReceiveCount

D.A larger message retention period only

AnswerC

A DLQ isolates messages that fail repeatedly so they can be investigated without disrupting normal processing.

Why this answer

A dead-letter queue (DLQ) with an appropriate maxReceiveCount allows messages that repeatedly fail processing to be moved out of the source queue after a specified number of receive attempts. This prevents poison messages from blocking useful retries and is a fully managed AWS-native pattern. The architecture review board's preference for a managed solution is satisfied because SQS DLQs are a built-in feature requiring no custom code.

Exam trap

The trap here is that candidates may confuse a DLQ with simply increasing retention or changing polling behavior, not realizing that poison messages require explicit isolation via a separate queue and a maxReceiveCount threshold to stop infinite retries.

How to eliminate wrong answers

Option A is wrong because a FIFO queue without a redrive policy does not automatically handle poison messages; without a DLQ, failed messages remain in the queue and continue to block retries. Option B is wrong because short polling reduces latency but does not address poison messages; it returns only a subset of servers' messages and can increase empty responses, but it has no effect on message failure handling. Option D is wrong because increasing the message retention period only keeps messages longer without removing failing ones; poison messages would still be retried until they expire, continuing to block useful retries.

Practice this question →

MCQhard

A patient portal must process every event at least once, but duplicate processing is acceptable if the consumer handles idempotency. Which eventing approach is most suitable? The team wants the control to be enforceable during normal operations.

A.Use an in-memory queue on one EC2 instance

B.Use UDP messages sent directly to workers

C.Use Amazon SQS standard queue and design consumers to be idempotent

D.Use CloudFront signed URLs

AnswerC

SQS standard queues provide at-least-once delivery and high throughput; consumers must handle occasional duplicates.

Why this answer

Amazon SQS standard queues provide at-least-once delivery, ensuring every event is processed at least once, which matches the requirement. Duplicate processing is acceptable because the team can design consumers to be idempotent, handling duplicates without side effects. SQS is a fully managed, scalable, and durable service that enforces this behavior during normal operations without requiring custom infrastructure.

Exam trap

The trap here is that candidates may confuse 'at-least-once' delivery with 'exactly-once' delivery, or incorrectly assume that UDP or in-memory queues can provide reliable event processing, when in fact only a managed queue service like SQS with idempotent consumers meets the stated requirement for enforceability during normal operations.

How to eliminate wrong answers

Option A is wrong because an in-memory queue on a single EC2 instance is not durable, cannot survive instance failures, and does not provide at-least-once delivery guarantees across restarts or scaling events. Option B is wrong because UDP is a connectionless, unreliable protocol that does not guarantee message delivery, order, or duplicate detection, making it unsuitable for at-least-once processing. Option D is wrong because CloudFront signed URLs are used for access control to content delivery, not for event processing or messaging, and they do not provide any delivery guarantee or queue semantics.

Practice this question →

Drag & Dropmedium

Order the steps to create a static website using Amazon S3 and CloudFront.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

S3 bucket with hosting, upload files, CloudFront distribution, configure CloudFront, then DNS.

Practice this question →

MCQeasy

A worker service consumes messages from an Amazon SQS queue. Some messages are malformed and always fail validation. The worker retries, but it keeps reprocessing the same bad messages and consumes processing capacity that should be used for valid work. What is the best solution to prevent “poison messages” from blocking progress?

A.Configure a Dead-Letter Queue (DLQ) and set a redrive policy so messages move to the DLQ after a maximum number of receives.

B.Increase the visibility timeout so the worker gets fewer retries per hour.

C.Disable SQS retries by deleting messages immediately on any processing error.

D.Create a second worker that polls the queue less frequently until the malformed message is processed successfully.

AnswerA

Configuring a Dead-Letter Queue (DLQ) with a redrive policy is the most effective solution. This mechanism automatically moves messages that fail processing a specified number of times (maxReceiveCount) from the source queue to the DLQ. This prevents 'poison pill' messages from continuously consuming worker resources and allows for their isolation, analysis, and eventual reprocessing or discarding without impacting the main message flow.

Why this answer

A Dead-Letter Queue (DLQ) with a redrive policy is the standard AWS mechanism for handling poison messages. By setting a maximum receive count (e.g., 5), the SQS queue automatically moves messages that fail processing repeatedly to the DLQ, isolating them from the main queue. This prevents the worker from wasting capacity on invalid messages and allows the main queue to continue processing valid work without interruption.

Exam trap

The trap here is that candidates may think increasing the visibility timeout or deleting messages on error is a valid solution, but AWS specifically designed the DLQ pattern to isolate poison messages without losing data or impacting throughput.

How to eliminate wrong answers

Option B is wrong because increasing the visibility timeout only delays the retry, it does not prevent the worker from eventually reprocessing the same bad message, so the poison message still consumes processing capacity. Option C is wrong because SQS does not support disabling retries; deleting messages immediately on error would lose the message entirely without any chance for recovery or analysis, which is not a best practice. Option D is wrong because creating a second worker that polls less frequently does not solve the problem—the malformed message will still be retried and block progress, and a slower poll rate only reduces throughput without addressing the root cause.

Practice this question →

MCQeasy

A company runs its customer-facing web app on EC2 behind an Application Load Balancer. The database is Amazon RDS for PostgreSQL. The requirement is that if a single Availability Zone fails, the database must automatically fail over within the same AWS Region with minimal application changes. Which database setup best meets this requirement?

A.Use an RDS single-AZ instance and periodically restore from automated backups if needed.

B.Deploy the RDS PostgreSQL instance as Multi-AZ with automatic failover enabled.

C.Create a read replica in a different AZ and use it only when the primary fails.

D.Use RDS with Multi-AZ disabled, but increase storage IOPS to prevent failover.

AnswerB

Multi-AZ RDS maintains a standby instance in a different AZ. If the primary fails, RDS performs automatic failover, preserving the same database endpoint behavior.

Why this answer

RDS Multi-AZ for PostgreSQL automatically provisions and maintains a synchronous standby replica in a different Availability Zone. If the primary AZ fails, Amazon RDS automatically fails over to the standby, typically within 60–120 seconds, with no changes required to the application's connection string (the DNS name remains the same). This meets the requirement for minimal application changes and automatic failover within the same Region.

Exam trap

The trap here is that candidates often confuse a read replica (which requires manual promotion and DNS changes) with a Multi-AZ standby (which provides automatic, transparent failover), leading them to incorrectly select Option C.

Why the other options are wrong

Single-AZ RDS with manual backup restoration does not provide automatic failover; it requires manual intervention and incurs significant downtime, failing the requirement for automatic failover within the same Region.

A read replica is not designed for automatic failover; promoting it requires manual intervention or additional scripting, which does not meet the 'automatically fail over' requirement with minimal application changes.

Multi-AZ disabled means no automatic failover; increasing IOPS improves performance but does not provide high availability across AZs, so it fails the requirement of automatic failover during an AZ failure.

Practice this question →

Multi-Selectmedium

A company is deploying a stateless web application on Amazon ECS with Fargate. The application must be resilient to individual task failures and Availability Zone failures. Which three steps should the company take to achieve this resilience? (Choose three.)

Select 3 answers

.Configure the ECS service to use a spread placement strategy across Availability Zones.

.Set a minimum healthy percent of 50 and a maximum percent of 200 in the ECS service deployment configuration.

.Place all ECS tasks in a single subnet to minimize network latency.

.Use an Application Load Balancer (ALB) in front of the ECS service to distribute traffic across tasks.

.Store application session data in an attached EFS file system shared across all tasks.

.Disable automatic task replacement to avoid unnecessary task churn during failures.

Why this answer

Configuring the ECS service with a spread placement strategy across Availability Zones ensures tasks are distributed across multiple AZs, providing resilience against AZ failures. Setting a minimum healthy percent of 50 and a maximum percent of 200 allows the service to maintain at least half of the desired tasks during deployments or failures while scaling up to replace failed tasks without downtime. Using an Application Load Balancer (ALB) in front of the ECS service distributes incoming traffic across healthy tasks in different AZs, automatically rerouting traffic if a task or AZ fails.

Exam trap

The trap here is that candidates may confuse stateless applications with stateful ones and incorrectly choose to store session data in EFS, or they may think placing tasks in a single subnet improves performance without considering the single point of failure risk.

Practice this question →

Multi-Selectmedium

A media company stores daily financial exports in Amazon S3. The files must be protected against accidental overwrite or deletion, and the business also wants a second copy in another Region for recovery after a regional outage. Which two actions should the architect take? Select two.

Select 2 answers

A.Enable bucket versioning on the S3 bucket.

B.Turn on S3 Transfer Acceleration for the bucket.

C.Use only lifecycle policies to move objects to Glacier.

D.Configure replication to a bucket in a second AWS Region.

E.Enable S3 Block Public Access on the bucket.

AnswersA, D

Versioning preserves prior object versions so accidental deletes and overwrites can be recovered later.

Why this answer

Enabling S3 Versioning on the bucket protects objects from accidental overwrite or deletion by preserving previous versions of each object. When versioning is enabled, a delete marker is placed instead of permanently removing the object, and overwrites create a new version while retaining the old one. This directly meets the requirement to guard against accidental data loss.

Exam trap

The trap here is that candidates may confuse S3 Transfer Acceleration or Block Public Access with data protection features, when in fact only versioning and replication directly address the requirements for preventing accidental deletion and providing cross-region recovery.

Why the other options are wrong

S3 Transfer Acceleration speeds up uploads over long distances but does not protect against accidental deletion or overwrite, nor does it create a cross-region copy for disaster recovery.

Lifecycle policies to move objects to Glacier provide cost optimization for long-term storage, but do not protect against accidental overwrite/deletion or provide cross-region recovery.

Block Public Access prevents public access to S3 objects but does not protect against accidental overwrite or deletion by authorized users, nor does it provide cross-region replication for disaster recovery.

Practice this question →

Multi-Selectmedium

A serverless order-ingestion API writes directly to a database. During traffic spikes, the database occasionally throttles, Lambda retries create duplicate order records, and some requests time out. Which two changes best improve buffering and safe retry behavior? Select two.

Select 2 answers

A.Increase the Lambda timeout and keep writing directly to the database.

B.Put an Amazon SQS queue between the API and the database-processing function.

C.Replace SQS with SNS so every request is delivered immediately to all subscribers.

D.Make the database write idempotent by using a unique request token or order ID.

E.Disable retries so failed writes are never duplicated.

AnswersB, D

SQS buffers bursts and decouples producers from consumers, so the database can be processed at a steadier rate.

Why this answer

Inserting an SQS queue between the API Gateway and the Lambda function decouples the ingestion from the database write. During traffic spikes, SQS buffers the requests, allowing the Lambda function to poll at a controlled rate, which prevents database throttling. Additionally, SQS provides built-in retry logic with a visibility timeout, so failed messages are automatically retried without creating duplicate order records.

Exam trap

The trap here is that candidates often think SNS (Option C) is a suitable replacement for SQS because both are messaging services, but SNS lacks buffering and retry mechanics, making it inappropriate for smoothing traffic spikes and handling failures gracefully.

Why the other options are wrong

Increasing Lambda timeout does not address database throttling or duplicate records; it only allows the function to wait longer, but the database will still throttle under load, and retries will still create duplicates.

SNS pushes messages to all subscribers immediately without buffering or throttling, so it does not help with database throttling or retry management; it would still overwhelm the database and cause duplicate processing.

Disabling retries entirely would cause order writes to fail permanently during throttling, losing data and increasing timeouts, which contradicts the need for safe retry behavior.

Practice this question →

MCQeasy

An engineering team deploys a stateless web API on EC2 using an Auto Scaling group and an Application Load Balancer (ALB). During a recent test, they noticed that when one Availability Zone was unavailable, traffic failed until new instances were manually launched. Which change most directly improves automatic failover for the compute layer within a single Region?

A.Place the Auto Scaling group in only one subnet so instance launches are simpler.

B.Ensure the ALB and Auto Scaling group span multiple subnets in at least two Availability Zones.

C.Increase the target group deregistration delay to allow old instances to stay longer.

D.Use a Network Load Balancer, but keep all subnets in a single Availability Zone.

AnswerB

Spreading the ALB and Auto Scaling group across at least two AZs provides redundant capacity. If one AZ fails, the ALB continues routing to healthy targets in the other AZ.

Why this answer

Placing both the ALB and the Auto Scaling group across multiple subnets in at least two Availability Zones ensures that if one AZ becomes unavailable, the ALB can route traffic to healthy instances in the remaining AZs, and the Auto Scaling group can automatically launch replacement instances in the other AZs. This directly provides automatic failover for the compute layer within a single Region without manual intervention.

Exam trap

The trap here is that candidates may think a single-AZ setup with a load balancer is sufficient for high availability, but without multi-AZ subnets for both the ALB and Auto Scaling group, the architecture remains vulnerable to AZ failure and requires manual recovery.

How to eliminate wrong answers

Option A is wrong because placing the Auto Scaling group in only one subnet (single AZ) creates a single point of failure; if that AZ becomes unavailable, all instances are lost and traffic fails until new instances are manually launched in another AZ. Option C is wrong because increasing the target group deregistration delay only keeps old instances longer during a deregistration process, which does not help with failover when an entire AZ is unavailable; it delays traffic draining but does not provide automatic recovery from AZ failure. Option D is wrong because using a Network Load Balancer in a single AZ still creates a single point of failure; the NLB cannot route traffic to other AZs if the only AZ is down, and it does not improve automatic failover compared to an ALB spanning multiple AZs.

Practice this question →

Multi-Selecthard

A regional web application for a inventory service must fail over automatically to a secondary Region if the primary endpoint becomes unhealthy. Which two services or features are required? The team wants the control to be enforceable during normal operations.

Select 2 answers

A.Route 53 failover routing with health checks

B.S3 Transfer Acceleration

C.A deployed standby application stack in the secondary Region

D.AWS Organizations service control policies

AnswersA, C

Route 53 can monitor endpoint health and return the standby endpoint when the primary is unhealthy.

Why this answer

Route 53 failover routing with health checks is correct because it enables automatic DNS-level failover to a secondary Region when the primary endpoint is unhealthy. Route 53 health checks monitor the primary endpoint's health, and if they detect a failure, the DNS record is updated to route traffic to the secondary Region's endpoint. This provides enforceable control during normal operations by allowing you to define routing policies that are active at all times.

Exam trap

The trap here is that candidates may think DNS-level failover alone is sufficient, forgetting that a fully deployed standby stack in the secondary Region is required to actually serve traffic after failover.

Practice this question →

MCQmedium

A.Backup and restore only, relying on scheduled snapshots and manual restores during incidents.

B.Pilot light, keeping only minimal infrastructure in the secondary Region and starting full services after failover.

C.Warm standby, keeping core infrastructure and a partially provisioned environment ready in the secondary Region with frequent data replication.

D.Active/active, routing production traffic to both Regions continuously and accepting dual-region complexity.

AnswerC

Warm standby balances cost and readiness by keeping enough capacity and services running to shorten recovery time while meeting RPO needs.

Why this answer

Warm standby is the best fit because it maintains a partially provisioned environment in the secondary Region with core infrastructure (e.g., a smaller EC2 instance fleet, a replicated database) and uses frequent data replication (e.g., Amazon RDS cross-Region replication or DynamoDB global tables) to achieve an RPO of 15 minutes. The RTO of about 1 hour is achievable by scaling up the standby environment and redirecting traffic, which is faster than a full rebuild but avoids the cost of full duplicate capacity. This balances the business constraint of not affording active/active with the need for automated readiness and guided failover.

Exam trap

The trap here is that candidates often confuse pilot light with warm standby, assuming minimal infrastructure is sufficient for a 1-hour RTO, but pilot light requires provisioning compute resources after failover, which adds significant time, whereas warm standby already has compute running and only needs scaling.

How to eliminate wrong answers

Option A is wrong because backup and restore only relies on scheduled snapshots (e.g., EBS snapshots or RDS automated backups) and manual restores, which typically cannot achieve an RPO of 15 minutes (snapshots are often taken every few hours) and would result in an RTO far exceeding 1 hour due to manual intervention and data restoration time. Option B is wrong because pilot light keeps only minimal infrastructure (e.g., a small database replica and no application servers) in the secondary Region, and starting full services after failover requires provisioning compute resources, which would likely exceed the 1-hour RTO target. Option D is wrong because active/active requires full duplicate capacity in both Regions all the time, which contradicts the business constraint that they cannot afford this, and it introduces dual-region complexity that is unnecessary for the stated RPO/RTO goals.

Practice this question →

Multi-Selectmedium

A SaaS application is deployed in us-east-1 and us-west-2 behind separate ALBs. The business wants DNS to send new clients to the primary Region when it is healthy and automatically fail over to the secondary Region when the primary endpoint is unhealthy. Which two Route 53 settings are required? Select two.

Select 2 answers

A.Use a failover routing policy with a primary and secondary record.

B.Create a health check and associate it with the primary endpoint.

C.Use weighted routing with a 50/50 traffic split between both Regions.

D.Use latency-based routing so clients always choose the fastest Region.

E.Use a geolocation policy without health checks.

AnswersA, B

Failover routing is designed specifically to send traffic to a secondary endpoint when the primary becomes unhealthy.

Why this answer

A failover routing policy is correct because it allows you to designate one record as primary and another as secondary. Route 53 will route traffic to the primary record as long as it is healthy, and automatically fail over to the secondary record when the primary becomes unhealthy. This directly meets the requirement to send new clients to the primary region when healthy and fail over automatically.

Exam trap

The trap here is that candidates often confuse failover routing with weighted or latency-based routing, assuming any multi-region setup with health checks will automatically fail over, but only failover routing provides the explicit primary/secondary failover behavior required.

Practice this question →

MCQmedium

A company uses Amazon RDS for a PostgreSQL database powering a customer-facing application. The application’s availability depends on fast database failover with minimal manual intervention. The RDS instance currently runs as a single-AZ deployment in one DB subnet group. Which change most directly meets the goal?

A.Create a read replica in a different Availability Zone and configure the application to fail over manually.

B.Enable Multi-AZ for the RDS DB instance so AWS manages a standby in another Availability Zone with automatic failover.

C.Switch the database to use EBS snapshots more frequently and restore in case of failure.

D.Pin the DB to a specific instance type with higher CPU credits to prevent CPU-related disconnects.

AnswerB

RDS Multi-AZ maintains a standby in another AZ and supports automatic failover, improving resilience and reducing manual work.

Why this answer

Enabling Multi-AZ for the RDS DB instance creates a synchronous standby replica in a different Availability Zone. AWS automatically handles failover to the standby with no manual intervention required, meeting the goal of fast database failover with minimal manual intervention.

Exam trap

The trap here is that candidates confuse a read replica (asynchronous, manual promotion) with Multi-AZ (synchronous, automatic failover), or assume that frequent backups or instance sizing improvements can substitute for a dedicated high-availability standby.

How to eliminate wrong answers

Option A is wrong because a read replica is asynchronous and intended for read scaling, not automatic failover; manual failover requires promoting the replica, which involves data loss risk and does not meet the 'minimal manual intervention' requirement. Option C is wrong because EBS snapshots are point-in-time backups that require manual restore and significant downtime, not fast automated failover. Option D is wrong because CPU credits apply to burstable instance types (e.g., T-series) and do not address database availability or failover; higher CPU credits prevent CPU throttling but do not provide a standby or automatic failover mechanism.

Practice this question →

MCQmedium

A trading dashboard stores uploaded documents in S3. The business requires a copy in another AWS Region for disaster recovery. What should be configured?

A.An EBS snapshot schedule

B.S3 Cross-Region Replication with versioning enabled

C.S3 lifecycle transition to Glacier Flexible Retrieval

D.A CloudFront distribution

AnswerB

CRR asynchronously replicates objects to a bucket in another Region and requires versioning.

Why this answer

S3 Cross-Region Replication (CRR) with versioning enabled automatically replicates objects to a destination bucket in a different AWS Region, providing a durable, low-latency disaster recovery copy. Versioning must be enabled on both source and destination buckets to track object changes and ensure consistency during replication. This meets the requirement for a cross-region copy without manual intervention.

Exam trap

The trap here is that candidates may confuse lifecycle transitions (which change storage class within the same region) with cross-region replication (which copies data to a different region), or assume EBS snapshots apply to S3 storage.

How to eliminate wrong answers

Option A is wrong because EBS snapshots are used for backing up EC2 block storage volumes, not for S3 objects, and they are region-specific unless manually copied. Option C is wrong because S3 lifecycle transition to Glacier Flexible Retrieval moves objects to a cold storage tier for cost savings, not to a different AWS Region for disaster recovery. Option D is wrong because CloudFront is a content delivery network that caches data at edge locations for low-latency access, not a mechanism for replicating data to another region for DR.

Practice this question →

MCQmedium

A SaaS platform serves an API using two regional deployments: us-east-1 (primary) and us-west-2 (secondary). Each region has its own ALB. The business requires automated DNS-based failover when the primary region becomes unhealthy, and they do not want manual DNS changes during incidents. Which Route 53 configuration is the best match?

A.Create a single Route 53 record using weighted routing across both ALBs with weights adjusted manually during an incident.

B.Use Route 53 failover routing with a primary record pointing to the us-east-1 ALB and a secondary record pointing to the us-west-2 ALB, each using health checks.

C.Use latency-based routing so Route 53 always selects the fastest region; health checks are unnecessary because client latency reflects availability.

D.Use a single A record with a static IP address that points to a NAT gateway, and update that IP during failure events.

AnswerB

Failover routing with health checks enables automatic switching of DNS responses when the primary endpoint fails health evaluation.

Why this answer

Route 53 failover routing is designed for active-passive configurations where traffic must automatically shift to a secondary endpoint when the primary fails. By attaching health checks to the primary record (us-east-1 ALB), Route 53 can detect regional unavailability and automatically route traffic to the secondary record (us-west-2 ALB) without manual intervention. This meets the requirement for DNS-based failover without manual DNS changes during incidents.

Exam trap

The trap here is that candidates often confuse latency-based routing with failover routing, assuming that lower latency implies availability, but latency routing does not incorporate health checks and cannot automatically redirect traffic away from an unhealthy region.

Why the other options are wrong

Weighted routing requires manual weight adjustments during incidents, which contradicts the requirement for automated DNS-based failover without manual changes.

Latency-based routing does not support health checks; it routes based solely on latency, not availability. If the primary region fails but still has low latency, traffic would still be sent there, causing downtime.

This option requires manual IP updates during failure, which contradicts the requirement for automated DNS-based failover without manual changes.

Practice this question →

Multi-Selecthard

A payments API requires point-in-time recovery and accidental-delete protection for a DynamoDB table. Which two settings should the architect enable? The architecture review board prefers a managed AWS-native control.

Select 2 answers

A.Deletion protection or tightly controlled delete permissions

B.Point-in-time recovery

C.Global secondary indexes

D.DAX

AnswersA, B

Deletion protection and least-privilege controls reduce accidental table removal risk.

Why this answer

Point-in-time recovery (PITR) enables continuous backups of the DynamoDB table, allowing restoration to any point within the last 35 days, which satisfies the requirement for point-in-time recovery. Deletion protection prevents accidental deletion of the table by blocking drop-table operations, meeting the accidental-delete protection requirement. Both are managed AWS-native controls that require no custom scripting or external tooling.

Exam trap

The trap here is that candidates often confuse operational features like DAX (caching) or GSIs (indexing) with data protection mechanisms, but neither provides backup/restore or deletion safeguards required for resilience and data durability.

Practice this question →

MCQmedium

A trading dashboard uses Aurora MySQL. The company wants fast cross-Region disaster recovery with low RPO. Which architecture should be considered?

A.A single-AZ Aurora cluster

B.Aurora Global Database

C.Manual snapshots copied monthly

D.An ElastiCache Redis replica

AnswerB

Aurora Global Database replicates with low latency to secondary Regions and supports faster disaster recovery than snapshot-only approaches.

Why this answer

Aurora Global Database is designed for cross-Region disaster recovery with a typical RPO of 1 second and RTO of less than 1 minute, using storage-based replication that does not impact database performance. This meets the low RPO requirement for a trading dashboard, where data loss must be minimized.

Exam trap

The trap here is that candidates might choose manual snapshots (Option C) thinking they are sufficient for DR, but they overlook the critical requirement of low RPO, which snapshots copied monthly cannot satisfy.

How to eliminate wrong answers

Option A is wrong because a single-AZ Aurora cluster provides no cross-Region replication and offers no disaster recovery across AWS Regions, resulting in potentially high RPO if the primary Region fails. Option C is wrong because manual snapshots copied monthly have an RPO of up to one month, which is far too high for a trading dashboard requiring low RPO. Option D is wrong because ElastiCache Redis is an in-memory cache, not a persistent database, and cannot serve as a cross-Region disaster recovery solution for Aurora MySQL data.

Practice this question →

MCQmedium

An events service publishes critical notifications using Amazon SNS. Three independent downstream systems (A, B, and C) subscribe to the topic. Downstream system B sometimes fails to process certain messages (for example, it times out or returns an error while handling the message), and you want: 1) failures in B to be isolated so A and C keep processing unaffected, and 2) messages that B cannot successfully process after retries to be sent to a DLQ for B. Which design best meets these requirements?

A.Subscribe each downstream directly with HTTPS endpoints and configure a single SNS dead-letter queue (DLQ) for the topic.

B.For each downstream system, create its own SQS queue, subscribe each SQS queue to the SNS topic, and configure a redrive policy with a DLQ for each SQS queue.

C.Use one shared SQS queue for all three downstream systems and configure a single DLQ only when all three downstream systems fail.

D.Use EventBridge rules to invoke A, B, and C synchronously with retries enabled, and send failures to a common DLQ.

AnswerB

SNS delivers the message independently to each subscribed SQS queue. If downstream B fails to process a message, B can avoid deleting it from its own queue; after visibility timeout and retry attempts, SQS redrives messages to B’s DLQ. A and C are isolated because they have separate queues and DLQs, so B’s failures do not prevent deliveries to A and C.

Why this answer

It creates a dedicated SQS queue for each downstream system, which isolates failures: if system B fails, its SQS queue will accumulate messages while systems A and C continue processing from their own queues. Each SQS queue can have a redrive policy that moves messages to a per-queue DLQ after the configured maximum retries are exhausted, satisfying the requirement for a B-specific DLQ without affecting the other subscribers.

Exam trap

The trap here is that candidates assume a single DLQ at the SNS topic level is sufficient, but SNS DLQs only apply to the SNS delivery failure (e.g., HTTP endpoint unreachable), not to downstream processing failures after the message is delivered to SQS.

How to eliminate wrong answers

Option A is wrong because a single SNS DLQ applies to the entire topic, not per-subscriber; if B fails, messages would be sent to the common DLQ for all subscribers, and A and C would still receive the message from SNS, but the DLQ is not isolated to B. Option C is wrong because a shared SQS queue for all three systems means a failure in B could block or delay messages for A and C, and a single DLQ would trigger only when all three fail, not when B alone fails. Option D is wrong because EventBridge synchronous invocation with a common DLQ would cause failures in B to potentially block or delay A and C (since synchronous calls are sequential), and the DLQ is shared, not isolated to B.

Practice this question →

MCQmedium

A stateless web API runs on EC2 instances behind an Application Load Balancer (ALB). The Auto Scaling group (ASG) currently uses subnets from only one Availability Zone, even though the ALB spans two Availability Zones. During maintenance of that single AZ, the ALB remains up but clients see timeouts because there are no healthy targets. Which change most directly improves resilience against an AZ failure?

A.Keep the ASG in one subnet/AZ, but enable ALB stickiness to reduce session interruption.

B.Update the ASG to launch instances across subnets in at least two Availability Zones and ensure ALB health checks target an application-ready path.

C.Add a NAT gateway in the public subnets so instances can reach the internet during maintenance events.

D.Create a second ALB in the same Availability Zone and route traffic using DNS failover.

AnswerB

Spreading instances across multiple AZs ensures the ALB can route to healthy targets even when one AZ fails.

Why this answer

The most direct fix for AZ failure resilience is to distribute the ASG across multiple Availability Zones. With the ALB already spanning two AZs, if the ASG only launches instances in one AZ, a failure of that AZ leaves the ALB with zero healthy targets, causing timeouts. By configuring the ASG to launch instances in at least two AZs and setting ALB health checks to an application-ready path, the ALB can route traffic to healthy instances in the surviving AZ, maintaining availability.

Exam trap

The trap here is that candidates may think adding a second ALB or enabling stickiness solves the problem, when the real issue is that the ASG is not distributing instances across multiple Availability Zones, leaving the ALB with no healthy targets during an AZ outage.

Why the other options are wrong

Enabling ALB stickiness does not address the root cause: the ASG has no healthy targets in the only AZ, so the ALB cannot route traffic to any instance, causing timeouts regardless of stickiness.

The issue is that EC2 instances are only in one AZ, so adding a NAT gateway does not provide healthy targets in the other AZ; NAT gateways enable outbound internet access but do not affect ALB target availability.

Creating a second ALB in the same AZ does not address the lack of healthy targets in the other AZ; the ALB is already spanning two AZs, but the ASG only has instances in one AZ. DNS failover would still route to the same AZ if both ALBs are in the same AZ, failing to provide resilience against an AZ failure.

Practice this question →

MCQmedium

A web application runs on an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ASG is currently attached to subnets in only two Availability Zones (AZs). During a planned maintenance window, one AZ becomes unavailable for about 25 minutes. Monitoring shows that targets in the remaining AZ go healthy, and the ALB/target group health checks report normal. However, users still experience intermittent connection failures and slower responses during the AZ outage. What change will most directly improve resilience against an AZ loss while keeping the same ALB-based design?

A.Set the ASG min capacity to 0 so instances can be recreated faster when an AZ recovers.

B.Extend the ASG to use subnets in three AZs so there is placement redundancy during an AZ outage, while continuing to keep traffic behind the ALB.

C.Increase the ALB idle timeout to 120 seconds to reduce connection drops.

D.Disable health checks on the target group so instances are not deregistered during the maintenance window.

AnswerB

An AZ outage reduces the number of AZs where the ASG can place instances. With only two AZs, losing one significantly limits capacity and can cause temporary shortages and uneven load distribution, even if existing targets are marked healthy. Expanding the ASG to subnets in three (or more) AZs provides additional placement options so the ASG can maintain the desired number of instances across the remaining AZ(s). The ALB will continue routing only to healthy targets, and the system is more likely to sustain stable response times during the outage.

Why this answer

B is correct because deploying the ASG across three Availability Zones (AZs) ensures that when one AZ becomes unavailable, the remaining two AZs can handle the full traffic load without overloading the instances. This placement redundancy directly addresses the intermittent connection failures and slower responses, as the ALB can distribute traffic only to healthy targets in the remaining AZs, maintaining capacity and performance. The current two-AZ setup lacks sufficient buffer capacity, causing the single remaining AZ to become overwhelmed during the outage.

Exam trap

The trap here is that candidates may focus on connection-level settings (idle timeout) or health check behavior, missing the fundamental architectural need for multi-AZ redundancy to maintain capacity during an AZ outage.

How to eliminate wrong answers

Option A is wrong because setting the ASG min capacity to 0 does not help during an AZ outage; it would actually allow all instances to be terminated, making the application unavailable, and it does not address the lack of capacity in the remaining AZ. Option C is wrong because increasing the ALB idle timeout to 120 seconds only keeps idle connections open longer, which does not prevent connection failures or slow responses caused by insufficient capacity in the remaining AZ; it may even mask underlying issues. Option D is wrong because disabling health checks on the target group would prevent the ALB from deregistering unhealthy instances, causing traffic to be routed to failed instances in the unavailable AZ, leading to more connection failures and no improvement in resilience.

Practice this question →

MCQmedium

A ticket booking system runs on EC2 instances behind an Application Load Balancer. The design must tolerate the failure of one Availability Zone. What should the Auto Scaling group configuration include? The architecture review board prefers a managed AWS-native control.

A.Subnets in at least two Availability Zones with health checks enabled

B.All instances in one larger subnet

C.A Network Load Balancer in one subnet

D.A single EC2 instance with detailed monitoring

AnswerA

An Auto Scaling group spanning multiple AZs can replace unhealthy instances and maintain capacity during an AZ failure.

Why this answer

An Auto Scaling group configured with subnets in at least two Availability Zones ensures that if one AZ fails, the remaining AZ(s) can continue to serve traffic. Health checks on the EC2 instances allow the Auto Scaling group to detect and replace unhealthy instances, maintaining the desired capacity across the surviving AZs. This aligns with the requirement for a managed AWS-native control to tolerate an AZ failure.

Exam trap

The trap here is that candidates might think a single large subnet or a Network Load Balancer provides AZ resilience, but subnets are AZ-scoped and an NLB is a separate load-balancing component, not an Auto Scaling group configuration setting.

How to eliminate wrong answers

Option B is wrong because placing all instances in one larger subnet, even if it spans multiple AZs (which is not possible as subnets are AZ-specific), does not provide AZ failure tolerance; a single AZ failure would take down all instances. Option C is wrong because a Network Load Balancer (NLB) is not a component of an Auto Scaling group configuration; the question asks what the Auto Scaling group should include, and an NLB is a separate resource, not a configuration setting within the group. Option D is wrong because a single EC2 instance, even with detailed monitoring, cannot tolerate the failure of one Availability Zone; if that instance resides in the failed AZ, the application becomes unavailable, and detailed monitoring does not provide redundancy.

Practice this question →

MCQeasy

A retail platform needs disaster recovery across AWS Regions. The business requirement is: RTO up to 6 hours, RPO up to 1 hour, and they want the ability to start serving quickly during a Region outage but do not want to run full production capacity continuously. Which DR strategy best fits these requirements?

A.Backup and restore only, with no continuously running infrastructure in the secondary Region.

B.Pilot light, keeping only the minimum resources needed to bootstrap the environment.

C.Warm standby, keeping a reduced but ready-to-scale environment in the secondary Region.

D.Multi-site active-active, serving production traffic from both Regions at all times.

AnswerC

Warm standby maintains enough infrastructure to reduce recovery time, while not fully running production capacity continuously.

Why this answer

Warm standby is the best fit because it maintains a scaled-down but fully functional copy of the production environment in the secondary Region, allowing the RTO of 6 hours and RPO of 1 hour to be met without running full production capacity continuously. During a disaster, the standby environment can be scaled up quickly to serve traffic, balancing cost and recovery speed.

Exam trap

The trap here is that candidates confuse pilot light with warm standby, assuming that minimal resources (pilot light) can meet the 6-hour RTO, but pilot light requires manual provisioning of compute and scaling, which often exceeds the RTO, while warm standby provides a pre-provisioned, ready-to-scale environment that meets the requirement.

How to eliminate wrong answers

Option A is wrong because backup and restore only would result in an RTO significantly longer than 6 hours, as it requires provisioning infrastructure and restoring data from backups, which cannot meet the 1-hour RPO or 6-hour RTO. Option B is wrong because pilot light keeps only the minimal core resources (e.g., database, DNS) and requires manual provisioning of compute and scaling, which typically exceeds the 6-hour RTO and may not achieve the 1-hour RPO without additional automation. Option D is wrong because multi-site active-active runs full production capacity in both Regions at all times, which violates the requirement to not run full production capacity continuously and incurs unnecessary cost.

Practice this question →

MCQmedium

A caching layer uses Amazon ElastiCache for Redis in front of a stateless web service. The service must continue to read cached responses during maintenance events and should automatically fail over to another node if one AZ becomes impaired. Which design change best satisfies this requirement?

A.Deploy a single-node Redis cluster and rely on application-level retries when cache misses occur.

B.Configure an ElastiCache Redis replication group with automatic failover across multiple Availability Zones.

C.Move the cache into the VPC but keep it in one Availability Zone to reduce network latency.

D.Use a Memcached cluster and configure only client-side connection pooling without failover support.

AnswerB

Multi-AZ replication groups provide redundant nodes and automatic failover, improving cache resilience during AZ events.

Why this answer

An ElastiCache Redis replication group with automatic failover across multiple Availability Zones ensures that if the primary node or its AZ becomes impaired, a read-replica in another AZ is automatically promoted to primary. This allows the stateless web service to continue reading cached responses without interruption, satisfying both the maintenance and AZ impairment requirements.

Exam trap

The trap here is that candidates often confuse Memcached's simplicity with Redis's replication capabilities, assuming that client-side connection pooling alone can handle failover, when in fact Memcached lacks any built-in replication or automatic failover mechanism.

Why the other options are wrong

A single-node Redis cluster lacks automatic failover; if the node or its AZ becomes impaired, the service cannot read cached responses until the node is restored, violating the requirement for continued reads during maintenance and AZ impairment.

Keeping the cache in one Availability Zone does not provide automatic failover to another node if that AZ becomes impaired, failing the requirement for high availability during maintenance events.

Memcached does not support automatic failover or multi-AZ replication; if an AZ becomes impaired, the cache becomes unavailable, violating the requirement for continued reads during maintenance.

Practice this question →

Multi-Selectmedium

An order-processing worker consumes messages from Amazon SQS. Occasionally, the worker times out after successfully creating a payment record but before deleting the message, which causes duplicate charges during retries. Some messages also fail validation repeatedly because required fields are missing. Which two changes should the team make? Select two.

Select 2 answers

A.Make the payment step idempotent using a unique transaction identifier.

B.Configure an SQS dead-letter queue with a redrive policy.

C.Reduce the visibility timeout so failed messages return to the queue faster.

D.Run only one long-lived worker instance so the queue can never be processed twice.

E.Switch from a standard queue to a FIFO queue and remove all other changes.

AnswersA, B

Correct. SQS provides at-least-once delivery, so the same message can be processed more than once if the worker times out, retries, or crashes after partially completing the work. An idempotency key lets the application recognize that the payment was already created and prevents duplicate charges.

Why this answer

Making the payment step idempotent using a unique transaction identifier ensures that if the same message is processed multiple times due to a timeout, the payment is only charged once. This is a common pattern for handling at-least-once delivery semantics in Amazon SQS, where the worker must be designed to handle duplicate messages safely.

Exam trap

The trap here is that candidates often think reducing the visibility timeout will speed up recovery, but it actually increases the chance of duplicate processing, and they may also overlook that a FIFO queue alone does not fix the worker's failure to delete the message after processing.

Practice this question →

MCQmedium

A company runs a stateful analytics workload on EC2 instances that use EBS volumes. The data must be restorable in another Region after a major outage, with frequent point-in-time recovery. Which approach provides the most suitable replication mechanism for the EBS-backed data?

A.Create scheduled EBS snapshots and copy them to another Region, then restore the volumes from those snapshots during recovery.

B.Enable EBS multi-attach to spread the workload across AZs and replicate snapshots automatically between Regions.

C.Use RDS read replicas in another Region and keep the analytics dataset in an RDS instance only.

D.Rely on instance store for durability and copy only AMIs across Regions.

AnswerA

Snapshotting and cross-Region copying gives point-in-time images of EBS volumes that can be restored in the target Region.

Why this answer

Scheduled EBS snapshots provide point-in-time backups of EBS volumes, which can be copied to another Region using the cross-Region snapshot copy feature. During recovery, you restore volumes from those snapshots in the target Region, ensuring the data is restorable after a major outage. This approach meets the requirements for frequent point-in-time recovery and cross-Region durability.

Exam trap

The trap here is that candidates may confuse EBS multi-attach (which is for high availability within a single AZ) with cross-Region replication, or mistakenly think instance store provides durability for long-term data recovery.

Why the other options are wrong

EBS multi-attach allows attaching a volume to multiple EC2 instances in the same AZ, but it does not replicate snapshots across Regions or provide cross-Region disaster recovery. It is designed for clustered applications within a single AZ, not for multi-Region replication.

RDS read replicas are for relational databases, not for analytics workloads on EC2 with EBS volumes. The question specifies EBS-backed data, not RDS-managed data, so using RDS would require migrating the dataset and does not replicate EBS snapshots.

Instance store volumes are ephemeral and lose data on instance stop/termination, making them unsuitable for durable, restorable data. Copying AMIs does not replicate the analytics data itself.

Practice this question →

MCQeasy

A web application runs on an Amazon EC2 Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ALB is configured to use at least two Availability Zones (AZs), but the ASG currently uses subnets in only one AZ. If that AZ becomes unavailable, the application stops serving requests. Which change most directly improves resilience to an AZ outage?

A.Keep the ASG in one Availability Zone, but reduce ALB health check intervals.

B.Place the ASG across multiple Availability Zones by configuring it with subnets in at least two AZs.

C.Switch the load balancer from an ALB to an NLB to remove HTTP health check dependency.

D.Add an Amazon SQS queue to buffer requests during failures.

AnswerB

An ASG launches instances into the AZs of the subnets you specify. By placing the ASG in at least two AZs, the ALB can route traffic to healthy targets in the remaining AZ(s) if one AZ fails, enabling recovery as new instances maintain desired capacity.

Why this answer

Distributing an Auto Scaling group across multiple Availability Zones (AZs) ensures that if one AZ fails, the remaining AZs continue to serve traffic. The Application Load Balancer (ALB) is already configured for at least two AZs, but the ASG’s single-AZ subnet placement creates a single point of failure. By adding subnets in at least two AZs to the ASG, the application becomes resilient to an AZ outage without any other architectural changes.

Exam trap

The trap here is that candidates assume the ALB’s multi-AZ configuration automatically protects the application, overlooking that the ASG must also span multiple AZs to provide compute redundancy.

How to eliminate wrong answers

Option A is wrong because reducing health check intervals only detects failures faster but does not eliminate the single point of failure; if the sole AZ becomes unavailable, no healthy instances exist to serve traffic. Option C is wrong because switching from an ALB to an NLB does not address the root cause—the ASG is still in one AZ—and HTTP health checks are not the issue; the ALB can already perform health checks across AZs. Option D is wrong because adding an SQS queue buffers requests but does not provide compute capacity in another AZ; without instances in a second AZ, the queue cannot process requests during an AZ outage.

Practice this question →

MCQmedium

A trading dashboard stores uploaded documents in S3. The business requires a copy in another AWS Region for disaster recovery. What should be configured? The design must avoid adding custom operational scripts.

A.An EBS snapshot schedule

B.S3 Cross-Region Replication with versioning enabled

C.S3 lifecycle transition to Glacier Flexible Retrieval

D.A CloudFront distribution

AnswerB

CRR asynchronously replicates objects to a bucket in another Region and requires versioning.

Why this answer

S3 Cross-Region Replication (CRR) automatically replicates objects to a destination bucket in a different AWS Region, meeting the disaster recovery requirement without custom scripts. Versioning must be enabled on both source and destination buckets for CRR to function, as it tracks object versions and ensures consistency during replication.

Exam trap

The trap here is that candidates may confuse S3 Cross-Region Replication with S3 lifecycle policies or CloudFront, thinking they provide cross-region replication, but only CRR with versioning enabled meets the DR requirement without custom scripts.

How to eliminate wrong answers

Option A is wrong because EBS snapshots are for Amazon Elastic Block Store volumes attached to EC2 instances, not for S3 objects; they cannot replicate S3 data across regions. Option C is wrong because S3 lifecycle transitions to Glacier Flexible Retrieval only change storage class within the same region for cost optimization, not replicate data to another region. Option D is wrong because CloudFront is a content delivery network (CDN) that caches content at edge locations for low-latency access, not a replication mechanism for disaster recovery across regions.

Practice this question →

MCQmedium

A web application runs on an Amazon EC2 Auto Scaling group behind an Application Load Balancer (ALB). After each deployment, new instances take about 2 minutes to download artifacts and become ready to accept requests on the target port. In the last deployment, the ALB started marking targets unhealthy before the app was ready, and the Auto Scaling group then replaced those instances repeatedly, causing a prolonged outage. Which change best improves resilience during instance start-up without reducing actual availability once the application is healthy?

A.Increase the Auto Scaling group’s health check grace period so it exceeds the ~2-minute initialization time.

B.Add more subnets across additional Availability Zones to distribute the same instances more widely.

C.Switch the load balancer target type from instance targets to IP targets to avoid health check failures.

D.Reduce the ALB health check interval so unhealthy targets are removed faster.

AnswerA

A health check grace period prevents the Auto Scaling group from treating early health check failures as instance health problems. This avoids terminating instances before the application finishes initializing, which stops the restart/replace loop during deployments while still allowing normal health checks to apply once the app is ready.

Why this answer

The Auto Scaling group's health check grace period allows instances to initialize without being marked unhealthy by the ELB health checks. By setting this grace period to exceed the ~2-minute artifact download time, the ASG will not replace instances that are still starting up, preventing the cascade of terminations and redeployments that caused the outage. This directly addresses the root cause—premature health check failures—without changing the health check configuration or reducing availability once the app is ready.

Exam trap

The trap here is that candidates confuse the ALB health check interval or target type with the Auto Scaling group's lifecycle management, mistakenly thinking that changing how the ALB checks health (interval or target type) will fix the premature replacement, when the correct solution is to adjust the ASG's grace period to align with the application's startup time.

How to eliminate wrong answers

Option B is wrong because adding more subnets across additional Availability Zones distributes instances more widely for fault tolerance but does not prevent the ALB from marking starting instances as unhealthy, so it does not solve the premature replacement issue. Option C is wrong because switching from instance targets to IP targets changes how the ALB routes traffic but does not alter the health check logic or timing; the ALB will still mark the target as unhealthy if the health check fails during the initialization window. Option D is wrong because reducing the ALB health check interval causes unhealthy targets to be detected and removed faster, which would worsen the problem by accelerating the replacement cycle, not improving resilience during start-up.

Practice this question →

MCQmedium

An order processing workflow uses Amazon SQS as the decoupling layer between a producer and a consumer Lambda function. The consumer intermittently fails due to a downstream dependency. The team has observed that certain “poison” messages keep being retried repeatedly and prevent other messages from being processed efficiently. Which SQS configuration most directly addresses this issue?

A.Set the SQS queue’s retention period to 10 years and rely on application retries to eventually succeed.

B.Increase visibility timeout to a very large value and avoid dead-letter queues to keep ordering stable.

C.Configure a redrive policy with a dead-letter queue (DLQ) and set an appropriate visibility timeout greater than the maximum processing time.

D.Switch the queue to FIFO and remove retries in the Lambda event source mapping entirely.

AnswerC

A DLQ isolates poison messages after a receive count threshold, and correct visibility timeout prevents premature retries.

Why this answer

Configuring a redrive policy with a dead-letter queue (DLQ) allows messages that exceed a specified maximum receive count to be moved to the DLQ, isolating poison messages. Setting the visibility timeout greater than the maximum processing time ensures the consumer has enough time to process each message before it becomes visible again, preventing premature retries. This directly addresses the issue of poison messages blocking the queue and degrading throughput.

Exam trap

The trap here is that candidates often confuse increasing the visibility timeout or switching to FIFO as solutions for poison messages, but neither addresses the root cause of isolating messages that repeatedly fail processing.

How to eliminate wrong answers

Option A is wrong because increasing the retention period to 10 years does not prevent poison messages from being retried; it only keeps them in the queue longer, worsening the problem. Option B is wrong because increasing visibility timeout to a very large value without a DLQ means poison messages will still be retried indefinitely, and avoiding DLQs does not help with ordering or poison message handling. Option D is wrong because switching to a FIFO queue does not address poison messages; FIFO ensures strict ordering but still requires a DLQ for poison message handling, and removing retries entirely would cause message loss if processing fails.

Practice this question →

MCQhard

A warehouse integration service must use shared file storage across Linux EC2 instances in multiple Availability Zones. The storage must remain available during an AZ failure. Which service should be used? The design must avoid adding custom operational scripts.

A.Amazon EFS with mount targets in multiple Availability Zones

B.S3 mounted as a POSIX file system without a file gateway

C.Instance store volumes

D.An EBS volume attached to all instances

AnswerA

EFS is regional file storage and supports mount targets across AZs.

Why this answer

Amazon EFS provides a fully managed, POSIX-compliant NFSv4.1 shared file system that can be mounted concurrently across multiple Linux EC2 instances. By deploying mount targets in multiple Availability Zones, the file system remains accessible even if one AZ fails, satisfying the high-availability requirement without any custom scripts.

Exam trap

The trap here is that candidates may confuse EBS Multi-Attach (which has strict limitations and requires cluster-aware file systems) with a true shared file system, or assume that S3 with a FUSE mount is a viable POSIX alternative without considering the operational overhead and lack of native consistency.

How to eliminate wrong answers

Option B is wrong because mounting S3 as a POSIX file system (e.g., via s3fs-fuse) requires custom operational scripts and does not provide native POSIX semantics or strong consistency, making it unsuitable for shared file storage across AZs. Option C is wrong because instance store volumes are ephemeral, tied to a single EC2 instance, and cannot be shared across instances or survive AZ failures. Option D is wrong because a single EBS volume cannot be attached to multiple EC2 instances; it can only be attached to one instance at a time, and while Multi-Attach EBS exists, it is limited to specific instance types and does not provide a shared file system without additional cluster-aware software.

Practice this question →

MCQeasy

A company runs the same public API in two regions (Region A and Region B), each fronted by an ALB. They want Route 53 to automatically route clients to the Region B API when Region A becomes unhealthy, with minimal configuration effort. Which Route 53 approach should they use?

A.Use a single Route 53 A record that points only to Region A’s ALB and manually update it after failures.

B.Use Route 53 latency-based routing with separate records for each region.

C.Use Route 53 failover routing with health checks for each region’s endpoint.

D.Use weighted routing and set the Region B weight to 0 to ensure it is only used when needed.

AnswerC

Failover routing works with health checks to move traffic from a primary endpoint to a secondary endpoint when the primary becomes unhealthy.

Why this answer

Route 53 failover routing with health checks is the correct choice because it automatically directs traffic to a secondary endpoint (Region B) when the primary endpoint (Region A) fails a health check. This provides active-passive failover with minimal configuration, as Route 53 monitors the health of each ALB and updates DNS responses accordingly without manual intervention.

Exam trap

The trap here is that candidates often confuse latency-based routing with failover capabilities, assuming latency routing will automatically avoid unhealthy endpoints, but it only optimizes for speed and requires health checks to be manually integrated via a separate routing policy.

How to eliminate wrong answers

Option A is wrong because manually updating a single A record after failure is not automated, contradicts the requirement for minimal configuration effort, and introduces significant downtime during the manual update window. Option B is wrong because latency-based routing routes clients based on lowest latency, not health; it does not automatically fail over to Region B when Region A is unhealthy—clients would still be directed to Region A if it has lower latency, even if it is down. Option D is wrong because setting Region B's weight to 0 would never route traffic to it, even if Region A fails; weighted routing does not support automatic failover based on health checks.

Practice this question →

MCQmedium

A fintech startup uses AWS to run a web API and a PostgreSQL database. They must meet an RPO of 15 minutes and an RTO of 2 hours for a Region-wide disaster. Budget allows running a small, always-on set of infrastructure in a secondary Region, but not full production capacity. The team wants a DR approach that is regularly testable without large manual effort. Which disaster recovery strategy is the best fit?

A.Pilot light: replicate databases and store backups, keep only minimal infrastructure in the secondary Region, and scale up fully during failover.

B.Warm standby: keep a scaled-down application environment and database replication active in the secondary Region, using automated failover controls.

C.Backup and restore only: rely on daily automated backups and restore into the secondary Region during an incident.

D.Multi-site active-active: run both Regions at full capacity and route live traffic to both simultaneously.

AnswerB

Warm standby aligns with moderate RTO requirements by having ready-to-run resources plus continuous replication to meet the RPO target during failover.

Why this answer

Warm standby (B) is the best fit because it maintains a scaled-down but fully functional application environment in the secondary Region with active database replication, meeting the RPO of 15 minutes (via synchronous or near-synchronous replication like PostgreSQL streaming replication) and RTO of 2 hours (via automated failover controls such as Route 53 health checks and AWS Lambda automation). This approach allows regular testing without large manual effort by simply promoting the standby environment, and the budget constraint is satisfied by running only minimal compute resources (e.g., smaller EC2 instances) in the secondary Region.

Exam trap

The trap here is that candidates often confuse pilot light with warm standby, assuming minimal infrastructure is sufficient for a 2-hour RTO, but pilot light requires provisioning and configuring application servers during failover, which typically takes longer than 2 hours, whereas warm standby already has the application running and only needs scaling.

Why the other options are wrong

Pilot light keeps minimal infrastructure in the secondary Region, which does not meet the RTO of 2 hours because scaling up from minimal to full capacity takes longer than 2 hours. The question requires a scaled-down but always-on environment to achieve the RTO.

The RPO of 15 minutes cannot be met with daily backups, as data loss could be up to 24 hours. Additionally, restoring from backups would likely exceed the 2-hour RTO due to manual restore and provisioning time.

Multi-site active-active requires both Regions to run at full production capacity simultaneously, which exceeds the budget constraint of running only a small, always-on infrastructure in the secondary Region.

Practice this question →

MCQhard

A payments API uses Amazon SQS. Poison messages are repeatedly failing and blocking useful retries. What should the architect configure? The architecture review board prefers a managed AWS-native control.

A.A FIFO queue without a redrive policy

B.A dead-letter queue with an appropriate maxReceiveCount

C.A larger message retention period only

D.Short polling instead of long polling

AnswerB

A DLQ isolates messages that fail repeatedly so they can be investigated without disrupting normal processing.

Why this answer

A dead-letter queue (DLQ) with an appropriate maxReceiveCount is the correct AWS-native solution for handling poison messages. When a message is repeatedly received from an SQS queue but fails processing, it is considered a poison message. By configuring a DLQ and setting a maxReceiveCount (e.g., 3 or 5), the message is automatically moved to the DLQ after exceeding that threshold, preventing it from blocking further retries and allowing the main queue to process valid messages.

Exam trap

The trap here is that candidates may confuse poison message handling with ordering or polling optimizations, and incorrectly choose FIFO queues or short polling, not realizing that only a DLQ with a redrive policy isolates repeatedly failing messages.

How to eliminate wrong answers

Option A is wrong because a FIFO queue without a redrive policy does not automatically handle poison messages; it only ensures strict ordering and exactly-once processing, but failed messages remain in the queue and continue to block retries. Option C is wrong because increasing the message retention period only keeps messages longer in the queue, but does nothing to isolate or remove poison messages that are repeatedly failing. Option D is wrong because short polling (returning immediately even if no messages are available) versus long polling (waiting for messages) affects latency and cost, but does not address the poison message problem; poison messages are a content/processing issue, not a polling mechanism issue.

Practice this question →

MCQmedium

A patient portal receives bursts of orders that sometimes overwhelm a downstream fulfilment service. The architecture must absorb spikes and retry processing without losing requests. Which service should be placed between the web tier and fulfilment workers? The design must avoid adding custom operational scripts.

A.AWS WAF

B.Amazon CloudFront

C.Amazon SQS queue

D.Amazon Route 53 weighted routing

AnswerC

SQS decouples producers and consumers, buffers bursts, and supports retries through visibility timeout and dead-letter queues.

Why this answer

Amazon SQS is the correct choice because it acts as a durable, fully managed message buffer that decouples the web tier from the fulfilment workers. When bursts of orders arrive, SQS queues the messages and allows workers to poll at their own pace, absorbing spikes without data loss. The built-in retry logic (visibility timeout and dead-letter queue) ensures failed processing attempts are automatically retried, and no custom operational scripts are needed.

Exam trap

The trap here is that candidates often confuse decoupling with caching or DNS-level distribution, picking CloudFront or Route 53 because they think 'absorbing spikes' means scaling web servers, but the question specifically requires buffering and retry without custom scripts, which only a queue service like SQS provides.

How to eliminate wrong answers

Option A is wrong because AWS WAF is a web application firewall that filters HTTP/S traffic based on rules (e.g., SQL injection, XSS); it does not buffer or retry messages between tiers. Option B is wrong because Amazon CloudFront is a content delivery network (CDN) that caches and accelerates static/dynamic content at edge locations; it cannot queue or retry asynchronous order processing. Option D is wrong because Amazon Route 53 weighted routing distributes DNS traffic across multiple endpoints based on weights; it provides load balancing at the DNS level but does not absorb spikes or provide retry mechanisms for message processing.

Practice this question →

Multi-Selecthard

A regional web application for a content publishing system must fail over automatically to a secondary Region if the primary endpoint becomes unhealthy. Which two services or features are required? The design must avoid adding custom operational scripts.

Select 2 answers

A.AWS Organizations service control policies

B.Route 53 failover routing with health checks

C.S3 Transfer Acceleration

D.A deployed standby application stack in the secondary Region

AnswersB, D

Route 53 can monitor endpoint health and return the standby endpoint when the primary is unhealthy.

Why this answer

Route 53 failover routing with health checks is required because it automatically directs traffic away from an unhealthy primary endpoint to a secondary endpoint, enabling cross-region failover without custom scripts. A deployed standby application stack in the secondary Region is necessary to serve traffic when the primary fails, as Route 53 can only route to healthy endpoints that are actually running.

Exam trap

The trap here is that candidates often assume Route 53 alone is sufficient, forgetting that the secondary Region must have a fully deployed and running application stack to receive traffic after failover.

Practice this question →

MCQmedium

A media company stores original uploads in an S3 bucket. They must recover from accidental overwrites/deletes and also recover quickly from a full Region outage. The required RPO is about 1 hour. Which configuration best meets these requirements?

A.Enable an S3 lifecycle policy to transition objects to Glacier after 7 days without enabling versioning.

B.Enable S3 cross-Region replication (CRR) but leave the bucket without versioning enabled.

C.Enable S3 versioning and configure cross-Region replication to a bucket in another Region.

D.Rely on frequent EBS snapshots of a temporary cache used during uploads.

AnswerC

Versioning enables recovery from accidental overwrites/deletes, and CRR provides near-current copies for Region-level disaster recovery.

Why this answer

Enabling S3 versioning protects against accidental overwrites and deletes by preserving all object versions, while cross-Region replication (CRR) asynchronously replicates objects to a bucket in another Region, enabling recovery from a full Region outage. With an RPO of about 1 hour, CRR meets this requirement as replication typically completes within minutes to a few hours, and versioning ensures point-in-time recovery of previous object states.

Exam trap

The trap here is that candidates often assume CRR alone is sufficient for data protection, overlooking that without versioning, overwrites and deletes are permanent and cannot be recovered, which directly violates the requirement to recover from accidental overwrites/deletes.

How to eliminate wrong answers

Option A is wrong because a lifecycle policy to transition objects to Glacier after 7 days does not protect against accidental overwrites or deletes (no versioning), and Glacier retrieval times (minutes to hours) are too slow for a 1-hour RPO in a Region outage scenario. Option B is wrong because CRR without versioning cannot recover from accidental overwrites or deletes, as overwrites permanently replace the object and deletes remove it entirely, leaving no previous versions to restore. Option D is wrong because EBS snapshots of a temporary cache are not designed for S3 object recovery; they capture block-level changes of an EC2 instance volume, not the S3 bucket's object state, and do not provide cross-Region durability or protection against S3-specific overwrites/deletes.

Practice this question →

MCQmedium

Based on the exhibit, the application should continue serving requests if one Availability Zone fails. Which change best improves resilience with the least operational complexity?

A.Increase the desired capacity in AZ-a so more instances can absorb the failure of that same Availability Zone.

B.Add at least one subnet from a second Availability Zone to both the ALB and the Auto Scaling group.

C.Disable health checks so the ALB stops removing targets during brief infrastructure issues.

D.Move the application to a single larger instance type so the fleet has fewer moving parts.

AnswerB

A resilient design needs the load balancer and the Auto Scaling group to span multiple Availability Zones. If one AZ fails, the ALB can still route to healthy targets in the remaining AZs and the Auto Scaling group can replenish capacity there. This is the simplest and most common way to achieve AZ-level fault tolerance.

Why this answer

Adding subnets from a second Availability Zone to both the ALB and the Auto Scaling group distributes the application across multiple AZs. This ensures that if one AZ fails, the ALB can route traffic to healthy targets in the remaining AZ, and the Auto Scaling group can maintain capacity by launching instances in the surviving AZ. This approach directly addresses the requirement to continue serving requests during an AZ failure with minimal operational complexity.

Exam trap

The trap here is that candidates often think increasing capacity in a single AZ (Option A) provides resilience, but it actually concentrates risk in that AZ, while the correct answer requires distributing resources across multiple AZs to achieve true fault tolerance.

How to eliminate wrong answers

Option A is wrong because increasing the desired capacity in a single AZ does not provide resilience against the failure of that same AZ; all instances would be lost if the AZ fails. Option C is wrong because disabling health checks would prevent the ALB from detecting and removing unhealthy targets, causing traffic to be routed to failed instances and degrading application availability. Option D is wrong because moving to a single larger instance type creates a single point of failure; if that instance fails, the entire application becomes unavailable, and it does not address AZ-level failures.

Practice this question →

Matchingmedium

A team wants a web application to keep serving traffic if one Availability Zone fails. Match each architecture element to the resilience behavior it provides.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Stop sending requests to unhealthy targets and keep only healthy instances in rotation.

Launch replacement instances in healthy AZs when capacity is lost.

Maintain a synchronous standby in another AZ and fail over automatically.

Allow instances to be replaced without losing user sessions that are stored elsewhere.

Why these pairings

These pairs match architecture elements with their resilience behaviors for surviving an Availability Zone failure, focusing on AWS services that provide high availability and fault tolerance.

Practice this question →

Multi-Selectmedium

A company is designing a disaster recovery plan for a critical application hosted on AWS. The application runs on EC2 instances with data stored in Amazon EBS volumes and Amazon S3. The recovery time objective (RTO) is 15 minutes, and the recovery point objective (RPO) is 1 hour. Which three strategies would help meet these objectives? (Choose three.)

Select 3 answers

.Use AWS Backup to create hourly snapshots of EBS volumes and copy them to a different AWS Region.

.Pre-provision EC2 instances in the disaster recovery region and keep them running 24/7.

.Replicate critical data to S3 in the disaster recovery region using S3 Cross-Region Replication (CRR).

.Store Amazon Machine Images (AMIs) in the source region and use AWS Lambda to copy them after a disaster.

.Configure Amazon Route 53 with a failover routing policy and health checks to redirect traffic to the DR region.

.Set up an AWS Direct Connect link between the primary and DR regions for faster data transfer.

Why this answer

AWS Backup can create hourly snapshots of EBS volumes and copy them to a different AWS Region, meeting the 1-hour RPO by ensuring backups are taken every hour. S3 Cross-Region Replication (CRR) asynchronously replicates objects to a bucket in another region, keeping data synchronized within minutes and supporting the RPO. Amazon Route 53 with a failover routing policy and health checks can automatically redirect traffic to the DR region within seconds to minutes, enabling the 15-minute RTO by quickly failing over to pre-prepared infrastructure.

Exam trap

The trap here is that candidates may confuse operational readiness (like pre-provisioning instances) with a specific strategy that directly contributes to meeting RTO/RPO, or they may think Direct Connect is a disaster recovery strategy when it is merely a connectivity option that does not automate failover or data replication.

Practice this question →

MCQmedium

A Multi-AZ Amazon RDS database experiences incorrect writes at 10:15 UTC due to a buggy release. The team detects the problem at 10:25 UTC. They want to restore the data to a known-good point around 10:15 UTC, and validate the recovered data, without taking the current production instance offline during the recovery process. What is the most appropriate AWS action?

A.Immediately reboot the RDS instance and rely on the reboot to roll back the bad writes.

B.Perform a point-in-time restore (PITR) to a new DB instance using a restore time around 10:15 UTC, then test the restored instance before cutting over.

C.Create a new Read Replica from the current primary and use it as the recovered database after applying reverse migrations.

D.Temporarily disable Multi-AZ to speed up storage rollback, then re-enable Multi-AZ.

AnswerB

PITR restores to a specific timestamp using backups and transaction logs. Importantly, it creates a recovered copy (typically a new DB instance), which allows validation and cutover decisions without stopping or directly impacting the existing production instance.

Why this answer

Amazon RDS point-in-time recovery (PITR) allows you to restore a DB instance to any second within the backup retention period, creating a new, independent DB instance. This lets you validate the recovered data without affecting the current production instance, which remains online and serving traffic. The team can then cut over to the restored instance after confirming it is clean.

Exam trap

The trap here is that candidates may assume a reboot or Read Replica can undo bad writes, but neither provides a rollback mechanism; only PITR or a manual restore from a snapshot can recover to a specific point in time without affecting the live instance.

How to eliminate wrong answers

Option A is wrong because rebooting an RDS instance does not roll back writes; it only restarts the database engine and applies any pending maintenance or parameter changes, leaving the bad data intact. Option C is wrong because a Read Replica is an asynchronous copy of the primary that replicates all writes, including the buggy ones, so it cannot serve as a point-in-time recovery target without manual, error-prone reverse migrations. Option D is wrong because disabling Multi-AZ does not provide a storage rollback mechanism; it only removes the standby replica, and the primary's storage still contains the incorrect writes.

Practice this question →

MCQmedium

Based on the exhibit, which Route 53 configuration should be used so traffic automatically returns to the secondary Region only when the primary Region becomes unhealthy?

A.Use latency-based routing with both ALB records enabled.

B.Use failover routing with a primary alias record, a secondary alias record, and a Route 53 health check on the primary target.

C.Use geolocation routing so users are always sent to the closest Region.

D.Use a CNAME record that points to both ALBs so DNS can round-robin between Regions.

AnswerB

Failover routing is designed for this pattern: Route 53 returns the primary alias while the primary endpoint is healthy, and switches to the secondary alias when the primary health check fails. Alias records integrate cleanly with ALB targets, and the health check provides the signal that drives the failover decision.

Why this answer

Failover routing in Amazon Route 53 is designed for active-passive configurations. By creating a primary alias record pointing to the ALB in the primary Region and a secondary alias record pointing to the ALB in the secondary Region, and attaching a Route 53 health check to the primary target, traffic automatically fails over to the secondary Region only when the health check detects the primary as unhealthy. This meets the requirement of returning traffic to the secondary Region only upon primary failure.

Exam trap

The trap here is that candidates often confuse failover routing with latency-based or geolocation routing, assuming that 'closest' or 'fastest' automatically implies health awareness, but Route 53 health checks must be explicitly associated with failover records to trigger automatic traffic redirection.

How to eliminate wrong answers

Option A is wrong because latency-based routing directs users based on lowest latency, not health status, so it would not automatically fail over only when the primary is unhealthy; traffic could still be sent to an unhealthy primary if latency is low. Option C is wrong because geolocation routing sends users based on their geographic location, not the health of the endpoint, so it cannot automatically redirect traffic to the secondary Region when the primary becomes unhealthy. Option D is wrong because a CNAME record cannot point to multiple ALBs for round-robin; CNAME records can only point to a single DNS name, and DNS round-robin does not consider health checks, so traffic would still be sent to an unhealthy primary.

Practice this question →

Multi-Selectmedium

A company is designing a multi-Region disaster recovery (DR) strategy for a stateless web application running on Amazon EC2 instances behind an Application Load Balancer (ALB). The application uses an Amazon RDS for MySQL database as its data store. The architecture must provide rapid failover with the lowest possible Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Which of the following design choices will help achieve these objectives? (Choose four.)

Select 4 answers

.Configure an active-passive failover strategy by deploying the application stack in two AWS Regions and using Amazon Route 53 health checks with a failover routing policy.

.Set up Amazon RDS Multi-AZ deployment to enable automatic failover to a standby replica in a different Availability Zone within the primary Region.

.Use Amazon RDS cross-Region read replicas with automatic failover to promote a read replica to a primary instance in the secondary Region.

.Deploy the application and ALB in an active-active configuration across two AWS Regions using Amazon Route 53 latency-based routing.

.Store static assets and application state in Amazon S3 with cross-Region replication enabled, and serve them via Amazon CloudFront.

.Use an Amazon RDS for MySQL single-AZ deployment in the primary Region and take daily snapshots copied to the secondary Region.

Why this answer

An active-passive failover strategy with Route 53 failover routing policy is correct because it provides rapid failover by directing traffic to the secondary Region only when health checks fail in the primary, minimizing RTO. Cross-Region read replicas with automatic failover are correct because they allow promoting a read replica to a primary in the secondary Region with low RPO (typically seconds) and automated failover, reducing RTO. Active-active configuration with latency-based routing is correct because it distributes traffic across both Regions, enabling immediate failover without DNS propagation delays, achieving very low RTO.

Storing static assets and application state in S3 with cross-Region replication and CloudFront is correct because it ensures data durability and low-latency access, supporting rapid recovery with minimal RPO.

Exam trap

The trap here is that candidates often confuse Multi-AZ (single-Region high availability) with cross-Region DR, or they assume daily snapshots provide adequate RPO for a DR strategy requiring the lowest possible RPO and RTO.

Practice this question →

MCQmedium

A inventory service uses Lambda functions that call an unreliable third-party API. Failed events must be retained for later investigation after retries are exhausted. What should be configured? The design must avoid adding custom operational scripts.

A.Lambda reserved concurrency set to zero

B.A Lambda dead-letter queue or failure destination

C.A larger deployment package

D.CloudFront error pages

AnswerB

A DLQ or asynchronous failure destination captures failed events after retry attempts.

Why this answer

A Lambda dead-letter queue (DLQ) or failure destination allows you to capture events that have exhausted all retry attempts from an asynchronous invocation. When the Lambda function fails after the maximum retries (default 3), the event is sent to the configured SQS queue or SNS topic for later investigation, without requiring custom scripts or manual polling.

Exam trap

The trap here is that candidates may confuse Lambda's DLQ/failure destination with other error-handling mechanisms like SQS redrive policies or CloudFront custom error pages, which serve different purposes and operate at different layers of the architecture.

How to eliminate wrong answers

Option A is wrong because setting reserved concurrency to zero would completely disable the Lambda function, preventing any invocations and thus failing to process or retain any events. Option C is wrong because a larger deployment package does not affect error handling or event retention; it only increases cold start latency and deployment size. Option D is wrong because CloudFront error pages are for HTTP-level errors from a web distribution, not for capturing asynchronous Lambda invocation failures or dead-letter events.

Practice this question →

MCQeasy

An order system receives events and uses a Lambda function to write each order into a database. During traffic spikes, the database sometimes throttles, and Lambda retries lead to occasional message loss in the event flow. The team wants buffering, automatic retries, and a way to isolate messages that repeatedly fail so they can be inspected later. What design change best meets this need?

A.Send events directly from EventBridge to Lambda without any queue to simplify the flow.

B.Use Amazon SQS as a buffer between the event source and Lambda, with an SQS dead-letter queue (DLQ).

C.Use SNS fan-out to multiple Lambda functions, but keep no retry logic and no DLQ.

D.Store events in an S3 bucket and trigger Lambda immediately after each upload, without using DLQs.

AnswerB

SQS buffers bursts, supports retries via visibility timeouts, and DLQs capture messages that fail repeatedly for later review.

Why this answer

B is correct because Amazon SQS acts as a durable buffer between the event source and Lambda, absorbing traffic spikes and providing automatic retries via its visibility timeout mechanism. By attaching a dead-letter queue (DLQ) to the SQS queue, messages that repeatedly fail processing can be isolated for later inspection, preventing data loss and enabling debugging.

Exam trap

The trap here is that candidates may think EventBridge or S3 triggers provide sufficient retry and isolation, but they lack the built-in DLQ and configurable retry mechanics that SQS offers for decoupling and resilience.

How to eliminate wrong answers

Option A is wrong because sending events directly from EventBridge to Lambda without a queue provides no buffering or retry isolation; Lambda’s synchronous invocation retries are limited and can still lead to message loss under throttling. Option C is wrong because SNS fan-out to multiple Lambda functions without retry logic and no DLQ means failed messages are dropped immediately, with no mechanism for buffering or isolating problematic messages. Option D is wrong because storing events in S3 and triggering Lambda immediately after upload does not provide built-in retry logic for processing failures, and S3 does not offer a DLQ concept; failed events would be lost unless custom retry logic is implemented.

Practice this question →

MCQmedium

A company runs a customer portal on an Amazon Aurora PostgreSQL cluster. The application currently connects directly to the writer instance endpoint and keeps long-lived connections open. During a maintenance failover, writes fail until clients are restarted. The team wants the application to reconnect to the correct Aurora endpoint automatically and reduce user-visible write interruptions. Which change is most likely to achieve this?

A.Use the Aurora cluster endpoint for write traffic, use the reader endpoint for read-only traffic, and implement connection retry or reconnect logic on failover.

B.Keep using the original writer instance endpoint so the database host name never changes during failover.

C.Convert the Aurora cluster to Single-AZ so there is only one database node to connect to.

D.Place Route 53 in front of the database and manually update DNS records whenever failover occurs.

AnswerA

The cluster endpoint always targets the current writer, and failover-aware reconnect logic helps the application recover from dropped connections after promotion.

Why this answer

The Aurora cluster endpoint automatically points to the current writer instance, so using it for write traffic ensures that after a failover, new writes are directed to the new writer without needing to change the connection string. Implementing connection retry or reconnect logic in the application is essential because the existing long-lived connections will be broken during failover; the application must detect the failure and re-establish connections to the cluster endpoint to resume writes seamlessly.

Exam trap

The trap here is that candidates assume the writer instance endpoint remains constant during failover (Option B), but in Aurora, the writer instance endpoint changes because it is tied to the specific DB instance, not the cluster.

Why the other options are wrong

The writer instance endpoint points to a specific Aurora node, which changes during failover. Keeping it does not automatically redirect traffic to the new writer, so writes still fail until clients are restarted.

Converting to Single-AZ removes the standby replica, eliminating high availability. During a failover, there is no standby to promote, causing longer downtime and potential data loss, which contradicts the goal of reducing write interruptions.

Manually updating Route 53 DNS records during failover is not automated and would still cause write interruptions until the manual update is completed, failing to meet the requirement of automatic reconnection and reduced downtime.

Practice this question →

MCQmedium

Your ecommerce app runs behind an Application Load Balancer (ALB) and uses an RDS database for orders. During an AZ impairment in us-east-1, customers report that checkout takes several minutes to recover. The current design places EC2 instances only in private subnets of AZ-a, while the ALB spans multiple subnets. The RDS DB instance is Multi-AZ. Management wants automatic recovery within the same Region. Which change best addresses the issue with minimal operational overhead?

A.Move the EC2 instances into Auto Scaling Groups that span private subnets in at least two AZs, keeping the ALB spanning those subnets.

B.Switch from RDS Single-AZ to RDS Multi-AZ, keeping the EC2 instances in only AZ-a because failover will still reach them.

C.Terminate the ALB and use a Network Load Balancer (NLB) in front of the existing single-AZ EC2 instances.

D.Add more EC2 instances in AZ-a and increase the ALB health check thresholds to avoid unnecessary replacements during impairments.

AnswerA

An Auto Scaling Group across multiple AZs ensures healthy capacity exists when an AZ becomes impaired, and the ALB can route to instances in any available AZ.

Why this answer

The current design has a single point of failure: all EC2 instances are in one Availability Zone (AZ-a). During an AZ impairment, those instances become unreachable, causing the checkout process to fail until the impairment ends or manual intervention occurs. By placing EC2 instances in an Auto Scaling Group spanning at least two AZs, the application can automatically recover by launching new instances in a healthy AZ, while the ALB distributes traffic across the surviving AZs.

This minimizes operational overhead as Auto Scaling handles instance replacement automatically.

Exam trap

The trap here is that candidates may focus on the database layer (Multi-AZ) or load balancer type (NLB vs ALB) and overlook the critical single-AZ EC2 instance placement, which is the actual bottleneck causing the prolonged recovery during an AZ impairment.

How to eliminate wrong answers

Option B is wrong because the RDS DB instance is already Multi-AZ (as stated in the question), so switching from Single-AZ to Multi-AZ is not a change; moreover, keeping EC2 instances in only AZ-a still leaves them vulnerable to an AZ impairment, as the ALB cannot route traffic to a healthy AZ if no instances exist there. Option C is wrong because replacing the ALB with an NLB does not address the root cause—EC2 instances are still confined to a single AZ; additionally, an NLB operates at Layer 4 and lacks the HTTP/HTTPS health checks and content-based routing that an ALB provides, which could break the ecommerce application's functionality. Option D is wrong because adding more EC2 instances in AZ-a only increases capacity within the same failing AZ, and increasing health check thresholds delays the detection of unhealthy instances, prolonging recovery time rather than improving it.

Practice this question →

MCQmedium

Your media processing pipeline writes original uploads to an S3 bucket and later generates derivative files. An operator accidentally deletes a subset of original uploads in production. You need to (1) restore the deleted objects with minimal data loss and (2) protect against both regional disasters and future operator mistakes. The company requires recovery even if objects are deleted and later overwritten. What is the most effective change to meet these requirements?

A.Enable S3 versioning on the bucket and configure cross-Region replication so previous versions are available after regional loss and accidental deletion.

B.Move all objects to S3 Glacier Instant Retrieval and apply a lifecycle policy to keep only the latest object copy.

C.Use S3 server-side encryption with KMS keys and rely on access logs to manually recover the deleted objects.

D.Enable S3 bucket policies that deny DeleteObject, but do not enable versioning or replication.

AnswerA

Versioning retains prior object versions, and cross-Region replication provides redundancy across Regions for recovery after deletion or disaster.

Why this answer

Enabling S3 Versioning preserves all object versions, including deleted markers and overwritten objects, allowing recovery from accidental deletions. Cross-Region Replication (CRR) replicates both current and previous versions to a secondary region, providing protection against regional disasters. This combination ensures that even if objects are deleted and later overwritten, the original versions remain recoverable in both the source and destination buckets.

Exam trap

The trap here is that candidates often assume S3 bucket policies or encryption alone can protect against deletion, but only versioning preserves object history, and only replication provides regional disaster recovery.

How to eliminate wrong answers

Option B is wrong because moving objects to S3 Glacier Instant Retrieval does not provide versioning or replication, so deleted objects cannot be restored and there is no protection against regional disasters. Option C is wrong because S3 server-side encryption with KMS keys does not preserve deleted or overwritten objects; access logs only record events, not the data itself, making manual recovery impossible. Option D is wrong because a bucket policy denying DeleteObject can be bypassed by authorized users or misconfigurations, and without versioning or replication, deleted objects are permanently lost and there is no regional disaster recovery.

Practice this question →