High Availability practice questions

Amazon S3

Why wrong: S3 is object storage with higher latency for small objects and not ideal for frequent updates.

Amazon ElastiCache for Memcached

Why wrong: ElastiCache is for temporary caching, not durable storage.

Amazon RDS for MySQL

Why wrong: RDS is a relational database, overkill for simple config data.

Store session data in Amazon S3 with reduced redundancy.

Why wrong: S3 has higher latency and is not designed for frequent access.

Use DynamoDB with on-demand capacity.

Why wrong: DynamoDB is more expensive than ElastiCache for this access pattern.

Use ElastiCache for Memcached with multiple nodes.

Why wrong: Memcached is not durable; data is lost on node failure.

Create a manual snapshot and copy it to another Region.

Why wrong: Manual process, not automated DR.

Use S3 cross-Region replication for the database.

Why wrong: S3 replication is for S3 objects, not RDS.

Enable Multi-AZ deployment.

Why wrong: Multi-AZ provides HA within a region, not DR.

Configure the Transit Gateway to propagate routes directly between VPCs.

Why wrong: Would bypass the firewall inspection.

Use a single route table in the Transit Gateway for all VPC attachments.

Why wrong: Does not allow asymmetric routing through firewall; need separate route tables.

Increase the Auto Scaling group's desired capacity to a higher fixed value.

Why wrong: Fixed capacity may not adapt to demand; without a load balancer, traffic may not be balanced.

Switch to a different Amazon Machine Image (AMI) with optimized performance.

Why wrong: AMI change does not directly improve scalability.

Increase the instance size to a larger type.

Why wrong: Vertical scaling may not address the root cause of overload.

Amazon Redshift

Why wrong: Redshift is a data warehouse, not a transactional database.

Amazon ElastiCache

Why wrong: ElastiCache is for caching, not a primary database.

Amazon DynamoDB

Why wrong: DynamoDB is NoSQL, not relational.

Store session state in Amazon DynamoDB

Why wrong: DynamoDB is a database, not optimized for session state.

Store session state on the local instance store of each EC2 instance

Why wrong: Instance store is ephemeral and not shared.

Store session state in Amazon S3

Why wrong: S3 is object storage, not suitable for session state.

Launch all EC2 instances in a single Availability Zone.

Why wrong: Single AZ is not fault-tolerant.

Use a Network Load Balancer instead of an Application Load Balancer.

Why wrong: NLB is for TCP/UDP traffic; web app typically uses HTTP/HTTPS.

Assign Elastic IP addresses to each EC2 instance.

Why wrong: EIPs are not needed behind an ALB.

Deploy web and application servers on EC2 instances in an Auto Scaling group in one AZ. Use Amazon Route 53 latency-based routing to another region.

Why wrong: Single AZ is a single point of failure; cross-region adds complexity and latency.

Deploy web, application, and database on a single large EC2 instance in one AZ. Take snapshots every hour.

Why wrong: Single AZ does not provide high availability; snapshot recovery takes time.

Deploy web and application servers on EC2 instances in two AZs with Elastic IP addresses. Use Amazon Route 53 with health checks to route traffic.

Why wrong: Elastic IPs are not highly available; manual intervention needed for failover.

Amazon CloudFront for static content, Application Load Balancer for API, and Lambda for compute.

Why wrong: ALB is not serverless and adds cost.

AWS Lambda@Edge for both static content and API.

Why wrong: Lambda@Edge is for lightweight edge processing, not full API.

Amazon S3 for static content with Transfer Acceleration, and AWS Lambda for API.

Why wrong: Transfer Acceleration is for uploads, not global distribution.

Amazon EFS with One Zone storage classes

Why wrong: EFS One Zone is not highly available as it operates within a single Availability Zone, failing the HA requirement.

Amazon EBS with gp3 volume type

Why wrong: EBS gp3 supports only ReadWriteOnce (RWO), so it cannot be accessed by multiple pods simultaneously.

Amazon FSx for Lustre

Why wrong: FSx for Lustre is designed for high-performance compute workloads, not general-purpose shared storage for EKS.

RDS Multi-AZ in the same region

Why wrong: Multi-AZ only protects within a region, not cross-region.

Amazon S3

Why wrong: S3 is not a database DR solution.

AWS Database Migration Service

Why wrong: DMS is for migration, not continuous DR.

Amazon Redshift

Why wrong: Redshift is for data warehousing, not transactional workloads.

Amazon DynamoDB

Why wrong: DynamoDB is a NoSQL database, not relational.

Amazon ElastiCache

Why wrong: ElastiCache is for in-memory caching, not a primary database.

Amazon Redshift with concurrency scaling

Why wrong: Redshift is for analytics, not OLTP.

Amazon RDS for MySQL with Single-AZ deployment

Why wrong: Single-AZ lacks high availability; failure would cause downtime.

Amazon DynamoDB with on-demand capacity

Why wrong: DynamoDB is NoSQL, not relational.

Store session state in Amazon DynamoDB.

Why wrong: DynamoDB is durable and suitable, but for session state that can be lost, ElastiCache is more cost-effective and lower latency.

Store session state in Amazon S3.

Why wrong: S3 has higher latency and is not ideal for frequent access session state.

Store session state in Amazon EFS.

Why wrong: EFS is for file storage and has higher latency than in-memory.

Use Amazon ElastiCache to cache database query results and reduce the number of direct database connections. Keep the application on a single EC2 instance but use an Auto Scaling group with a minimum of one instance.

Why wrong: Caching may help but does not address the connection pooling issue or provide HA for the application.

Increase the connection pool size in the application configuration to handle more concurrent requests. Then deploy the application on a larger EC2 instance to handle the load.

Why wrong: Increasing pool size may lead to database resource exhaustion, and vertical scaling does not provide HA.

Migrate the application to run on AWS Lambda with a connection pool managed by the Lambda function. Use Amazon RDS Proxy to handle the database connections.

Why wrong: Lambda has limitations on long-running connections and may require significant refactoring.

Manually create EBS snapshots every day.

Why wrong: Manual snapshots are not automated and do not provide high availability.

Store data in a single Amazon S3 bucket in one Region.

Why wrong: Single Region may not be fault-tolerant.

Use a single large EC2 instance to simplify management.

Why wrong: A single large EC2 instance creates a single point of failure; if the instance fails or the underlying hardware experiences an outage, the application becomes unavailable, directly violating the requirement for fault tolerance. This option is tempting because consolidating workloads onto one large instance reduces operational overhead and licensing costs, and it would be correct for a non-critical application where simplicity and cost control are prioritised over resilience.

Deploy the API and frontend on Amazon ECS with Fargate. Use Application Auto Scaling with target tracking based on average CPU and memory utilization. Use Amazon DynamoDB for the database with on-demand capacity mode.

Why wrong: DynamoDB is not appropriate for a PostgreSQL workload; the application would require significant changes.

Deploy the API and frontend on Amazon EC2 instances behind an Application Load Balancer. Use Auto Scaling groups with dynamic scaling policies. Use Amazon RDS for PostgreSQL with Multi-AZ deployment.

Why wrong: EC2 instances require more operational overhead than Fargate; Fargate is more cost-effective for containerized workloads.

Deploy the API and frontend on Amazon ECS with Fargate. Configure a scheduled task to scale out during known promotional events. Use Amazon RDS for PostgreSQL with Multi-AZ deployment.

Why wrong: Scheduled scaling does not handle unexpected traffic spikes; manual intervention is still needed.

Amazon EFS

Why wrong: EFS is a file system, not designed for low-latency session state access.

Amazon RDS for MySQL

Why wrong: RDS is a relational database with higher latency and overhead for session state.

Amazon DynamoDB

Why wrong: DynamoDB is a NoSQL database with single-digit millisecond latency, but in-memory caching like Redis is faster for session state.

Use Amazon RDS Multi-AZ deployment in the primary Region with a standby in another Region.

Why wrong: Incorrect. Amazon RDS Multi-AZ does not support cross-Region standby; it only provides high availability within the same region. Therefore, it cannot meet the cross-Region DR requirement.

Take manual snapshots of the RDS instance every hour and copy them to another Region.

Why wrong: Incorrect. Manual snapshots taken every hour have an RPO of up to one hour, far exceeding the required 1 second RPO.

Use AWS Database Migration Service (DMS) for continuous replication to another Region.

Why wrong: AWS DMS with CDC can replicate data across Regions with low latency, but it is asynchronous and cannot guarantee a Recovery Point Objective (RPO) of 1 second. Therefore, it does not meet the strict RPO requirement.

Configure cross-Region read replicas for RDS MySQL.

Why wrong: Incorrect. Cross-Region read replicas for RDS MySQL use asynchronous replication, so the RPO is not guaranteed to be 1 second. Additionally, promoting a read replica to a primary instance is a manual process that typically takes longer than 1 minute, failing the RTO requirement.