High Availability & DR

Correct answer: .

In a Multi-AZ RDS DB instance deployment (the single-standby kind, as opposed to a Multi-AZ DB cluster deployment), synchronous replication keeps a standby instance's storage in lockstep with the primary at all times, so a failover carries essentially no data loss — ruling out the idea that replication is asynchronous or lossy. That standby exists purely for failover, not for serving application reads, so it cannot have already been fielding read traffic before the switch. Because the deployment exposes a single, stable DB instance endpoint, RDS handles a failover by updating the underlying DNS record for that same endpoint to point at the newly promoted instance; the application keeps its existing connection string and simply reconnects, rather than needing a new endpoint address hardcoded anywhere.

Source: AWS RDS User Guide: Configuring and managing a Multi-AZ deployment (Multi-AZ DB instance deployments)

Correct answer: .

A traditional Multi-AZ DB instance deployment has exactly one standby that exists solely for failover and never serves read traffic, so an option describing a second, still read-incapable standby only adds redundancy without changing that fundamental limitation, which isn't what a DB cluster deployment does. A Multi-AZ DB cluster deployment is a distinct architecture that spans three Availability Zones with a writer instance and two reader-capable standby instances; because those standbys can be queried directly, they add usable read capacity on top of failover protection, and their replication is synchronous, not asynchronous — so describing the cluster as merely swapping to async replication is backwards. Cross-Region read replicas are a separate feature entirely and aren't what enables faster, quorum-based failover within a Multi-AZ DB cluster.

Source: AWS RDS User Guide: Configuring and managing a Multi-AZ deployment (Multi-AZ DB cluster deployments)

Correct answer: .

Aurora Global Database is built for exactly this pattern: one primary cluster can replicate to up to ten read-only secondary clusters in other Regions, using the underlying storage layer rather than the database engine's own replication mechanism, which is why replication lag is typically under a second rather than being bound by binlog-style replication delays — this also rules out any option describing engine-level binlog replication. Secondary clusters are read-only by design and cannot accept writes on their own, so no relocation can happen without an explicit operation. For a planned relocation with no data loss, AWS provides the switchover operation (the current name for what used to be called managed planned failover); a separate, unplanned failover operation is reserved for recovering from an actual outage in the primary Region.

Source: Amazon Aurora User Guide: Using Amazon Aurora Global Database

Correct answer: .

AWS Regions never fail over to each other automatically — every one of the four Well-Architected disaster recovery strategies requires the workload's own architecture to make that happen, so treating them as interchangeable ignores how each is actually built. Backup and restore has the highest RTO and RPO of the four because it must provision infrastructure and restore data from scratch, which routinely takes far longer than a few minutes. Pilot light keeps only core data services running while everything else stays fully scaled down, so it still needs to provision and scale up compute before serving traffic — that startup time typically lands in the tens-of-minutes-to-hours range, not a reliable few minutes for any workload. Warm standby keeps a smaller but fully running, already-scaled copy of the environment, so it only needs to scale up rather than build from nothing, which is what makes minute-level recovery achievable without paying for full multi-site active/active.

Source: AWS Well-Architected Framework, Reliability Pillar: Disaster Recovery (DR) objectives and strategies

Correct answer: .

Route 53 doesn't rely on any single health checker's opinion: it operates checkers from many locations worldwide, and each one independently evaluates the endpoint using the consecutive-failure threshold that was configured. Route 53 then aggregates all of those independent opinions and only marks the endpoint unhealthy once 18% or fewer of the reporting checkers currently consider it healthy, precisely so that one checker's transient network blip can't flip the overall status on its own — that also means describing a single checker's failure count as automatically overriding the whole assessment gets the mechanism backwards. The consecutive-failure threshold isn't limited to CloudWatch-alarm-based health checks; it's the core mechanism for health checks that monitor an endpoint directly, too. And Route 53 doesn't require every single global location to fail before disabling failover, nor does it ever permanently disable failover once triggered — health status keeps being reevaluated continuously.

Source: Amazon Route 53 Developer Guide: How Amazon Route 53 determines whether a health check is healthy

Correct answer: .

Cross-Region Replication is a live replication feature, and live replication in S3 only ever copies new and updated objects from the moment the replication rule is enabled onward — it was never designed to look backward at a bucket's existing contents. That means objects added before replication was turned on need a separate, explicit action: an S3 Batch Replication job, which is specifically built to replicate existing objects on demand. Nothing about enabling Cross-Region Replication deletes older objects or touches them at all; they simply stay unreplicated until Batch Replication (or some other explicit copy) is run. Cross-Region Replication also has no dependency on S3 Transfer Acceleration, which is an unrelated feature for speeding up uploads over long distances, not a prerequisite for replication of any kind.

Source: Amazon S3 User Guide: Replicating objects within and across Regions

Correct answer: .

AWS Elastic Disaster Recovery (DRS) is purpose-built for this: it installs lightweight agents on source servers and continuously replicates their disks at the block level into a staging area in the target Region, using minimal, inexpensive compute and storage to hold that ongoing replica — full-sized recovery instances only get created at the moment of a drill or a real recovery, which is what keeps steady-state costs low. AWS Backup instead relies on periodic backup snapshots and a full restore process before anything can boot, which is a fundamentally slower path typically measured in hours. Amazon Data Lifecycle Manager only automates snapshot scheduling and retention; it has no mechanism to launch a runnable recovery instance at all. S3 Cross-Region Replication copies object storage, not EBS volumes or whole servers, and has no concept of converting replicated data into a bootable EC2 instance.

Source: AWS Elastic Disaster Recovery User Guide: What is Elastic Disaster Recovery?

Correct answer: .

Amazon EBS snapshots are incremental by nature, storing only the blocks that changed since the previous snapshot, but that incremental chain is tied to the Region where the snapshots were taken — it doesn't extend across Regions on its own. Protecting against a full Regional outage requires an explicit step: copying snapshots to another Region, and because that destination Region has no prior snapshot history for the volume, the first snapshot copied there is necessarily a full copy rather than an incremental one; later copies can then build their own incremental chain in that destination Region. Snapshots absolutely can be copied across Regions — that capability is a standard, supported operation, not something that's unavailable. And copying a snapshot elsewhere has no effect on the original snapshot or its incremental chain back in the source Region.

Source: Amazon EC2 User Guide: Copying an Amazon EBS snapshot

Correct answer: .

DynamoDB global tables use a multi-active replication model, meaning every replica in every Region can accept both reads and writes directly, rather than restricting writes to a single elected primary the way some other multi-Region database features do — that rules out describing the setup as having one write-capable Region with the rest strictly read-only pending manual promotion. Because writes can land in more than one Region for the same item, DynamoDB needs a way to settle conflicting concurrent writes, and by default it does so with a last-writer-wins rule, which also rules out claiming no conflict-resolution mechanism is needed. Global tables replicate asynchronously between Regions rather than offering an always-on strong consistency guarantee across all Regions at all times. Global tables remain a fully functional, actively-written key-value store in every participating Region, not a passive backup mirror.

Source: Amazon DynamoDB Developer Guide: Global tables - multi-active, multi-Region replication

Correct answer: .

Recovery Point Objective describes the maximum acceptable amount of data an organization could lose, measured as the time between the last good recovery point and the moment the interruption began — here, that's the gap between the 11:00 backup and the 14:00 outage, so up to three hours of changes made during that window are gone once the team restores from the 11:00 backup. Recovery Time Objective describes how long the workload was actually unavailable, measured between the interruption and service being restored — here, that's the interval between the 14:00 outage and the 15:30 recovery, so ninety minutes. Swapping those two definitions, treating them as the same window, or claiming RTO doesn't apply to Regional outages all describe the relationship incorrectly; RPO and RTO apply to any interruption regardless of its cause or scope, and they measure two different things: data loss versus downtime.

Source: AWS Well-Architected Framework, Reliability Pillar: Disaster Recovery (DR) objectives (RTO and RPO definitions)

Correct answer: .

With one primary and one secondary record under the failover routing policy, Route 53 only needs a way to judge the primary's health -- typically a health check, or Evaluate Target Health set to yes when the primary is an alias to an AWS resource -- to decide which record to return; while that primary is healthy, Route 53 answers queries with it, and only starts answering with the secondary once the primary is judged unhealthy, all without a health check ever being attached to the secondary record itself. The option requiring an independent health check on both records adds a mandatory step this simple one-primary/one-secondary setup doesn't need. The option describing weighted routing being required is backwards: failover routing policy alone is exactly what produces active-passive behavior, and active-active is what happens when other routing policies such as weighted are combined with health checks instead. The option describing latency-based comparison describes an entirely different routing policy (latency-based routing); failover routing policy makes its decision purely from health status, not measured response time.

Source: Amazon Route 53 Developer Guide: Active-active and active-passive failover

Correct answer: .

For an Application Load Balancer, cross-zone load balancing is on by default at the load balancer level and that default can't be changed there, which is exactly why the two targets in Availability Zone A and the single target in Availability Zone B still each receive a roughly even share of total requests: every load balancer node spreads traffic across all registered, healthy targets in every enabled Availability Zone rather than confining itself to targets in its own zone. The option describing cross-zone load balancing as off by default confuses this with Network Load Balancers, where cross-zone load balancing is in fact off by default; Application Load Balancers behave differently. Recreating the load balancer as a Network Load Balancer isn't required to control this setting for an ALB: cross-zone load balancing for an Application Load Balancer can instead be turned off at the target group level, which is the one place this particular default can be overridden. The option claiming traffic never crosses Availability Zone boundaries describes the opposite of what cross-zone load balancing actually does.

Source: AWS Elastic Load Balancing documentation: Application Load Balancers — Cross-zone load balancing

Correct answer: .

Amazon EC2 Auto Scaling continuously tries to keep an equivalent number of instances in each enabled Availability Zone, and when an impairment leaves the group unbalanced, it automatically corrects this once the zone recovers by launching new instances in whichever enabled Availability Zones currently have the fewest instances -- including the newly recovered one -- and only terminating the excess instances elsewhere afterward, which is what keeps this rebalancing from ever dropping the group's effective capacity partway through. No manual intervention is needed for this basic Availability Zone rebalancing, so treating it as a manual-only process is incorrect. Terminating the over-represented instances before the replacements are up would also get the order backwards from how Auto Scaling actually performs the swap, needlessly risking a capacity dip. Capacity Rebalancing is a separate, opt-in feature specifically for proactively replacing Spot Instances flagged as being at elevated risk of interruption; it has nothing to do with whether this ordinary Availability Zone rebalancing after an impairment happens automatically, which it does regardless of that setting.

Source: AWS documentation: Amazon EC2 Auto Scaling — Distribute instances across Availability Zones (rebalancing activities)

Correct answer: .

Amazon EFS replication works asynchronously: after the one-time initial sync finishes, Amazon EFS keeps the destination file system's data caught up to within a recovery point objective of about 15 minutes for most file systems, which is measured from the last successful sync rather than guaranteed on every individual write, so describing it as synchronous with a zero recovery point objective overstates what the feature provides. The destination file system is not simultaneously read-write alongside the source; it exists specifically to be promoted during a disaster or planned game-day exercise, and an explicit failover step is what makes it usable for reads and writes, with a separate failback step needed to resume normal operation on the original source afterward. Amazon EFS does support cross-Region replication as a purpose-built feature, so claiming only same-Region backups exist is incorrect.

Source: AWS EFS User Guide: Replicating EFS file systems (replication performance and RPO)

Correct answer: .

Route 53 ARC deliberately splits these two jobs into separate components: readiness check continually monitors resource quotas, capacity, and configuration in the standby Region so a team knows in advance whether a failover would actually succeed, and it's explicitly documented as not intended for the critical path during an actual failover event; routing control is the component built for that live moment, giving extremely reliable, guardrailed control over which Region's DNS traffic is active, with safety rules that prevent an operator from accidentally leaving an application with no healthy active replica. Swapping which component does which job gets the design backwards. Route 53 ARC's multi-Region recovery capability (routing control, alongside Region switch) handles failover between entire Regions, distinct from ARC's separate single-Availability-Zone zonal shift and zonal autoshift capabilities, so describing ARC as limited to single-AZ shifts within one Region ignores this multi-Region capability entirely. Readiness check and routing control are documented as distinct capabilities serving different purposes, not interchangeable names for one feature.

Source: AWS documentation: What is Amazon Application Recovery Controller (ARC) — Multi-Region recovery: routing control and readiness check

Correct answer: .

Static stability is the Well-Architected Reliability Pillar principle that a system should be able to keep running, or fail over, using capacity and configuration that already exist, rather than depending on control-plane API calls -- like launching new instances or scaling a group -- made in the middle of the very disruption it's trying to survive; those control-plane calls are exactly what can be slower or less reliable during a widespread event, since many other systems may be competing for the same API capacity at the same time. The recommended fix is to pre-provision and pre-scale the standby environment in advance, so a real failover only has to redirect traffic to resources that are already running rather than waiting on API calls to create them. Calling this unavoidable is wrong; static stability exists specifically to design around this dependency, and Multi-AZ standbys are themselves already provisioned in advance rather than launched reactively, which is part of why they achieve fast, predictable failover. This has nothing to do with the shared responsibility model or with AWS Support prioritizing API calls, and redefining RTO/RPO targets to match a flawed design's current performance addresses the symptom, not the architectural gap the question describes.

Source: AWS Well-Architected Framework, Reliability Pillar: Static stability using Availability Zones

Correct answer: .

With write forwarding enabled, a secondary cluster doesn't write to its own storage first -- it forwards the write's SQL statement, along with the necessary session and transactional context, to the primary cluster, which applies the change and remains the single source of truth before that change replicates back out to every secondary Region the normal way; that round trip to the primary and back is exactly why a forwarded write takes longer than a write issued directly against the primary. The option describing a local-commit-then-push order has this backwards -- the primary always changes first. Write forwarding is documented as supporting data manipulation statements such as inserts, updates, and deletes, while data definition language and certain other operations still need to run directly on the primary cluster's writer instance, so the feature doesn't universally forward every kind of write. It also doesn't turn secondary clusters into independent writers in their own right; the primary/secondary distinction and the underlying storage-level cross-Region replication mechanism both stay exactly as they were, which is also why the option describing a switch to engine-level logical replication is wrong -- write forwarding changes nothing about how the global database physically replicates data.

Source: Amazon Aurora User Guide: Using write forwarding in an Amazon Aurora global database

Correct answer: .

Compliance mode is the Object Lock retention mode built for exactly this requirement: once an object version is locked under compliance mode, its retention mode can't be changed and its retention period can't be shortened by any user at all, including the AWS account's own root user, and the documented exception -- deleting the entire AWS account -- makes clear just how absolute that protection is meant to be. Governance mode looks similar on the surface but is deliberately less strict: it's designed so most users are blocked from deleting or altering a locked object, while users holding the dedicated bypass permission can still override the lock, which is the opposite of the 'no one, ever' requirement here. A legal hold has no expiration date at all -- it protects an object indefinitely until someone with the right permission explicitly removes it -- so it doesn't provide a fixed retention date and doesn't describe compliance mode's behavior. S3 Versioning by itself, without Object Lock enabled, only keeps prior versions recoverable after a new version or delete marker is added; it does not stop a version from being permanently deleted outright, which is precisely the gap Object Lock closes.

Source: Amazon S3 User Guide: Locking objects with S3 Object Lock (retention modes)

Correct answer: .

For a Multi-AZ DB instance deployment, Amazon RDS reduces the impact of a required OS patch by applying it to the standby instance first, then promoting that now-patched standby to be the new primary, and finally patching the old primary, which becomes the new standby -- the only visible impact to the application is the brief Multi-AZ failover this promotion causes, typically well under a minute, rather than downtime for the full patching duration. Patching the live primary first, while it's still serving traffic, isn't how this process works and would defeat the purpose of having a standby ready to absorb the failover. Patching both instances simultaneously describes what happens for a database engine version upgrade, a different maintenance operation, not routine OS security patching, and that scenario doesn't apply here regardless of Single-AZ versus Multi-AZ. Mandatory OS updates aren't deferred indefinitely either; if left unapplied, RDS automatically applies them at or after their specified mandatory apply date during a maintenance window, whether or not an operator manually intervenes first.

Source: AWS RDS User Guide: Maintaining a DB instance — Maintenance for Multi-AZ deployments

Correct answer: .

AWS Resilience Hub is purpose-built for this: a team defines a resiliency policy expressing their RTO and RPO targets, and Resilience Hub assesses the application's actual architecture against that policy, surfacing specific gaps and prioritized, actionable recommendations for closing them, along with the ability to run tests that validate whether the recommendations actually improve resilience. Trusted Advisor instead runs general best-practice checks across categories like cost optimization, security, and service limits; it isn't built around a workload's own custom-defined RTO and RPO targets, which is why relying on it for this specific assessment is the wrong fit. AWS Backup is an operational service for centrally managing and executing backup and restore policies -- valuable for actually protecting data, but it doesn't itself assess an architecture's overall resiliency against defined recovery targets. Amazon CloudWatch provides monitoring and alarming on metrics; configuring alarms doesn't amount to an architectural gap analysis against RTO and RPO targets either.

Source: AWS Resilience Hub User Guide: What is AWS Resilience Hub