AWS High Availability and Disaster Recovery: RTO, RPO, and the Four DR Levels

The exam uses these terms precisely, and so should you. High availability means the system recovers from failures quickly enough to meet its availability target — brief interruption or degradation is acceptable. An Auto Scaling group replacing a failed instance in a few minutes, or RDS failing over to its standby with a short pause, is high availability: users may notice a blip, but the workload comes back without human intervention. Fault tolerance is the stronger promise: the system keeps operating with no interruption at all when a component fails, because redundant components are already running in active parallel and absorbing the load the moment one dies. Fault tolerance always costs more, because you pay for the redundancy continuously whether or not anything fails.

Disaster recovery is the third concept, and it is different in kind: HA and fault tolerance handle component failures inside a running architecture, while DR is the plan for when the architecture itself is lost — typically a Region-scale event — and the workload must be restored somewhere else. HA is architecture; DR is strategy plus rehearsed process.

The reason the distinction matters on the exam is wording. A stem that says the application "must remain available" or "must recover automatically" is asking for high availability — Multi-AZ, Auto Scaling, load balancing. A stem that says users "must experience no interruption" or the system "cannot tolerate any downtime or data loss" is asking for fault tolerance — active-active redundancy, synchronous replication, capacity already running. Choosing the fault-tolerant design when only HA was required fails the MOST cost-effective qualifier; choosing the merely highly available design when the stem demanded zero interruption fails the requirement itself. Read the promise the scenario is making to its users before you look at the options — it is usually stated in one sentence, and it selects between answers that are otherwise both technically correct.

Two details sharpen the line. First, a running hot standby is still not fault tolerance. If one instance serves while a second one waits, and a health check moves an Elastic IP or DNS record to the standby when the first fails, requests in flight are lost and new ones fail for the time it takes to detect the failure and switch over. Only when the load is already shared across several active instances, with enough spare capacity in the survivors, does a failure cause no interruption.

Second, fault tolerance across zones is a sizing exercise called static stability: run enough capacity that losing a zone still leaves what you need, instead of relying on Auto Scaling to launch replacements during the event. To keep N instances after losing one of Z zones, run N × Z/(Z−1), spread evenly. If the workload needs 6 instances, that is 9 across three zones (3 per zone, 6 survive) or 12 across two zones (6 per zone, 6 survive), which is why spreading across three zones is usually the cheaper fault-tolerant layout.

Availability design starts by finding every component whose failure takes the workload down. SAA-C03 hides these in the setup sentences, and each has a standard fix. A single EC2 instance is the obvious one: put it in an Auto Scaling group across multiple AZs behind a load balancer.

A single Availability Zone is subtler. Subnets are AZ-scoped, so anything deployed into one subnet (an entire ASG, a database, an EFS mount target) lives or dies with that AZ. The fix is always the same: spread across at least two AZs. Watch especially for the single NAT gateway. The classic zonal NAT gateway is highly available only within its AZ: if every private subnet routes 0.0.0.0/0 through one zonal NAT gateway and that AZ fails, instances in the surviving AZs lose outbound access too. The resilient zonal design is one NAT gateway per AZ, with each private subnet's route table pointing at the gateway in its own AZ, which also avoids cross-AZ data charges. Since 2025 a NAT gateway can instead be created in regional availability mode: one regional NAT gateway automatically expands to the Availability Zones where the VPC has workloads (a newly used zone can take up to an hour to be added), needs no public subnet, and every private route table points at the one gateway ID, removing the per-AZ setup (the VPC still needs an internet gateway, and private NAT still requires zonal mode). Either design removes the SPOF; one zonal gateway serving every zone does not.

State on the instance is the failure multiplier: if sessions live in a web server's memory or files sit on its disk, losing the instance loses data even when the ASG replaces it. Move sessions to ElastiCache or DynamoDB and files to S3 or EFS, and instances become disposable. Self-managed components are single points of failure you chose to own: a message broker, cache or model server on one EC2 instance is a SPOF plus a patching burden. And a single Region is only a single point of failure when the requirements say so; if the stem states the workload must survive a Region outage, you are in DR territory, covered below.

Purpose-built managed services

The cheapest way to remove a self-managed SPOF is often to stop running the component. AWS AI services such as Amazon Comprehend (text analysis) and Amazon Polly (text-to-speech) are fully managed Regional APIs: AWS runs and scales the infrastructure behind them, so there is no server for you to make redundant, unlike a model hosted on your own instance. Where a managed service still offers a deployment choice, the availability answer is the multi-AZ one: Amazon MQ as an active/standby broker (ActiveMQ) or a cluster deployment of three nodes across AZs (RabbitMQ) rather than a single-instance broker, and ElastiCache as a replication group with a replica in another AZ and Multi-AZ automatic failover rather than a single node.

Legacy applications that cannot be changed

The exam's "improve the reliability of an application that cannot be modified" scenario is answered with infrastructure around the app: an Application Load Balancer that health-checks it and stops routing to a failed node, an Auto Scaling group for self-healing, and whatever state can be moved off the instance. When the app must stay a single instance, two tools behave differently and the scenario's constraint picks one:

Choose automatic recovery when clients, licences or allow-lists depend on the instance's fixed private IP; choose the Auto Scaling group when surviving an AZ failure matters more. Neither preserves instance store data. The exam rewards the option that removes the named SPOF with the least change, not the one that re-architects everything.

The standard highly available tier is an Elastic Load Balancer distributing traffic to an Auto Scaling group that spans at least two AZs. The load balancer health-checks every target and stops routing to failures; the ASG replaces failed instances and rebalances across zones. Together they survive both instance failure and AZ failure with no human involvement, and this pairing is the assumed baseline in nearly every Task 2.2 answer.

Three configuration details decide whether that baseline really works:

• The load balancer's zones must match the group's zones. An ALB (which needs at least two enabled AZs) only routes to targets in the Availability Zones enabled on it. Instances the ASG launches in a zone the ALB is not enabled in are registered but receive no traffic. Cross-zone load balancing does not fix that: on an ALB it is always on at the load balancer level (target groups can opt out), and it spreads requests across targets in enabled zones only.
• The ASG's health check type defaults to EC2 status checks, which only see hardware and operating-system failures. An instance whose application returns errors still passes them, so the ALB stops sending it traffic but the ASG never replaces it. Turn on ELB health checks for the group so instances that fail the target group's health check are replaced.
• Keep the replacement health check shallow. A health-check endpoint that also queries a shared dependency, such as the database, fails on every instance at once when that dependency has a problem, and the ASG then replaces the whole healthy fleet. Let the check prove the instance itself can serve, and watch dependencies with separate CloudWatch alarms.

The database tier is where the exam gets precise, and where it sets its favorite trap. RDS Multi-AZ in its classic DB instance deployment maintains a standby in a different AZ with synchronous replication. When the primary or its AZ fails, RDS automatically fails over by repointing the instance's DNS endpoint at the standby, typically within a minute or two, with no data loss. The trap: that standby is not readable. It serves no traffic at all, so any answer that sends report queries to "the Multi-AZ standby" of a DB instance deployment is wrong. The newer Multi-AZ DB cluster deployment changes that, and read replicas are a third shape:

The decision rule: automatic failover with no data loss inside a Region is Multi-AZ; readable standby capacity plus faster failover on MySQL or PostgreSQL is the Multi-AZ DB cluster; scaling reads or seeding another Region is read replicas; a scenario needing both availability and read scaling on a DB instance deployment gets both. Aurora blurs the line: its storage is replicated across three AZs and its replicas are both readable and failover targets, so if the stem says Aurora, replicas do double duty.

The final building block is RDS Proxy: a managed database proxy that pools and shares connections. It matters for availability three ways. During a failover it holds application connections open and routes them to the new writer as soon as it is ready, cutting the effective failover time and sparing the application a reconnection storm. It gives clients a stable endpoint: an application that caches DNS (a JVM is the classic case) can keep resolving an Aurora cluster endpoint to the old writer after a failover, while the proxy endpoint never changes. And for serverless callers it prevents a burst of Lambda invocations from exhausting the database's connection limit. Trigger phrases: "reduce failover time," "applications experience errors during failover," "Lambda functions overwhelm database connections."

Storage durability on AWS depends on its scope: instance store lives and dies with the instance, EBS lives in one Availability Zone, and EFS and S3 are Regional services that store data across multiple AZs. Choosing storage for an available design means matching that scope to the failure you must survive.

Two consequences come up repeatedly. A shared file system that must stay available when a zone fails is EFS with a mount target in each AZ, not an EBS volume shared through Multi-Attach, which never leaves its zone. And the way to move EBS data to another AZ is through a snapshot: schedule snapshots (Amazon Data Lifecycle Manager or AWS Backup), then restore one into a volume in the surviving zone. The RPO is the snapshot interval.

Route 53 is how you steer traffic above the Region: load balancers distribute within a Region, while Route 53 health checks decide which records DNS returns, which makes it the failover mechanism for multi-Region designs. A health check can probe an endpoint from checkers around the world, follow the state of a CloudWatch alarm, or combine other checks into a calculated health check. Alarm-based checks let failover follow a business metric rather than a ping: if the requirement is "fail over when users cannot sign in," publish the login success rate as a custom metric, alarm on it, and base the health check on that alarm. That is how you identify metrics from business requirements: a page that loads but cannot do its job is down for the business.

Detection is not failover. Any monitoring signal whose only action is a notification to a person changes nothing in DNS; failover happens only when the signal backs a Route 53 health check that a routing policy uses.

Failover routing

Failover routing is the policy built for availability: a primary record serves all traffic while healthy, and a secondary record takes over when the primary is unhealthy. It is the standard active-passive pattern: primary Region to DR Region, or an application endpoint failing over to a static maintenance page on S3 and CloudFront. When the primary is an alias record to an ALB, set Evaluate Target Health to Yes (or attach a health check); otherwise Route 53 has nothing to evaluate and always treats the primary as healthy, so the secondary is never used.

Recovery time through DNS has two parts: detection (the check's request interval multiplied by its failure threshold) plus DNS caching, because resolvers and clients keep the old answer until the record's TTL expires. A long TTL delays failover no matter how fast the health check trips, so lower the TTL on failover records ahead of time. Route 53 query logs show the answers Route 53 returned; they cannot show what a caching resolver is still handing to clients, which is why logs can show the switch while some users still reach the old Region.

The other routing policies

The elimination rule: "send users to the closest/fastest Region" is latency; "send a percentage" is weighted; "return several addresses but only healthy ones" is multivalue, not simple; "survive a Region failure with a passive standby" is failover. After you pick the DR strategy in the next sections, Route 53 failover or weighted routing is almost always the mechanism that actually moves the users.

Every disaster recovery decision on this exam reduces to two objectives, and you must hold their definitions precisely. Recovery time objective (RTO) is the maximum acceptable time between the disruption and the restoration of service — how long the business can be down. Recovery point objective (RPO) is the maximum acceptable data loss, measured as time: how far back the most recent recoverable copy of the data may be when disaster strikes. An RPO of one hour means losing up to the last hour of writes is tolerable; an RPO near zero means data must be replicated continuously.

The two numbers drive different levers, which is why the exam quotes both. RPO is about data movement: it dictates how often data leaves the primary site. Nightly backups give an RPO measured in hours (up to a day); continuous asynchronous replication gives an RPO of seconds to minutes; synchronous replication gives an RPO of zero within its scope. RTO is about standing infrastructure: it dictates how much of the recovery environment already exists before the disaster. If everything must be provisioned from scratch, restoration takes hours; if a full environment is already serving traffic, restoration is near-instant. Tightening either number costs money — more frequent replication, more idle infrastructure — which is why cost qualifiers and RTO/RPO figures always appear together.

Your exam method: extract the two numbers from the stem first, before reading the options. "Must be restored within four hours with no more than 15 minutes of data loss" is RTO = 4 hours, RPO = 15 minutes — and immediately you know nightly backups fail the RPO, so any backup-and-restore option with daily snapshots is eliminated regardless of how cheap it is. Then apply the golden rule: choose the cheapest strategy whose RTO and RPO both satisfy the requirement. Over-delivering — picking active-active when warm standby meets the numbers — is exactly what the MOST cost-effective qualifier is written to punish, and under-delivering fails outright. The four strategies in the next section are the ladder those numbers select from.

When an existing design misses its objectives, diagnose which objective is missed before changing strategy. If restores finish in time but lose too much data, only RPO is missed: send data to the recovery Region more often (for example, RDS cross-Region automated backup replication, covered below) without paying for standing compute. If the data is fresh enough but rebuilding takes too long, RTO is missed: pre-provision more of the environment (pilot light, warm standby) or automate the rebuild.

AWS frames disaster recovery as four strategies on a spectrum. Each step up runs more infrastructure in the recovery Region, buys a faster RTO and tighter RPO, and costs more. Learn them as a ladder, because exam questions are answered by finding the lowest rung that meets the stated numbers.

Backup and restore keeps only data in the recovery Region: backups and snapshots are copied cross-Region, and after a disaster you provision the entire stack from scratch — far faster and more repeatably if infrastructure is defined as code. Everything you launch from must already exist in the recovery Region: AMIs and EBS snapshots are Regional, so copy the AMIs there (an AMI copy, or an AWS Backup copy rule) alongside the IaC templates, because an AMI ID from the primary Region means nothing in the DR Region. Nothing runs day to day, so it is the cheapest strategy, but RTO is measured in hours and RPO is set by backup frequency. Pilot light keeps the core alive: data is continuously replicated to a live database or storage layer in the recovery Region, and minimal or no compute runs until needed — servers exist as images and templates, switched off. Because the data is already there and current, RPO drops to seconds or minutes, and RTO falls to tens of minutes — the time to start and scale compute around the warm core. Warm standby runs a complete, functional, scaled-down copy of the whole workload in the recovery Region, continuously receiving replicated data and able to serve (reduced) traffic immediately; failover is scaling it to production capacity and shifting traffic, for an RTO in minutes. Multi-site active-active runs the workload at full capacity in multiple Regions simultaneously, with users served from both and data replicated between them; a Region failure just removes one serving location, for RTO and RPO near zero to seconds — at close to double the infrastructure cost. Active-active also needs a data layer that accepts writes in every Region, which narrows the database choice (see the cross-Region data layer section).

Two boundary cases trip candidates. Pilot light vs warm standby: in pilot light the application cannot serve requests until compute is started; in warm standby it already can, just not at full load. And Multi-AZ is not on this ladder at all — it is in-Region high availability, not disaster recovery; when the stem says "survive a Region failure," a Multi-AZ answer is an automatic elimination.

The database decides how fast and how cleanly a Region failover can happen, and the three cross-Region options behave differently when the primary Region is lost.

Cross-Region read replica (RDS). The runbook is two steps: promote the replica to a standalone writable instance (this ends replication), then repoint the application, by updating the DNS name it connects through (for example, a Route 53 record) or its connection string. Promotion does not change the endpoint the application already uses. "Reboot with failover" is a Multi-AZ feature inside one Region and does nothing for a cross-Region replica. Asynchronous replication means the RPO is the replica lag at the moment of failure.

Aurora Global Database. One primary Region holds the only writer cluster; storage-level replication keeps read-only secondary Regions typically under a second behind. Write forwarding lets applications in a secondary Region send writes, but the database forwards them to the primary, so there is still one writer Region: if the primary Region is lost, writes stop until a secondary is promoted. Two operations move the writer, and the exam distinguishes them:

• Switchover (formerly "managed planned failover"): for a healthy primary, such as a DR drill or Region rotation. It waits for the secondary to catch up, so RPO is zero.
• Failover with data loss allowed: for an unplanned Regional outage. It promotes a secondary immediately; writes not yet replicated are lost (RPO is the replication lag).

Aurora Global Database provides a global writer endpoint that always points at the current primary cluster, so applications using it need no connection change after either operation.

DynamoDB global tables are multi-active: every replica Region accepts reads and writes, which makes them the natural data layer for active-active designs where users write in both Regions. They offer two consistency modes:

The decision rule: writes needed in several Regions at once points to DynamoDB global tables; a relational workload with fast cross-Region DR and local reads points to Aurora Global Database (one writer); a cheaper RDS setup that accepts manual promotion and a DNS change points to cross-Region read replicas.

Data protection rests on three tools, and the exam distinguishes them by which failure each defends against: replication survives the loss of a Region, versioning survives mistakes, and isolated, locked backups survive a compromised account. AWS Backup is the umbrella: centralized backup plans that schedule and manage backups across services (EBS, EC2, RDS, Aurora, DynamoDB, EFS, S3 and more) with policy-based retention, cross-Region copy and cross-account copy within AWS Organizations. When a scenario asks to "centrally manage and automate backups across multiple services or accounts," AWS Backup is the answer over per-service scripting.

Ransomware and account compromise: cross-account copy plus Vault Lock

An attacker with administrator access in the production account can delete backups stored in that account. The resilient pattern is to copy backups into a vault in a separate account and lock that vault with AWS Backup Vault Lock, which has two modes:

• Governance mode: blocks deletions and retention changes, but users with sufficient IAM permissions can remove the lock. Useful for testing settings or guarding against accidents.
• Compliance mode: after a grace period (cooling-off time), the lock is immutable. No one, including the account root user or AWS, can delete recovery points before retention ends or remove the lock.

Ransomware resilience needs both halves: compliance mode stops deletion even by a compromised administrator, and the separate account keeps the copies out of the compromised account's reach.

Cross-account copy has an encryption catch. For resource types that AWS Backup does not fully manage, such as RDS, Aurora and EBS, the copy job must be able to read the source recovery point, which is encrypted with the source resource's KMS key, so the destination account must be granted use of that key (the copy itself is then encrypted with the destination vault's key). AWS managed keys such as aws/rds or aws/ebs cannot be shared, because their key policies cannot be edited, so the source resources must be encrypted with a customer managed key shared with the destination account, and the destination vault cannot use the aws/backup managed key for those types.

Service-level mechanics

EBS snapshots are incremental and Regional, and can be copied cross-Region; an AMI captures a full launchable machine image, the unit pilot light keeps on the shelf. RDS automated backups enable point-in-time recovery within the retention window, while manual snapshots persist until deleted and can be copied to another Region. RDS cross-Region automated backup replication (for supported engines) copies snapshots and transaction logs to a second Region, so you can restore to a point in time there: the low-cost way to tighten RPO in a backup-and-restore design without running a replica.

S3 replication: forward-only, with options

S3 Cross-Region Replication copies new objects asynchronously to a bucket in another Region, and versioning must be enabled on both buckets. A replication rule is forward-only: it copies objects written after the rule exists. Objects already in the bucket need S3 Batch Replication; nothing else backfills them. Related features answer different needs:

Replication is for disasters; versioning is for mistakes

Replication faithfully copies what happens at the source, so it does not protect you from yourself. S3 Versioning is the defense against accidental deletion and overwrite: every version is preserved, a delete merely writes a delete marker, and recovery is removing the marker or restoring a prior version. A scenario about "a user accidentally deleted objects" is answered by versioning (with MFA Delete or Object Lock for stronger variants), not by replication, because a replicated delete is just a delete in two Regions. Conversely, "data must be available in another Region if this one fails" is replication, and versioning alone does nothing for it.

Backup questions usually hide the real requirement in one phrase: "across all accounts in the organization" (AWS Backup cross-account), "even an administrator must not be able to delete them" (Vault Lock compliance mode), "recover to any point in the last 7 days" (RDS point-in-time recovery), "protect against accidental deletion" (versioning), "the bucket already holds data" (Batch Replication). The wrong options defend against a different failure than the one named.

Operational readiness means the environment you fail over to, or redeploy into, behaves exactly like the one you tested. Two practices from the task statement carry most of it.

Immutable infrastructure and blue-green

With immutable infrastructure, servers are never patched or modified in place: every change ships as a new artifact (a new AMI, a new container image) deployed as new instances, and the old ones are discarded. Configuration drift disappears, every environment is reproducible from code, and rollback becomes redeploying the previous artifact rather than un-editing a live server. The AWS tooling for it on EC2:

• EC2 Image Builder builds, tests and distributes patched AMIs on a schedule (including to other Regions and accounts).
• An Auto Scaling instance refresh replaces the group's instances gradually with ones from the new launch template version, keeping a minimum healthy percentage in service. With auto rollback enabled and CloudWatch alarms specified, an alarm during the refresh reverts the group to the previous launch template version; an alarm without auto rollback only fails the refresh, leaving the instances already replaced on the new version.
• CloudFormation drift detection reports resources whose actual configuration no longer matches the stack template, which is how you find out-of-band changes someone made in the console.

The natural deployment pattern is blue-green: stand up the new (green) environment alongside the old (blue), shift traffic with Route 53 weighted records or a load balancer, and keep blue running until green proves healthy. If the release fails, shifting traffic back to blue is fast, which is why blue-green also counts as a failover strategy.

Service quotas and throttling

Quotas are per account and per Region, and that second part is the trap: a pilot light or warm standby environment that must scale to production size during a failover will hit the recovery Region's default quotas unless you requested increases there ahead of time, sized for full production, through the Service Quotas console. For accounts that do not exist yet, such as new DR accounts created by an account factory, a Service Quotas quota request template associated with the organization automatically requests the listed per-Region increases for each new account. Service control policies cannot raise quotas (they only restrict permissions), and Trusted Advisor only reports usage against quotas.

When an AWS API throttles a caller, the correct client behavior is retries with exponential backoff and jitter; retrying in a tight loop makes the overload worse, and synchronized retries from many clients arrive in waves without jitter. A scenario about "ThrottlingException errors during a traffic surge" wants backoff (and, for sustained load, a quota increase), not bigger instances.

The failure-to-mechanism map

AWS X-Ray shows where in a distributed request path latency or errors come from. In a microservices or serverless architecture, availability problems surface as symptoms far from their cause: the API is slow because a dependency three hops away is erroring. X-Ray records traces of individual requests end to end across API Gateway, Lambda, containers and instrumented code, and draws a trace map (service map) that shows which component adds the latency or faults. CloudWatch metrics tell you that something is wrong; X-Ray shows where in the request path it breaks.

Turning it on for a serverless API takes two switches: enable X-Ray tracing on the API Gateway stage and turn on active tracing for the Lambda functions. Calls from the function to downstream services such as DynamoDB appear as subsegments when the code's AWS SDK client is instrumented (the X-Ray SDK, now in maintenance mode, or the AWS Distro for OpenTelemetry). Similar-sounding tools answer different questions:

Sampling controls cost. The default rule records the first request each second plus 5% of additional requests, so a rare error on one path can go unrecorded. A custom sampling rule, matched on attributes such as the URL path or service name and given a priority, can record that path at a higher rate without tracing everything. Groups are different: a group is a filter expression over traces that were already recorded (with its own trace map and metrics); it does not change what gets sampled.

Scenario 1 — DR strategy selection by the numbers. A company runs a business-critical application in one Region and must prepare for a Region-wide outage. Requirements: RTO of 30 minutes, RPO of 5 minutes, and the solution must be as cost-effective as possible. Options: (A) nightly backups copied to another Region, with infrastructure recreated from CloudFormation after a disaster; (B) continuously replicate the database to the second Region and keep templates and AMIs ready to launch the application tier on failover; (C) run a scaled-down but fully functional copy of the workload in the second Region, scaling it up on failover; (D) run the workload at full capacity in both Regions behind latency-based routing.

Extract the numbers first: RPO 5 minutes kills option A immediately — nightly backups mean up to 24 hours of data loss, and rebuilding a full stack also blows the 30-minute RTO. Both B (pilot light) and C (warm standby) meet RPO through continuous replication; the question is RTO. Pilot light recovers in tens of minutes — launching pre-built AMIs behind existing templates fits inside 30 minutes — and warm standby recovers in minutes, comfortably inside it too. Now the qualifier decides: both meet the numbers, and pilot light runs less idle infrastructure, so B is correct. D also meets everything but doubles the run cost — the classic over-delivery trap under a cost qualifier. Had the RTO been "a few minutes," pilot light would fail and C would win; had it said "near-zero downtime and data loss," only D survives. Same ladder, different rung — the numbers choose.

Scenario 2 — Multi-AZ vs read replicas. An application uses RDS for MySQL. It must remain available if an Availability Zone fails, with no data loss and no manual intervention, and the team also wants to offload heavy reporting queries from the primary. Options: (A) add a read replica in another AZ and promote it if the primary fails; (B) enable Multi-AZ and run reporting queries against the standby; (C) enable Multi-AZ for failover and add a read replica for reporting; (D) snapshot hourly and restore into another AZ on failure.

Eliminate D: restoring from hourly snapshots is manual, slow, and loses up to an hour of data — fails all three requirements. Eliminate A: read replicas replicate asynchronously (possible data loss) and promotion is a manual step (intervention), so a replica alone is not an availability mechanism. Eliminate B on the trap this lesson flagged: the Multi-AZ standby is not readable — you cannot point reporting at it. C is correct: Multi-AZ delivers synchronous replication and automatic failover (no data loss, no intervention), and the read replica absorbs reporting. Two requirements, two tools — the exam frequently writes questions where each half of the answer handles one stated need, and the wrong options try to stretch one tool over both.