Reliability and Business Continuity practice questions

Weighted routing policy

Why it fails: Weighted routing policy in Amazon Route 53 assigns a weight to each resource record and returns DNS records in proportion to those weights, enabling load balancing across multiple instances. However, it does not evaluate the health of the target instances unless you explicitly attach health checks to the records, and even then it only stops responding with the IP when the health check fails. For a simple two-instance web application needing automatic failover when one instance becomes unhealthy, weighted routing would still return the unhealthy instance's IP to a portion of clients instead of routing all traffic to the healthy one.

Geolocation routing policy

Why it fails: Geolocation routing policy routes traffic based on the geographic location of the DNS resolver (the user's IP address) rather than the health or availability of your resources. You can map different instances to serve users from specific continents, countries, or states, but Route 53 does not automatically reroute traffic when a particular instance becomes unhealthy — it simply continues responding with the record associated with that location. This policy is optimized for content localization and compliance, not for detecting instance failure and shifting traffic like the requirement here.

Simple routing policy

Why it fails: Simple routing policy in Amazon Route 53 is the most basic policy: it allows you to define a single record with multiple values (e.g., all IP addresses) and returns all values in a random order, or a single value if only one is configured. It does not support health checks, so Route 53 cannot distinguish between healthy and unhealthy instances, and every client receives the same set of IPs regardless of instance status. Because there is no mechanism to stop returning an unhealthy instance's IP, simple routing cannot provide automatic failover between the two EC2 instances.

Place tasks in a single Availability Zone.

Why it fails: Placing all tasks in a single Availability Zone creates a hard dependency on that AZ's infrastructure. If the AZ experiences an outage, network partition, or power failure, the ECS service has no capacity to fail over because all task instances are co-located. This violates the high-availability design goal for critical applications, as even a healthy task in a healthy AZ cannot serve traffic if the entire AZ is impacted. This is the opposite of the recommended approach.

Use a binpack placement strategy.

Why it fails: Binpack placement strategy optimizes for the smallest number of container instances or the highest resource utilization, not for AZ diversity. It will place tasks on the instance that has the most available CPU or memory to meet the task's requirements, which can easily result in all tasks being scheduled onto a single container instance within one AZ. While binpack is efficient for cost and resource usage, it directly contradicts the need for high availability, as a single instance failure or AZ outage could take down the entire application.

Increase the desired task count to 10.

Why it fails: Simply increasing the desired task count to 10 does not influence where ECS places those tasks; placement is determined by the service's placement strategy and constraints. Without a spread strategy, the ECS scheduler could still place all 10 tasks on the same container instance or within the same AZ, especially if the instance has sufficient resources to run them. More tasks don't equate to more AZ resilience; you need to explicitly spread tasks across AZs to achieve high availability. In fact, increasing the count may even increase the blast radius if they're all co-located.

Use Amazon Data Lifecycle Manager (DLM) to take snapshots every hour and use AWS Backup to copy them to us-west-2. In a disaster, restore the snapshot as a volume and attach to a new instance in us-west-2.

Why it fails: This is the correct answer because Amazon Data Lifecycle Manager (DLM) automates the creation of hourly EBS snapshots, satisfying the 1-hour RPO with minimal manual effort. AWS Backup can then automatically copy these snapshots to us-west-2, ensuring a current, recoverable copy exists in the DR region. During a disaster, you can restore the snapshot as an EBS volume and attach it to a pre-provisioned EC2 instance in us-west-2; if the instance and volume attachment are scripted (e.g., with a small bootstrapping script), the 15-minute RTO is achievable. The combination of DLM for lifecycle scheduling and AWS Backup for cross-region replication provides a fully managed, reliable DR solution.

Enable Amazon S3 Cross-Region Replication for the EBS volume's snapshot repository.

Why it fails: This option misunderstands how EBS snapshots are stored. While EBS snapshots are indeed backed by Amazon S3, they are placed in an internal, AWS-managed bucket that you cannot access directly, and S3 Cross-Region Replication cannot be enabled on that bucket. Even if you could enable CRR, the snapshot metadata and the actual data blocks are not ordinary S3 objects available for replication; snapshot copying must be done through the EC2 API, AWS Backup, or DLM’s cross-region copy feature. Therefore, simply enabling S3 CRR on the snapshot repository is not technically possible and would not provide the needed cross-region disaster recovery.

Attach an additional EBS volume configured with RAID 1, and use rsync to replicate data every hour to a volume in us-west-2.

Why it fails: This approach relies on manual scripting and additional infrastructure, which is not a managed or automated solution. You would need to maintain a second EBS volume in us-west-2, continuously run rsync processes, and handle the complexity of keeping the RAID 1 mirror in sync across regions, including dealing with network latency and consistency. Moreover, rsync-based replication is not crash-consistent and does not capture the full state of the application unless you also script volume attachment and instance launching. This method would be fragile, difficult to maintain, and would likely fail to meet the 15-minute RTO without significant custom automation, unlike the fully managed DLM/AWS Backup approach.

Set the Auto Scaling group's desired capacity to a high number.

Why it fails: A high desired capacity does not place instances in multiple Availability Zones, so an AZ failure still removes all capacity. Desired capacity is the correct control when the requirement is throughput or headroom, not AZ-level resilience, which needs subnet and AZ distribution.

Create a CloudWatch alarm that triggers if the ALB has elevated 5xx errors.

Why it fails: A CloudWatch alarm on ALB 5xx errors detects failures after they occur but does not restore capacity in a surviving Availability Zone. Alarms belong to monitoring and response design; the resilience requirement needs the Auto Scaling group configured across multiple subnets in different AZs.

Use a single EC2 instance type for all instances.

Why it fails: A single instance type does not distribute capacity across Availability Zones, so an AZ outage still takes down every instance in it. Uniform instance types are the right choice when simplifying fleet management or capacity reservations, not when surviving an AZ failure.

Create a VPC peering connection between VPC A and VPC B, and use route tables to send traffic through the inspection VPC.

Why it fails: VPC peering is a direct, one-to-one network connection between exactly two VPCs. Route tables cannot force traffic to transit through a third VPC because VPC peering does not support transitive routing; any traffic between VPC A and VPC B would take the direct peering path, bypassing the inspection VPC entirely. Even if you added explicit routes, the peering connection itself is not capable of forwarding to another peering attachment, so the inspection requirement fails.

Use security groups in the inspection VPC to filter traffic between VPC A and VPC B.

Why it fails: Security groups are stateful virtual firewalls that are attached to individual elastic network interfaces (ENIs) and only evaluate traffic to and from the resources they protect. They cannot be placed in an inspection VPC to filter traffic flowing purely between other VPCs because they are not inline for transit traffic. Security groups do not operate at the network routing layer and cannot inspect or forward packets between VPCs; they only filter traffic destined to or originating from the specific instances that carry them.

Attach a NAT gateway in the inspection VPC and configure route tables in VPC A and B to point to the NAT gateway.

Why it fails: A NAT gateway is designed to enable outbound internet connectivity for instances in private subnets by translating private addresses to the public IP of the gateway. It does not support routing or forwarding traffic between VPCs, nor is it an inspection or firewall appliance. Pointing VPC A and VPC B route tables to a NAT gateway in the inspection VPC would only send traffic toward the internet, not between the VPCs, and the NAT gateway would drop any non-internet traffic, causing connectivity failure.

Create a cross-region read replica in us-west-2 and promote it during a disaster.

Why it fails: A cross-region read replica in us-west-2 replicates asynchronously, so the lag between the source and replica can exceed the required 5-second RPO under load or network delays. Promoting a read replica is a manual action that stops replication, applies remaining log segments, and then makes the database writable, which takes time and is not automatic. While this option provides a readable secondary in another region, it cannot guarantee zero data loss or fast automatic failover.

Take daily automated snapshots and copy them to another region.

Why it fails: Daily automated snapshots are taken once per 24-hour period, so the maximum data loss (RPO) is up to 24 hours, plus the time needed to copy the snapshot to another region. In a disaster, you would manually restore that snapshot into a brand-new DB instance, and the RTO includes not only snapshot restore time but also configuration changes, making it too slow for a 5-second RPO and fast failover requirement.

Deploy the database in a single AZ and use point-in-time recovery.

Why it fails: Deploying in a single AZ and relying on point-in-time recovery means you have one database instance with no redundant standby; if the AZ fails the database is unavailable. PITR restores from automated backups and transaction logs, but the RPO can be up to 5 minutes and the RTO includes provisioning a new instance, restoring the latest snapshot, and applying logs—manually. This approach does not provide automatic failover and cannot meet a 5-second RPO or fast recovery.

Enable S3 Versioning and S3 Same-Region Replication (SRR)

Why it fails: A is incorrect because Same-Region Replication (SRR) does not replicate data to another region, so it cannot provide disaster recovery if the primary region fails.

Enable S3 Versioning and transfer data to another region using AWS DataSync

Why it fails: C is incorrect because AWS DataSync is designed for large-scale, one-time or scheduled transfers, not continuous real-time replication, and cannot guarantee sub-5-minute RPO.

Enable S3 Versioning and S3 Cross-Region Replication (CRR) with replication time control (RTC)

Why it fails: D is incorrect because CRR with RTC guarantees replication within 15 minutes (99.99% of objects), but does not meet the less-than-5-minute RPO requirement.

Create a CloudWatch Events rule to trigger a Lambda function that creates snapshots

Why it fails: Creating a CloudWatch Events rule to trigger a Lambda function for snapshots necessitates writing custom code to manage both the snapshot creation and the specified 7-day retention policy, including deletion. This introduces unnecessary operational overhead and potential for errors for a standard requirement. This approach is tempting as CloudWatch Events and Lambda are excellent for bespoke automation tasks, particularly when integrating with non-AWS services or executing highly specific pre/post-snapshot actions not natively supported by managed backup solutions.

Use AWS Backup to create a backup plan with hourly frequency

Why it fails: AWS Backup can do this, but the question asks for THREE steps; DLM is more direct for EBS snapshots.

Weighted routing policy

Why it fails: Weighted routing policy is incorrect because it is designed to split traffic across multiple records by relative weights, not to provide automatic failover between a primary and a standby. Although you can attach health checks to weighted records so unhealthy records are omitted, Route 53 does not promote a designated secondary or maintain the active-passive semantics required for this scenario. The operator must adjust weights or rely on the remaining records, which is not the same as automatic failover.

Geolocation routing policy

Why it fails: Geolocation routing policy is incorrect because it selects DNS responses based on the geographic location of the requesting resolver and a set of geographic mappings. It does not inherently evaluate the health of the target endpoint; a geolocation record will continue to return an unhealthy resource unless you explicitly associate a health check and configure a fallback behavior. This policy is meant for location-based traffic management, not for automatic failover between primary and secondary endpoints.

Latency routing policy

Why it fails: Latency routing policy is incorrect because it chooses the record that provides the lowest round-trip latency for the client, typically by region, rather than checking endpoint health. It can serve traffic to an unhealthy endpoint if that endpoint still has the lowest latency, as latency and health are independent metrics. Route 53 does not automatically reroute to a backup solely because the lowest-latency endpoint becomes unhealthy; health checks would need to be manually associated, and even then it is not a primary/secondary failover policy.

Enable deletion protection.

Why it fails: Deletion protection only prevents accidental deletion of the database instance through the RDS console or APIs; it does not create any backup, replica, or failover mechanism. If the underlying hardware fails or data becomes corrupted, deletion protection does nothing to restore availability or data. It is an operational safety control, not a recovery strategy, so it has no effect on RTO or RPO.

Create manual snapshots daily.

Why it fails: Manual snapshots are durable, user-initiated backups that you must manually restore by launching a new DB instance and then updating your application's DNS or connection strings. This restore process can take tens of minutes to hours, so RTO is longer than with a live replica or Multi-AZ failover. Additionally, daily manual snapshots leave up to 24 hours of potential data loss (RPO), making them less effective than automated backups with point-in-time recovery for minimizing data loss.

The instances are out of memory; increase the instance size.

Why it fails: Memory exhaustion would typically cause the web application to fail, the instance to become unresponsive, or even result in kernel panics, but the instance is passing EC2 status checks, which confirm that the OS is reachable and running. Although EC2 status checks do not directly monitor memory, an out-of-memory condition severe enough to make the ALB health check fail would almost certainly also affect the system-level status checks or cause the process to crash completely. Since the instances are running and the health check failure is isolated to the ALB's application-level probe, the root cause is not memory pressure, and resizing the instance would not correct a health check path or port mismatch.

The Auto Scaling group's scaling policy is not launching new instances; update the policy.

Why it fails: The Auto Scaling group's scaling policy adjusts the desired capacity based on CloudWatch metrics, but the problem here is not a lack of instances—it's that existing instances are marked unhealthy by the ALB, as evidenced by HealthyHostCount being zero. If the scaling policy were at fault, you would see fewer running instances than the desired capacity or the desired capacity set to zero, but the instances are already running. Scaling policies have no effect on the health status of individual instances; they only add or remove capacity. Updating the policy would not alter the ALB's health check evaluation, so this is not the correct remediation.

Enable MFA Delete on the bucket.

Why it fails: MFA Delete adds a second authentication factor to permanently delete an object version or change the bucket's versioning state, but it does not prevent ordinary overwrites or object deletions—it only requires extra authentication for those specific destructive actions. It guards against unauthorized permanent deletions but does not help recover data that has already been overwritten or logically deleted, so it cannot serve as a backup mechanism for ongoing data recovery.

Configure S3 Cross-Region Replication.

Why it fails: S3 Cross-Region Replication asynchronously copies new objects and updates to a destination bucket in another AWS Region, but it does not protect against deletion on the source; deletions in the source bucket are replicated as delete markers to the destination if delete marker replication is enabled, which would compromise the replicated copy. Additionally, replication is one-way and cannot prevent an object from being overwritten in the source. While it provides geographic redundancy, it cannot restore original data once it has been mutated or removed from the source bucket.

Enable default encryption (SSE-S3) on the bucket.

Why it fails: Server-side encryption with SSE-S3 encrypts objects at rest using Amazon-managed keys, protecting data from unauthorized access at the storage layer, but it has no bearing on object lifecycle operations such as deletion or overwriting. Encryption ensures confidentiality if an unauthorized party gains access to the underlying storage, yet it cannot prevent or undo a DELETE request or a PUT that replaces an existing object. Therefore, it neither preserves prior versions nor recovers deleted data, making it irrelevant to the backup strategy.

The target group has no registered targets.

Why it fails: Incorrect because the stem explicitly states the target group has healthy EC2 instances, meaning registered targets exist; 'no registered targets' directly contradicts the given information.

The target group health check is misconfigured.

Why it fails: Correct because a misconfigured health check can cause the ALB to consider all targets unhealthy, even if the instances are healthy, leading to 503 errors.

Modify the application to store session data in the RDS database instead of ElastiCache.

Why it fails: Storing session data in RDS increases database load and latency, and does not address cache warm-up; it also may violate performance SLAs.

Increase the size of EC2 instances in us-west-2 to handle the load faster.

Why it fails: Increasing EC2 instance size does not reduce cache population time; the bottleneck is the cache initialization, not compute capacity.

Increase the desired capacity to 6 to ensure enough capacity if one AZ fails.

Why it fails: Simply raising the desired capacity does not guarantee that the extra instances will be placed in the surviving AZs, especially if the Auto Scaling group's maximum size is not increased accordingly. Without cross-zone load balancing, the Application Load Balancer only routes traffic to instances in the same Availability Zone as the requesting client, so instances in a failed AZ are unreachable regardless of total count. The ASG must have a sufficient maximum size to launch replacement capacity in the remaining AZs, and the ALB must be configured to distribute traffic across all healthy instances in all AZs.

Configure the Auto Scaling group to launch instances in only two AZs to reduce costs.

Why it fails: Limiting the Auto Scaling group to only two Availability Zones reduces the application's fault tolerance compared to using three or more AZs, because the failure of one AZ would leave only a single AZ to handle 100% of the traffic. In a two-AZ configuration, the loss of one AZ removes up to half of the instance capacity with no additional AZ to absorb the load. The goal is to maintain availability, and cost reduction via fewer AZs undermines that objective without addressing the capacity required during an AZ failure.

Place the Auto Scaling group in a single AZ to simplify management.

Why it fails: Placing the entire Auto Scaling group in a single Availability Zone creates a single point of failure: any outage affecting that AZ, such as a power loss or network failure, will render all instances and the application unavailable. Since the application is stateless, it can be deployed across multiple AZs without the complexity of data replication, so simplification does not justify the availability risk. High availability design requires the ASG to span multiple AZs with a load balancer to distribute traffic.

The ALB health check threshold of 2 consecutive failures is too low, causing premature instance replacement.

Why it fails: The ALB health check threshold of 2 consecutive failures is a standard, reasonable setting and is not the root cause. Even if the threshold were higher, the EC2 instances would still fail health checks because they are unable to connect to the database due to DNS caching after failover. The health check fails due to application-level database connectivity issues, not because the threshold is too sensitive. Premature instance replacement would occur regardless of the threshold as long as the cache persists.

The application connection pool timeout of 5 seconds is too short for RDS failover.

Why it fails: A five-second connection pool timeout is short, but the root cause is that connections are directed to the old primary IP, not timeout duration. Extending the timeout would not help because the connections are being made to an unreachable address, so they would eventually time out and still fail. Also, connection pool timeouts typically manifest as intermittent application errors, not as health check failures and subsequent instance replacement. The correct fix is to address DNS caching or implement a retry mechanism that re-resolves DNS.

The Multi-AZ RDS configuration is insufficient; the company should implement a warm standby database in another Region.

Why it fails: Multi-AZ RDS is working correctly to promote the standby within the same Region; the failure is on the client side. Implementing a warm standby in another Region would not resolve DNS caching on existing EC2 instances, which are trying to reach the old primary IP. Additionally, a cross-Region warm standby introduces latency and complexity without addressing the actual connectivity problem. The application already has Multi-AZ protection, so the solution should focus on updating connection strings or retrying on new DNS resolution.

Use AWS Backup to manually copy the bucket to another Region.

Why it fails: AWS Backup copy jobs are scheduled or on-demand, not continuous, so recent objects can be lost, and cross-Region backup storage plus request charges cost more than replication. It fits compliance-driven backup retention, not the cheapest continuous cross-Region durability.

Enable S3 Versioning on the bucket.

Why it fails: S3 Versioning retains multiple variants of objects within the same bucket in one Region, so a Region-wide failure still loses all data. It is the right choice for recovering overwritten or deleted objects, not for cross-Region disaster recovery.

Use S3 Standard storage class.

Why it fails: S3 Standard replicates only within a single Region, so a Region-wide outage leaves the data unrecoverable; durability across facilities does not equal cross-Region resilience. It is tempting because it suits frequently accessed data needing low latency and high throughput, but the requirement here is Region-survivable storage, which needs Cross-Region Replication or S3 Multi-Region Access Points.

Enable sticky sessions (session affinity) on the ALB.

Why it fails: Enabling sticky sessions on the ALB ties a user's session to a specific EC2 instance via a cookie. While this keeps session data local to that instance, it creates a single point of failure: if the instance becomes unhealthy or terminates, the ELB fails over to another instance, but the in-memory session data is lost and the user is forced to re-authenticate or lose progress. Additionally, sticky sessions can cause an uneven load distribution as some instances receive a disproportionate share of traffic.

Mount the same EBS volume to all EC2 instances to share session data.

Why it fails: Mounting the same EBS volume to all EC2 instances is technically impossible for most volume types, as standard EBS volumes support single-attach only. Even for specialized multi-attach volumes (like io1/io2), concurrent access from multiple instances would lead to data corruption unless a cluster-aware file system is used, and the volume is confined to a single availability zone. This approach also reintroduces a single point of failure at the storage layer, does not scale, and is not a recommended session-sharing mechanism.

Store session data in an ElastiCache Memcached cluster.

Why it fails: Using ElastiCache Memcached to store session data provides fast in-memory access, but Memcached is an ephemeral cache with no built-in persistence or replication. If a cache node fails or is replaced, all session data is irretrievably lost, causing active users to be logged out. While ElastiCache Redis with Multi-AZ can offer persistence, Memcached clusters are not appropriate for durable session state, making this an unreliable option for a fault-tolerant web application.

The health check endpoint returns 5xx errors, which are ignored by the ALB.

Why it fails: The health check endpoint returning 5xx errors would cause the instance to be marked unhealthy, not ignored. This is incorrect because ALB does not ignore 5xx errors.

The UnhealthyThresholdCount is set too low.

Why it fails: Two consecutive failed checks already tolerate a single transient blip, so lowering the threshold would mark instances unhealthy sooner, worsening the intermittent failures. A low UnhealthyThresholdCount suits endpoints expected to respond consistently within the timeout.

The health check is using TCP instead of HTTP.

Why it fails: Using TCP instead of HTTP for health checks would still check connectivity; it would not cause intermittent failures if the instance is reachable. The problem is related to the health check threshold, not the protocol.