Question 110
An operations team uses RDS automated backups with a recovery objective requiring restoration to a specific minute before an accidental bulk update. It has only monthly manual snapshots in its documented recovery plan. Which recovery technique better fits?
- Restore the latest manual snapshot and replay no transaction logs, even when the target minute is weeks after the snapshot was created.
- Use Aurora/RDS Multi-AZ automatic failover to undo an accidental but successfully committed database update.
- Copy the most recent RDS snapshot to another Region but omit transaction-log-based point-in-time recovery within retention.
- Use RDS point-in-time restore within the supported automated-backup retention window and validate the new restored instance.
Explanation
Correct Answer
D:PITR uses automated backups and logs to select a recovery moment rather than accepting the much coarser monthly snapshot gap.
Incorrect Answers
A:A manual snapshot captures one point in time and cannot alone recover to an arbitrary recent minute.
B:Failover provides availability and normally replicates committed changes; it does not reverse logical errors from past transactions.
C:Regional copies help disaster recovery but do not meet minute-specific logical restore unless the supported PITR backup window is used.
Question 111
A team restores a DynamoDB table to a moment before an operator accidentally overwrote thousands of records. Management assumes PITR will overwrite the current table in place and retain the same stream and downstream references. What recovery behavior must they plan for?
- Recreate DynamoDB global table replication and assume it returns overwritten values into the existing table without a restore or cutover.
- Disable current table writes and try PITR directly onto the same table name without creating a new restored table.
- Restore DynamoDB PITR to a new table, then verify schema, indexes, encryption, downstream event processing and controlled application cutover.
- Restore to a new table but assume its streams, IAM, autoscaling and dependent consumers automatically inherit all settings unchanged.
Explanation
Correct Answer
C:DynamoDB PITR creates a separate restored table, so dependencies and client routing require explicit coordination.
Incorrect Answers
A:Replication propagates current writes; it does not rewind mistaken updates or replace DynamoDB PITR behavior.
B:DynamoDB PITR restores into a new table, requiring planned consumer, stream and application cutover; it is not an in-place rewind.
D:A restored table is a distinct resource; verify associated features, permissions and downstream references before switching production.
Question 112
A payment ledger is migrating to a new DynamoDB Multi-Region Strong Consistency (MRSC) global table across supported Regions. During a load test, two regional clients concurrently update the same item. One receives ReplicatedWriteConflictException even though the second Region and the witness are healthy. What application behavior best preserves correctness?
- Disable conditional writes and assume MRSC automatically merges both conflicting financial modifications into a single accumulated balance.
- Change to eventual-consistency reads in every Region and assume that makes conflicting write requests globally serializable without retry.
- Create an additional witness in a fourth arbitrary Region and assume the write conflict exception will never occur again.
- Handle ReplicatedWriteConflictException with bounded retry and jitter, re-evaluate business invariants and idempotency, and avoid treating a failed concurrent write as committed.
Explanation
Correct Answer
D:DynamoDB MRSC can reject concurrent conflicting writes. Clients should retry safely after the conflict ends and preserve financial operation idempotency and invariant checks.
Incorrect Answers
A:MRSC provides globally consistent item state but does not automatically merge the application semantics of simultaneous, conflicting balance updates.
B:Read-consistency choice does not eliminate write conflicts or make an unsuccessful update committed; a retry strategy remains necessary.
C:MRSC topology has documented Region/replica/witness limits; increasing witness count is not the solution to concurrent item modifications.
Question 113
A primary-region Aurora Global Database cluster is healthy, and the company plans to move the write workload to a secondary Region for scheduled maintenance with as little potential data loss as supported. Which operation should be evaluated?
- Trigger an Aurora Global Database unplanned failover despite having a healthy primary and a scheduled maintenance window.
- Plan a managed global database switchover for the healthy-cluster maintenance event and validate client connectivity afterward.
- Stop all cross-Region replication hours before maintenance and manually promote the secondary without first confirming lag.
- Change only the application Route 53 alias to the read-only secondary cluster endpoint, without a database writer switchover.
Explanation
Correct Answer
B:A planned switchover can synchronize and transfer writer responsibility with different risk characteristics from an emergency failover.
Incorrect Answers
A:Unplanned failover is for outage conditions and may increase data loss; managed switchover is appropriate for coordinated healthy-region moves.
C:Stopping replication early increases data-loss exposure and undermines the minimal-loss planned transition requirement.
D:Routing to a read-only secondary does not change global writer ownership. An Aurora switchover plus application endpoint plan is required.
Question 114
A production Application Load Balancer runs in three Availability Zones of one AWS Region. One AZ becomes impaired but other AZs have been pre-scaled to absorb all customer traffic. Incident command needs a supported temporary operator-controlled action to move traffic away from the impaired AZ without changing the primary Region or copying data to a second Region. Which AWS recovery capability fits?
- Use a Route 53 ARC multi-Region routing control to evacuate the entire healthy Region instead of the impaired AZ only.
- Use Amazon Application Recovery Controller zonal shift for the supported opted-in load-balancer resource, directing traffic away from the affected AZ for a controlled period.
- Modify ALB target-group health-check thresholds only and assume this is equivalent to the operator-controlled removal of an AZ from service.
- Run ARC readiness checks and assume a green or red score automatically executes an ALB zonal shift.
Explanation
Correct Answer
B:ARC zonal shift is designed for temporary operator-directed traffic movement away from an impaired AZ for supported regional resources after ensuring healthy-AZ capacity.
Incorrect Answers
A:Cross-Region evacuation unnecessarily shifts the whole application when supported zonal shift can move ALB traffic away from one impaired AZ.
C:Health checks detect target problems; zonal shift explicitly directs supported load-balancer traffic away from the AZ for a controlled interval.
D:Readiness checks are advisory. Operators must initiate the actual supported zonal shift recovery control.
Question 115
A team uses Route 53 ARC readiness checks to assess whether the standby environment has sufficient scaling and capacity. It assumes a GREEN readiness check automatically transfers production traffic when the primary fails. Which correction is necessary?
- Treat readiness checks as assessment signals; configure and test a separate routing-control or DNS failover mechanism for actual traffic movement.
- Require readiness checks to stay green but omit configured failover routing because the check result will move DNS traffic automatically.
- Enable Route 53 health checks for the primary but leave secondary deployment and routing targets untested, relying on readiness status alone.
- Use application recovery readiness checks as a substitute for practicing region promotion and client cutover.
Explanation
Correct Answer
A:Readiness evaluation indicates recovery preparation but does not itself perform routing failover for application endpoints.
Incorrect Answers
B:Readiness assessment and traffic-control actuation are separate; an explicit routing-control or DNS failover path must be deployed.
C:Health signals are useful but cannot prove routing to and successful service restoration on an adequately prepared standby.
D:A readiness indication does not validate the actual operational steps and measured RTO of a completed failover drill.
Question 116
A Route 53 failover record set serves a primary ALB endpoint and a secondary ALB endpoint. An engineer has created two records with the same name and type but configured both with the PRIMARY failover role and no valid SECONDARY entry. The desired design is an active-passive answer with supported health-aware selection. Which record design fixes the configuration?
- Create one PRIMARY and one SECONDARY failover record for the same name and type with distinct record identifiers, and associate supported health/evaluate-target-health settings so Route 53 can select the standby when the primary is unhealthy.
- Keep both records as PRIMARY and give them different TTL values, expecting DNS caches to infer which record is passive.
- Change the record routing policy to latency-based and assume it preserves exclusive primary/secondary failover role semantics.
- Delete the SECONDARY destination and configure only a primary health check, expecting Route 53 to synthesize a regional standby endpoint.
Explanation
Correct Answer
A:Active-passive Route 53 failover routing requires a primary and a secondary record with valid identifiers and health behavior, not two primaries.
Incorrect Answers
B:TTL controls caching and cannot replace the required PRIMARY/SECONDARY selection policy for two same-name answers.
C:Latency routing directs queries to lower-latency healthy endpoints, not a strict primary/secondary pair configured under failover policy.
D:Route 53 will not generate an endpoint in another Region; the secondary record and target must exist and be healthy.
Question 117
After a controlled regional failover, a commerce platform has fenced the old primary and promoted a secondary database as the only writer. The formerly isolated primary returns with a divergent transaction history, and an operator proposes re-enabling it as writer immediately. What should happen before any planned failback?
- Keep the former primary fenced, reconcile or rebuild its state from the authoritative writer, verify replication/invariants, then perform a separately controlled writer handoff.
- Re-enable writes in the former primary as soon as the Region is reachable, then resolve conflicting order IDs only if customer complaints appear.
- Change Route 53 DNS back to the original Region without reconciling the two database histories because route control alone guarantees data consistency.
- Increase the former primary instance class and assume additional memory makes its divergent committed state identical to the active writer.
Explanation
Correct Answer
A:Before failback, a formerly isolated writer must not resume until its state is made consistent with the authoritative primary; a verified, controlled handoff preserves order invariants.
Incorrect Answers
B:Turning the old writer on before reconciliation recreates split-brain behavior and can overwrite or duplicate committed customer transactions.
C:DNS movement affects endpoint selection, not reconciliation of divergent database history or writer ownership across Regions.
D:More database capacity does not merge conflicting order state; logical recovery and controlled promotion are required.
Question 118
A cloud backup program uses recurring AWS Backup plans tagged by application tier. Recently launched production RDS databases are missing from backups because their resource tags differ from the documented selection rule. Which control should be corrected?
- Increase AWS Backup vault retention and assume it adds newly launched databases even when tag-based resource selection excludes them.
- Standardize tags and backup plan resource selections, then verify new resources appear in scheduled jobs and retention reports.
- Enable backup cross-account copying but leave the resource selection rule missing the new production RDS databases.
- Create AWS Config rules only, then treat their compliance alerts as actual generated database backups.
Explanation
Correct Answer
B:Tag-based backup coverage depends on actual selection matches; testing new-resource enrollment closes the gap.
Incorrect Answers
A:Retention applies to selected recovery points, not discovery of improperly tagged resources. Fix selection and tagging governance.
C:Cross-account copy does not back up a resource omitted from its source backup plan in the first place.
D:Detection can flag missing backups but a correct Backup plan resource selection is needed to produce recovery points.
Question 119
An on-premises application is protected by AWS Elastic Disaster Recovery. The disaster site can launch recovery instances in AWS, but management needs assurance that restored servers will not start with outdated network settings and untested boot dependencies. What should the team do?
- Monitor replication lag continuously and assume low lag proves every restored VM boots with correct network identity and application dependencies.
- Perform only a boot test of one isolated test server without validating multi-server dependencies or factory interfaces.
- Rely on the default DRS launch template without rehearsing target VPC routes, IAM profiles or recovery-instance connections.
- Run non-disruptive recovery drills with representative launch settings, boot ordering and application checks, and repair failed dependencies.
Explanation
Correct Answer
D:Replication of blocks does not prove OS startup, subnet routing, identity permissions or applications will function after launch.
Incorrect Answers
A:Replica freshness is not a successful recovery launch; drill the exact network, boot ordering and business service readiness.
B:One server starting does not guarantee that the application stack, database connections and inter-server startup order work during DR.
C:Unverified default launch settings may differ from production dependencies and fail recovery even with intact replicated disks.
Question 120
A regional business application has S3 data and stateless compute deployed to two Regions, but the second Region requires a copy of the original KMS-encrypted secrets and regional IAM configuration. A disaster drill fails only at secret retrieval. Which dependency must the recovery design handle?
- Replicate S3 objects but leave secret values and KMS permissions configured exclusively in the primary Region.
- Replicate a Secrets Manager secret metadata record without decryptable regional KMS key access for the standby application role.
- Grant the standby service broader s3:GetObject permissions and assume it can retrieve Secrets Manager secrets through the S3 data path.
- Provision or replicate the secret in the secondary Region under a usable regional KMS key and authorize the recovery workload role.
Explanation
Correct Answer
D:A recovered app cannot start if a required secret remains accessible only with a primary-region encryption key or policy.
Incorrect Answers
A:S3 object replication does not automatically create regional Secrets Manager replicas or provide an authorized recovery-region KMS path.
B:Secret existence is insufficient when ciphertext depends on a key or permissions unavailable during primary-region isolation.
C:S3 object permissions are separate from Secrets Manager and KMS authorization; the missing dependency requires proper secret replication and access.
AWS Certified Solutions Architect - Professional SAP-C02 Practice Tests