Practice Test #1

Route 53 latency-based routing with health checks can shift DNS, but it does not promote a cross-Region read replica to writer. Health checks against Aurora cluster endpoints can be misleading (endpoint may resolve while writer is impaired), and DNS caching/TTL can violate the tight 2-minute detection and fast cutover requirement. CloudTrail is not the right source for RDS failure notifications; it logs API activity, not service failover events.

Aurora custom endpoints are for routing within a single Aurora cluster (e.g., subset of instances) and do not span Regions or manage cross-Region replica promotion. You also cannot “update” a custom endpoint in eu-central-1 to point to a cluster/instance in eu-west-1. Using CloudTrail as a trigger for database unavailability is incorrect because CloudTrail does not emit service health/failover events.

Modifying and reapplying a CloudFormation stack during an outage is slow and operationally risky, and it does not directly address the need to promote the cross-Region replica based on writer endpoint unreachability. CloudFormation is not an eventing system for RDS failover, and stack updates can exceed the required RTO. This also adds unnecessary coupling between infrastructure deployment and incident response automation.

A weekly scheduled EventBridge rule is not responsive enough to meet the 5-minute requirement. It could detect a retirement event days late, and “check for events” is also not the normal pattern—AWS already emits the event. Additionally, hibernation is not the requested action (stop then start), requires hibernation prerequisites, and may not be supported/appropriate for all instance configurations.

EC2 Auto Recovery is designed for recovering from underlying hardware/host impairment (triggered by a CloudWatch alarm on StatusCheckFailed_System), not for scheduled instance retirement events. It also does not perform a stop/start cycle; it recovers the instance on new hardware while keeping the instance ID. Adding AWS Config to restrict recovery to a time window is not a standard or reliable control for this scenario.

Rebooting all instances weekly is a blunt, non-targeted approach that violates the requirement to restart only the affected instance. It also does not guarantee remediation of a scheduled retirement event, which typically requires stop/start (or replacement) rather than reboot. CloudWatch alarms for notification add monitoring but do not provide the required automated, event-driven remediation within 5 minutes.

Incorrect. A 99/1 weighted split intentionally routes a portion of client requests to the standby even when the primary is healthy. The scenario explicitly states the broker cannot operate across multiple active nodes, so any steady-state traffic to the standby risks concurrent active processing, session/state conflicts, and offset inconsistencies. Weighted routing is not the same as active/passive unless the standby effectively receives 0 traffic.

Incorrect. An ALB can perform health checks, but using listener target group weights 100 and 0 is not a dependable way to implement strict failover, and it introduces an always-on load balancer layer that may still attempt routing behaviors not aligned with “never send traffic to standby unless primary is unhealthy.” For single-active workloads, Route 53 health-check-based DNS failover is the simpler and more appropriate mechanism.

Incorrect. Like option B, using 99/1 weights sends some traffic to the standby during normal operation, violating the single-active constraint. Additionally, ALB target group weighting is designed for traffic distribution (canary/blue-green), not strict warm-standby failover for a stateful singleton. This could cause concurrent processing and state/offset issues even if both instances mount the same EFS.

Amazon GuardDuty is a threat-detection service that analyzes logs and telemetry for suspicious activity, not a configuration-governance service for deterministic detection of every RDS public accessibility change. It does not provide a direct control that says an SNS notification must be sent whenever PubliclyAccessible becomes true on an RDS DB instance. GuardDuty findings also depend on its own detection logic and finding generation, which is not the most precise match for this compliance-style requirement. This option therefore does not cleanly satisfy the requirement for centrally governed notification on a specific RDS configuration state change.

CloudTrail and EventBridge can detect the ModifyDBInstance API call quickly, but this design deploys the EventBridge rule and SNS topic into each member account, which means the notification path exists inside the accounts that are supposed to be prevented from bypassing it. The answer explanation relies on adding SCPs, but SCPs are not included in the proposed solution and would be necessary to make the anti-bypass claim credible. In addition, this approach is event-based on a specific API call rather than a centrally governed compliance evaluation of the resulting resource state. Because the question emphasizes delegated administrator and preventing member-account disablement or bypass, this decentralized StackSets design is not the best answer.

Amazon Inspector is focused on vulnerability management and exposure assessment, not on guaranteed near-real-time notification for a specific RDS configuration attribute change. Inspector findings are not the canonical mechanism for detecting that PubliclyAccessible was set to true on an RDS DB instance. The service does not map as directly to this governance requirement as AWS Config managed rules do. As a result, this option is less precise and less reliable for the stated compliance and notification objective.

This adds unnecessary complexity and overhead. Tagging instances and then calling IMDS plus the EC2 API requires additional IAM permissions, network/API availability, and extra logic to map tags to environments. It also introduces failure modes unrelated to deployment (throttling, missing tags). CodeDeploy already provides deployment group context directly to scripts, so this is not the least-management approach.

CodeDeploy does not support arbitrary “custom environment variables per deployment group” in the way implied here for hook scripts. Typically, you use built-in variables or external configuration sources (Parameter Store/Secrets Manager) if needed. Also, ValidateService is generally for post-deploy validation; changing Nginx config there is late and can cause mismatches unless you also reload/restart, complicating the flow.

DEPLOYMENT_GROUP_ID is not the right selector for human-friendly environment mapping and is not the commonly used variable for this purpose; scripts typically rely on DEPLOYMENT_GROUP_NAME. Even if an ID were available, you would still need to maintain an ID-to-environment mapping, increasing operational overhead. Using the Install hook is also less typical for config changes than BeforeInstall/AfterInstall.