Reliability and Business Continuity practice questions

Enable DynamoDB Accelerator (DAX).

Why wrong: Incorrect. DAX is a cache that improves read performance but does not provide disaster recovery across regions.

Create a read replica in another region.

Why wrong: Incorrect. DynamoDB does not offer read replicas; the feature for multi-region replication is global tables.

Increase read and write capacity units.

Why wrong: Incorrect. Capacity adjustment affects performance within a single region, not availability during a regional outage.

Modify the DB instance to Single-AZ and then back to Multi-AZ.

Why wrong: Incorrect. This would cause downtime and is not a proper failover test; it changes the architecture.

Reboot the DB instance without selecting any failover option.

Why wrong: Incorrect. A standard reboot does not force failover; it restarts the current primary.

Promote the standby instance using the Amazon RDS console.

Why wrong: Incorrect. Multi-AZ standby is not a read replica; it cannot be promoted manually. Promotion applies to read replicas.

Deploy an additional EC2 instance in the same Availability Zone.

Why wrong: Incorrect. Adding instances in the same AZ does not protect against an AZ failure.

Enable termination protection on all EC2 instances.

Why wrong: Incorrect. Termination protection prevents accidental termination but does not protect against AZ failure.

Use an Amazon RDS Multi-AZ deployment for the database tier.

Why wrong: Incorrect. While this improves database availability, the question asks about the application itself, and the web servers remain vulnerable.

Use an Application Load Balancer with an Auto Scaling group and a launch configuration that includes the Elastic IP

Why wrong: Elastic IPs cannot be associated with an auto-scaled instance via a launch configuration. Additionally, an ALB expects dynamic IPs; using an EIP for the instances behind the ALB is not standard and adds complexity.

Create a CloudFormation template that launches a new instance and associates the Elastic IP

Why wrong: While CloudFormation can launch a new instance and associate the EIP, it does not provide automatic failure detection and recovery. Manual or scheduled intervention would be required to detect failure and launch the replacement.

Place the instance in an Auto Scaling group with a minimum of 1 and a maximum of 1, and set the health check to replace unhealthy instances

Why wrong: This would replace the instance if it fails, but it does not address data persistence. The new instance would be launched from the original AMI, losing any data that was not on persistent storage. It also does not automatically reassociate the Elastic IP.

Amazon RDS Performance Insights

Why wrong: Performance Insights is for database performance tuning, not for reviewing failover event details.

Amazon CloudWatch Logs

Why wrong: CloudWatch Logs captures log files, but without custom instrumentation from the application or database, failover details are not logged.

AWS CloudTrail

Why wrong: CloudTrail logs API calls made to RDS, but the automatic failover process is not initiated by an API call; it's an internal service event.

Increase the Auto Scaling group minimum to 10 instances to absorb the failure.

Why wrong: Running 10 instances in a single AZ still results in total failure if that AZ fails.

Use larger instance types to handle the load of a failed AZ.

Why wrong: Larger instances do not provide AZ redundancy; if the only AZ fails, all instances are lost.

Use multiple Application Load Balancers in different AZs.

Why wrong: Having multiple ALBs does not solve the issue if the EC2 instances are all in a single AZ; the instances still fail.

Use Amazon Route 53 with weighted routing to distribute traffic between the two regions. Use a global DynamoDB table for session data, and launch EC2 instances in the DR region only when a failure is detected using AWS CloudFormation StackSets.

Why wrong: Weighted routing does not automatically failover; it requires manual adjustment. CloudFormation StackSets would take time to provision instances, likely exceeding the 1-hour RTO. Also, the requirement mentions ElastiCache Redis, not DynamoDB.

Use an Amazon CloudFront distribution with multiple origins (primary and DR). Enable session stickiness at the CloudFront level. Use EC2 instances in both regions behind separate ALBs. No special data replication is needed because sessions are stored in Redis.

Why wrong: CloudFront does not provide cross-region failover for origins in the way Route 53 does. Session stickiness is not sufficient for DR because Redis data is not replicated across regions, so users would lose sessions after failover. RPO would be effectively longer than 15 minutes without replication.

Use EC2 instances with an Auto Scaling group in both regions. Schedule a Lambda function to take snapshots of the Redis cluster every 15 minutes and copy them to the DR region. Use Route 53 latency routing to direct users to the nearest region.

Why wrong: Snapshot-based replication every 15 minutes could meet the RPO, but copying snapshots and restoring them during a disaster would take more than 1 hour, exceeding the RTO. Latency routing does not provide automatic failover in a regional outage; it routes based on latency, which could still send traffic to the failed region.

Enable detailed monitoring on the RDS instance and stream the logs to Amazon CloudWatch Logs where a metric filter can detect failover patterns.

Why wrong: Detailed monitoring provides performance metrics at a higher frequency, but it does not generate failover events. Failovers are not captured in standard logs; they are separate events.

Configure AWS CloudTrail to log all RDS API calls and analyze the logs for the 'Failover' event type.

Why wrong: CloudTrail logs API calls made to the RDS service (e.g., modifying a DB instance). The internal failover process is not an API call initiated by the user; it is an automated action and is not recorded in CloudTrail.

Use AWS Config to create a config rule that evaluates whether the 'DBInstanceStatus' changes to 'failover' and then trigger a remediation action.

Why wrong: AWS Config records configuration changes and compliance over time. A failover event does not change a persistent configuration unless the instance is modified. Config rules are not suitable for capturing transient events like failovers.

Use a launch template that includes a pre-warmed Amazon Machine Image (AMI) with all software pre-installed, and configure the Auto Scaling group to use a larger instance type to reduce initialization time.

Why wrong: A pre-warmed AMI can reduce installation time, but it does not eliminate the need for instance launch and initialization (e.g., booting, cache warming). Increasing instance type may not significantly reduce boot time and increases cost.

Use scheduled scaling to predictively launch instances before the traffic spikes based on historical patterns.

Why wrong: Scheduled scaling works for predictable patterns but does not help with unpredictable traffic spikes. It may either over-provision or under-provision.

Configure lifecycle hooks to add a wait time during instance launch so that the instance is fully configured before it is placed behind the load balancer.

Why wrong: Lifecycle hooks add delays to the launch process, making the time to service longer. They are useful for custom actions but do not reduce initialization time.

Create an Auto Scaling group that spans at least two Availability Zones, attach the existing EBS volume to the new instances, and use an ALB to distribute traffic.

Why wrong: An EBS volume can only be attached to one instance at a time. To share data, use a distributed file system like Amazon EFS or a database. This option does not solve the stateful issue.

Place the EC2 instance in an Auto Scaling group with a minimum and maximum of 1 in the same AZ, and attach an Elastic IP to the instance.

Why wrong: This does not provide multi-AZ redundancy. An AZ failure would still cause an outage. An Elastic IP does not provide automatic failover.

Use an ALB with the existing single instance as the target, and enable cross-zone load balancing.

Why wrong: A single instance cannot survive an AZ failure if the AZ fails. Cross-zone load balancing distributes traffic across instances in different AZs, but there is only one instance in one AZ.

Increase the stickiness duration to a very high value so that sessions are not lost during brief interruptions.

Why wrong: Stickiness only controls how long the load balancer binds a user to an instance. If the instance fails, the session is lost regardless of the duration.

Change the Auto Scaling group to use a larger instance type to handle more sessions per instance, reducing the likelihood of session loss.

Why wrong: This does not prevent data loss if an instance fails. Sessions are still stored locally on the instance.

Configure the Auto Scaling group to use a larger minimum size and a lower maximum, so instances are less likely to be terminated.

Why wrong: While this reduces the frequency of scale-in events, it does not protect against instance failures. Sessions are still lost on instance termination.

Create a read replica of the RDS instance in a second region. Configure an Amazon CloudFront distribution with the ALB as origin. Use Route53 failover routing policy to route traffic to the CloudFront distribution.

Why wrong: CloudFront is for content delivery, not DR failover. Promoting a read replica requires manual steps, increasing RTO beyond 2 hours.

Take daily manual snapshots of the RDS instance and copy them to a second region. Store the AWS CloudFormation template for the infrastructure in an S3 bucket with cross-region replication. In the event of a disaster, manually deploy the stack and restore the snapshot.

Why wrong: Manual snapshots and deployments are too slow to meet the 2-hour RTO. Also daily snapshots may not meet the 1-hour RPO.

Use AWS Database Migration Service (DMS) to continuously replicate data to a second region. Use an Application Load Balancer in the primary region and a Network Load Balancer in the secondary region. Create a Route53 weighted routing policy to distribute traffic.

Why wrong: Weighted routing does not automatically failover; it distributes traffic based on weights. DMS adds complexity and cost. This solution does not provide automatic failover for a regional outage.

Use Amazon Data Lifecycle Manager (DLM) to take hourly snapshots and create an AWS CloudFormation template to launch a new instance from the snapshot.

Why wrong: DLM can schedule snapshots, but it requires additional steps to automate recovery (e.g., CloudFormation) and lacks centralized backup management features like cross-region copy and monitoring that AWS Backup offers, resulting in higher operational overhead.

Use custom scripts to copy snapshots to an Amazon S3 bucket and restore from there.

Why wrong: This approach requires developing, testing, and maintaining custom scripts, which increases operational overhead and risk of errors.

Use Amazon S3 Lifecycle policies to transition data to Amazon S3 Glacier.

Why wrong: S3 Lifecycle policies manage object storage classes, not EBS snapshots. This does not provide point-in-time recovery for EBS volumes.

Use sticky sessions (session affinity) on the ALB and configure the Auto Scaling group with a larger min size.

Why wrong: Sticky sessions ensure a user is always directed to the same instance, but if that instance fails or is terminated, the session data stored in memory is lost.

Deploy the application in multiple AWS Regions and use Amazon Route 53 with latency-based routing.

Why wrong: Multi-Region deployment addresses regional failures, not cross-AZ high availability. It is unnecessary for the stated requirement and does not solve the session data loss problem within a single Region.

Store session data in an Amazon RDS for MySQL database and configure the application to read/write session state to the database.

Why wrong: While a database can persist session data, RDS is slower than an in-memory cache for this use case and requires more significant application changes. ElastiCache is a better fit.

Create manual snapshots of the DB instance every hour and copy them to another AWS Region.

Why wrong: Manual snapshots are taken at intervals; copying to another Region adds delay. This approach cannot guarantee an RPO of 1 hour because the snapshot schedule may miss the window, and recovery requires creating a new instance from the snapshot which can take longer than 2 hours.

Enable automated backups with a retention period of 35 days and restore to a different Region when needed.

Why wrong: Automated backups are stored only in the same Region. You would need to copy them manually, and the RPO is at least the backup window (usually 24 hours for automated backups), exceeding the 1-hour RPO.

Use AWS Database Migration Service (DMS) to continuously replicate data to a DB instance in another Region.

Why wrong: DMS can provide continuous replication, but it adds operational complexity and cost compared to a native read replica. It also requires managing the target instance separately. The native read replica is simpler and more cost-effective.

Create an AMI of the current instance, configure an Auto Scaling group with a launch template that uses the AMI, and attach the existing EBS volume to new instances.

Why wrong: EBS volumes are AZ-specific; an EBS volume attached to an instance in one AZ cannot be attached to an instance in another AZ. This approach does not survive an AZ failure.

Create a multi-AZ Auto Scaling group and use sticky sessions (session affinity) on the ALB to tie users to specific instances.

Why wrong: Sticky sessions ensure a user is directed to the same instance, but if that instance fails, session data in memory is lost. It does not address AZ failure.

Use an Auto Scaling group in a single AZ and use a Multi-AZ RDS instance for data storage.

Why wrong: A single AZ Auto Scaling group cannot tolerate an AZ failure. Multi-AZ RDS helps with data redundancy but not compute availability.

DynamoDB Accelerator (DAX)

Why wrong: DAX is an in-memory cache that improves read performance but does not provide cross-region replication or disaster recovery capabilities.

DynamoDB Point-in-Time Recovery (PITR)

Why wrong: PITR enables restoration of a table to a point in time within the last 35 days, but recovery time is minutes to hours, and it does not provide continuous availability or global low-latency access.

DynamoDB Auto Scaling

Why wrong: Auto Scaling adjusts read/write throughput based on traffic but does not replicate data across regions or provide disaster recovery.

Weighted routing policy

Why wrong: Weighted routing distributes traffic across multiple resources according to specified weights but does not automatically failover when a resource becomes unhealthy.

Geolocation routing policy

Why wrong: Geolocation routing directs traffic based on the geographic location of the user, not for automatic failover based on instance health.

Simple routing policy

Why wrong: Simple routing policy supports only one resource per record and does not include health checks or automatic failover.

Multi-AZ deployment

Why wrong: Only protects within a single region.

Cross-region read replica

Why wrong: Typical RPO of seconds, not sub-second; manual promotion increases RTO.

Automated snapshot copy to another region

Why wrong: RPO of hours or more; RTO involves restoring which takes time.

Take daily snapshots and copy them to another region.

Why wrong: Daily snapshots have an RPO of up to 24 hours, which exceeds the required 5-minute RPO.

Use cross-region automated backups.

Why wrong: Automated backups are retained for up to 35 days and can be copied across regions, but the RPO is typically up to 15 minutes, and recovery involves restoring from a snapshot, which may take longer than 1 hour.

Deploy a second Multi-AZ DB instance in another region.

Why wrong: This creates a fully provisioned, writable standby instance that incurs costs for compute and storage, making it more expensive than a Read Replica.