Select Two (Multi-Select) Questions

Replace the API fleet with Dedicated Hosts to lock in lower rates.

Why wrong: Incorrect. Dedicated Hosts are primarily for licensing or isolation requirements, not cost reduction. They are usually more expensive and do not solve the cost problem for a steady web API.

Buy Standard Reserved Instances for the batch workers and keep them running 24/7.

Why wrong: Incorrect. Reserved Instances assume predictable long-running usage, but the batch workers are mostly idle. Paying for always-on capacity defeats the purpose of cost optimization for this workload.

Increase the worker Auto Scaling minimum to prevent Spot interruptions.

Why wrong: Incorrect. Raising the minimum keeps more capacity running continuously and increases cost. It also does not eliminate Spot interruptions, so it undermines the savings goal.

Keep a fixed fleet of m6i.large instances in an Auto Scaling group with a higher minimum.

Why wrong: Incorrect. A higher minimum keeps capacity running even when the queue is empty, so idle cost remains high. It also does not provide the burst efficiency that queued, event-driven processing gives you.

Use Reserved Instances for the workers even though demand is highly bursty.

Why wrong: Incorrect. Reserved Instances work best for stable, predictable utilization. Bursty workers would leave committed capacity unused much of the time, which wastes money.

Process uploads only during a nightly window so the fleet looks busier.

Why wrong: Incorrect. Batch scheduling may reduce perceived complexity, but it increases latency and does not inherently reduce compute cost if the same amount of work must still be done.

Use weighted routing with a 50/50 traffic split between both Regions.

Why wrong: Weighted routing distributes traffic, but it does not automatically fail over based on endpoint health.

Use latency-based routing so clients always choose the fastest Region.

Why wrong: Latency-based routing optimizes performance, but it is not the same as primary-secondary failover behavior.

Use a geolocation policy without health checks.

Why wrong: Geolocation routes by user location and still requires additional health-aware design for automatic failover.

Convert the database to a single-AZ deployment for faster restores.

Why wrong: Converting an RDS instance to a single-AZ deployment offers no benefit for recovering from data corruption and actively reduces database availability. While it might slightly reduce operational costs, it eliminates the high availability and automatic failover capabilities provided by Multi-AZ deployments. This change does not alter the underlying mechanism of Point-in-Time Recovery, which relies on automated backups and transaction logs, making it irrelevant for data integrity restoration.

Delete the corrupted rows manually and continue without restoring.

Why wrong: Manually deleting corrupted rows is an extremely risky and unreliable approach for recovering from data corruption in a production environment. This method is highly prone to human error, potentially missing related data, orphaned records, or application-level inconsistencies that a full restore would resolve. A manual cleanup fails to guarantee a return to a known-good state, which is the primary objective when recovering from data integrity issues.

Use a read replica as the only recovery source for all deletions.

Why wrong: An Amazon RDS read replica is primarily designed for read scaling and offloading read traffic from the primary database, not for point-in-time data recovery from corruption. While a read replica maintains a copy of the data, it replicates changes from the primary instance, including corruption, making it an unsuitable source for restoring to a clean state. It cannot provide the granular, precise timestamp recovery capabilities that automated backups and Point-in-Time Restore offer for data integrity issues.

Increase the size of the S3 bucket’s underlying storage to absorb more origin traffic.

Why wrong: S3 storage capacity does not affect cache key design or CloudFront reuse. The problem is request variation, not insufficient bucket storage. Increasing storage size will not raise the cache hit ratio or reduce repeated origin requests.

Add Lambda@Edge logic to append a timestamp to every asset request so updates are always fetched immediately.

Why wrong: Appending a timestamp intentionally destroys cacheability by making every request unique. That approach may force freshness, but it worsens hit ratio and increases origin traffic. It is the opposite of what a high-performing static asset design should do.

Disable compression so CloudFront can treat each object as a separate cache entry.

Why wrong: Compression does not control cache-key fragmentation in a useful way here. Disabling compression can actually hurt transfer efficiency and does not address the excessive variation caused by headers, cookies, and query strings. The origin request pattern would remain inefficient.

Buy Standard Reserved Instances only for the nightly analytics batch job.

Why wrong: Reserved Instances are a poor fit for interruptible batch jobs because the job may not run continuously enough to benefit from a reservation. The workload can tolerate interruption, so committing to fixed capacity usually wastes money compared with more flexible pricing.

Move the entire workload to On-Demand Instances for maximum flexibility.

Why wrong: On-Demand offers flexibility, but it is not the lowest-cost option for a steady baseline or for interruption-tolerant processing. The scenario specifically asks to minimize monthly cost, so paying full On-Demand rates for everything is unnecessary.

Use Dedicated Hosts for the batch job so the fleet is isolated.

Why wrong: Dedicated Hosts are typically chosen for licensing or compliance isolation requirements, not for minimizing cost. They are usually more expensive than other EC2 purchase options and do not add value to a checkpointed batch workload.

Reduce the visibility timeout so failed messages return to the queue faster.

Why wrong: Incorrect. Reducing visibility timeout speeds up redelivery, but it does not prevent duplicate business actions and can actually increase replay pressure. The core problem is that the payment operation must tolerate retries, and poison messages need a separate failure path.

Run only one long-lived worker instance so the queue can never be processed twice.

Why wrong: Incorrect. A single worker reduces availability and still does not guarantee exactly-once processing, because SQS can redeliver messages after a timeout or failure. This approach makes the system less resilient and creates a single point of failure.

Switch from a standard queue to a FIFO queue and remove all other changes.

Why wrong: Incorrect. FIFO queues help preserve order within a message group, but they do not remove the need for idempotent processing if the consumer times out after a partial success. They also do not replace the need for a dead-letter queue for messages that will never validate successfully.

Convert the cluster to a single-AZ RDS MySQL instance to reduce replication overhead.

Why wrong: This would remove Aurora’s read-scaling architecture and reduce availability. A single-AZ instance also concentrates all traffic on one node, which is the opposite of what this workload needs. It may reduce replication complexity, but it does not increase read throughput.

Replace the writer endpoint with the instance endpoint of the primary node to speed up SELECT queries.

Why wrong: The primary writer is already the bottleneck in the scenario. Sending more SELECT traffic to the writer endpoint or its instance endpoint increases contention on the busiest node and does not add any new read capacity. That choice worsens the current CPU imbalance.

Add Amazon ElastiCache and move all database writes into the cache layer.

Why wrong: A cache can offload some read traffic, but it is not a substitute for the database for transactional writes. Moving writes into a cache layer would break durability and consistency guarantees. The question asks for a direct Aurora read-scaling fix without schema redesign, so replica-based scaling is the right approach.

Restore the most recent manual snapshot because it will include the 10:30 UTC state.

Why wrong: Incorrect. A snapshot only captures the database state at the moment the snapshot was taken, so it cannot reliably recreate an arbitrary time such as 10:30 UTC unless that exact snapshot happened then. The correct tool for restoring to a specific time is point-in-time restore.

Overwrite the existing database instance in place so the application keeps the same storage volume.

Why wrong: Incorrect. In-place recovery is riskier because it can make rollback difficult if the restore does not produce the expected data set. AWS RDS point-in-time restore is designed to create a new instance, which lets the team validate the data before changing production traffic.

Wait for automated backups to complete again, then replay the migration to restore the missing rows.

Why wrong: Incorrect. Waiting for another backup does not recover the lost state, and replaying the migration can reapply the corruption or introduce additional inconsistency. The problem is a known bad change, so the correct response is to restore to a known-good time before that change.

Increase the Lambda timeout so the function has more time to initialize during the spike.

Why wrong: A longer timeout does not remove cold starts or pre-initialize execution environments. It only changes how long a function may run before timing out. The user-facing latency issue would remain, so this does not solve the core problem.

Double the memory size during the spike without changing the concurrency model.

Why wrong: More memory can improve CPU allocation and sometimes reduce execution duration, but it does not guarantee that the environment is already warm. Without provisioned concurrency, the first requests can still incur cold-start penalties. The scenario specifically calls for stable p95 latency.

Move the function into more Availability Zones so the platform can spread cold starts across regions.

Why wrong: Lambda already runs as a managed regional service and does not need the customer to place individual functions across AZs. Spreading across AZs does not eliminate cold starts. The issue is initialization time, not geographic distribution.

Put the service behind API Gateway REST API and use Lambda integration.

Why wrong: API Gateway is designed for API requests, not arbitrary custom binary TCP sessions. It would not preserve the required protocol semantics or satisfy the static allowlisting requirement for this use case. It is the wrong abstraction for raw TCP traffic.

Use CloudFront to cache the binary packets at edge locations.

Why wrong: CloudFront is optimized for HTTP and HTTPS content delivery and caching, not for arbitrary TCP application protocols. It does not solve static IP allowlisting or source-IP preservation for a custom binary service. Caching is irrelevant to the described workload.

Terminate the traffic with an Amazon RDS proxy to stabilize the connections.

Why wrong: RDS Proxy is for database connection management, not for fronting a TCP application service. It has no role in preserving source IP for a custom binary protocol or in providing allowlisted endpoint addresses. This is a mismatch to the workload.

Store the data in Amazon S3 Glacier Deep Archive immediately after creation.

Why wrong: Storing data directly in S3 Glacier Deep Archive upon creation is generally not cost-optimized if there's any chance of initial access. This storage class is designed for long-term archives with retrieval times measured in hours and incurs significant retrieval costs, making it unsuitable for data that might be accessed even infrequently in its early lifecycle.

Store all data in Amazon EBS gp2 volumes attached to an EC2 instance for low-latency access.

Why wrong: Storing large datasets on EBS gp2 volumes attached to an EC2 instance is not a cost-optimized solution for general data storage. EBS is block storage designed for single-instance, low-latency application needs, not scalable object storage. It incurs EC2 compute costs and is significantly more expensive per GB than S3 for large, infrequently accessed datasets, lacking S3's inherent durability and scalability.

Replicate all data to a second AWS Region using S3 Cross-Region Replication to ensure durability.

Why wrong: While S3 Cross-Region Replication (CRR) enhances disaster recovery capabilities by providing a copy in a separate geographical region, S3 Standard already offers 11 nines of durability within a single region. Replicating all data to a second region solely for "durability" is redundant and doubles storage costs, making it an inefficient and non-cost-optimized approach when S3's inherent durability is already extremely high.

Amazon RDS for MySQL with Multi-AZ and Read Replicas.

Why wrong: Amazon RDS for MySQL, while offering high availability with Multi-AZ and improved read scalability with Read Replicas, is a relational database. For extremely high-performance e-commerce with massive scale and rapidly evolving data models, the inherent limitations of a fixed schema and the complexities of scaling writes in a relational database may not meet the most stringent low-latency, high-throughput requirements compared to a purpose-built NoSQL solution.

Amazon S3 as a primary data store accessed via Select and Range queries.

Why wrong: Amazon S3 is an object storage service primarily designed for durability, availability, and cost-effectiveness for unstructured data, not as a transactional primary database. While S3 Select allows querying data within objects and range queries can retrieve parts of objects, its latency profile and access patterns are fundamentally unsuitable for the real-time, low-latency, high-throughput transactional reads and writes required by a primary e-commerce database.

Amazon Redshift with auto-scaling for real-time reads.

Why wrong: Amazon Redshift is a fully managed, petabyte-scale data warehouse service optimized for complex analytical queries over large datasets, not for real-time operational reads and writes. Its architecture is geared towards batch loading and analytical processing, making it an inappropriate choice for the low-latency, high-concurrency transactional demands of a primary e-commerce database that requires immediate data access and modification.

Place the EC2 instances in a single Availability Zone to reduce network latency.

Why wrong: Placing EC2 instances in a single Availability Zone (AZ) would indeed minimize intra-AZ network latency between instances, but it critically compromises the application's high availability and fault tolerance. A high-performance web application requires resilience against AZ-level failures, which multi-AZ deployments provide. Furthermore, the primary latency concern for a web application is typically user-to-server latency, which is better addressed by edge caching or network optimization services rather than restricting compute to a single AZ.

Enable S3 Transfer Acceleration on the bucket for faster downloads.

Why wrong: S3 Transfer Acceleration is designed to speed up uploads of data to an S3 bucket from clients located far from the bucket's region, by routing the data through CloudFront edge locations. While it uses the CloudFront network, its primary benefit is for ingress (uploads) to S3, not for accelerating downloads of web application content served by EC2 instances or CloudFront itself. For faster downloads of web content, CloudFront is the appropriate service.

Use an Amazon RDS Multi-AZ database for read replicas to offload read traffic.

Why wrong: An Amazon RDS Multi-AZ deployment provides high availability and automatic failover for a database by synchronously replicating data to a standby instance in a different Availability Zone. However, the standby instance is not used for read traffic. To offload read traffic from the primary database and improve read performance and scalability, Amazon RDS Read Replicas are required. This option incorrectly conflates the high availability feature of Multi-AZ with the read scaling capability of read replicas.

Place all ECS tasks in a single subnet to minimize network latency.

Why wrong: Placing all ECS tasks within a single subnet severely compromises the application's fault tolerance and availability. While it might marginally reduce network latency between tasks, this configuration creates a single point of failure; an outage affecting that specific subnet or its Availability Zone would render the entire application inaccessible. Best practices for resilient cloud deployments mandate distributing resources across multiple subnets in distinct Availability Zones.

Store application session data in an attached EFS file system shared across all tasks.

Why wrong: Storing application session data in an attached EFS file system contradicts the principle of a stateless web application, which should not maintain session state on the compute layer. Furthermore, EFS is a shared file system primarily designed for persistent storage, not optimized for high-performance session management. For stateful applications requiring session persistence, external, highly available services like Amazon ElastiCache or Amazon DynamoDB are more appropriate and performant.

Disable automatic task replacement to avoid unnecessary task churn during failures.

Why wrong: Disabling automatic task replacement for an ECS service would severely undermine the application's resilience and availability. This critical feature ensures that unhealthy or failed tasks are automatically stopped and replaced with new, healthy ones, maintaining the desired task count and service capacity. Without automatic replacement, task failures would lead to a permanent reduction in application capacity and potential service outages, requiring manual intervention.

Deploy the Aurora cluster with a single DB instance to reduce complexity and cost.

Why wrong: Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.

Place the EC2 instances in a single Availability Zone to ensure data locality with the primary database.

Why wrong: Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.

Provision additional EC2 instances to handle peak load at all times, ensuring maximum performance.

Why wrong: Provisioning additional EC2 instances to handle peak load at all times is an inefficient and costly approach. This strategy leads to significant over-provisioning during off-peak periods, where a large portion of the allocated resources remains idle and unused. Consequently, the company incurs unnecessary expenses for compute capacity that is not actively contributing to workload performance, directly contradicting cost optimization goals.

Store all data in Amazon S3 Standard storage class to avoid any data retrieval costs.

Why wrong: Storing all data exclusively in Amazon S3 Standard storage class is not an optimal cost-saving strategy, as S3 Standard does incur data retrieval costs, albeit typically lower than other classes for frequent access. For data that is accessed less frequently or archived, using lifecycle policies to transition objects to S3 Infrequent Access, Glacier, or Glacier Deep Archive would yield significant storage cost reductions, despite potentially higher retrieval fees or longer retrieval times.

Deploy all resources in a single Availability Zone to minimize data transfer costs.

Why wrong: Deploying all resources within a single Availability Zone (AZ) to minimize data transfer costs is a critical misstep for production workloads. While it might reduce cross-AZ data transfer charges, this approach creates a single point of failure, severely compromising the application's high availability and fault tolerance. The potential cost savings are far outweighed by the increased risk of downtime and data loss in the event of an AZ-wide outage.

Disable CloudTrail logging

Why wrong: Disabling audit logging is not a storage cost optimization for EBS and weakens governance.

Stop all EC2 instances in the account

Why wrong: Stopping instances does not remove EBS volume or snapshot charges.

Global secondary indexes

Why wrong: GSIs support query access patterns but do not protect against data loss.

DAX

Why wrong: DAX improves read performance but does not provide recovery.

Use a single EBS Multi-Attach volume mounted read/write by all instances across AZs.

Why wrong: EBS Multi-Attach is not a general-purpose multi-AZ shared filesystem for application servers. It has service limitations and is not the correct service for many instances requiring concurrent shared file access across AZs. EFS is the AWS-managed option designed for this use case.

Store the files in S3 and mount them directly through the console as a shared network filesystem.

Why wrong: S3 is object storage, not a native shared filesystem with standard POSIX semantics. It does not provide the same low-latency metadata behavior or filesystem-level concurrent read/write model that application servers expect. This option does not satisfy the workload requirements.

Place the files on instance store volumes so each server has faster local access.

Why wrong: Instance store is local to a single EC2 instance and is ephemeral. That means each server would have its own isolated copy of the data, which breaks the requirement for a shared filesystem across multiple instances. It also risks data loss if an instance stops or terminates.