Select Two (Multi-Select) Questions

Purchase an All Upfront Reserved Instance for the transcoding fleet only.

Why wrong: Reserved Instances fit steady, predictable usage, but this batch fleet is interruption-tolerant and variable.

Increase the API instance size so CPU utilization stays below 30 percent.

Why wrong: Larger instances raise cost; right sizing should reduce waste, not add extra unused capacity.

Move the API tier to Dedicated Hosts to improve isolation and lower spend.

Why wrong: Dedicated Hosts usually increase cost and are used for licensing or compliance, not savings.

Add an internet gateway and move the instances into public subnets.

Why wrong: This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.

Replace the NAT Gateway with a Site-to-Site VPN connection.

Why wrong: A VPN is meant for connectivity to on-premises or external networks. It does not eliminate the need to reach S3 and DynamoDB privately, so it does not directly solve the NAT data-processing-cost problem.

Create an interface endpoint for S3 instead of a gateway endpoint.

Why wrong: An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.

Increase the size of the S3 bucket.

Why wrong: Bucket size does not improve cache reuse or reduce request costs. The issue is cacheability, not storage capacity.

Place an Application Load Balancer in front of S3.

Why wrong: An ALB is not used as a front end for static S3 content in this pattern. It adds unnecessary infrastructure and does not address the cache key problem.

Disable caching so clients always get the latest files.

Why wrong: Disabling caching guarantees more origin traffic and higher cost. The deployment already uses versioned assets, so cache efficiency should increase rather than disappear.

Switch from SQS to Amazon SNS for reliable buffering.

Why wrong: SNS is a pub/sub notification service, not a durable work queue for buffering and retrying tasks. It does not provide the same queue semantics as SQS for worker processing.

Shorten the queue retention period so messages expire quickly.

Why wrong: Reducing retention does not prevent duplicates. It increases the chance of message loss if workers are unavailable long enough for messages to expire before processing completes.

Disable retries in the consumer application.

Why wrong: Retries are often necessary for transient failures such as throttling or brief downstream outages. Disabling retries makes the system less resilient and can turn temporary problems into permanent data loss.

Use an S3 bucket as the backing store because object storage scales automatically.

Why wrong: S3 is object storage, not block storage. It does not provide the low-latency random write behavior required by a database cache or similar block-based workload.

Choose a cold HDD-based volume so the cache has durable low-cost storage.

Why wrong: Cold HDD volumes are optimized for low cost, not for high IOPS or latency-sensitive random access. They are a poor fit for a cache or database-like workload.

Use the root volume from a T-series instance because burst credits can absorb the write spikes.

Why wrong: Burst credits do not provide the sustained, predictable IOPS needed for a latency-sensitive cache. T-series instances are designed for short CPU bursts, not for high-performance storage workloads.

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.

Place a NAT gateway in the public subnet so the private instances can reach AWS services.

Why wrong: A NAT gateway sends outbound traffic to the internet and adds cost and exposure that the requirement explicitly forbids. It is not a private-only connectivity solution.

Assign public IPv4 addresses to the instances and restrict them with security groups.

Why wrong: Public IPs contradict the requirement to stay private and do not remove internet exposure. Security groups alone do not make a workload private.

Use VPC peering to the AWS service endpoints instead of VPC endpoints.

Why wrong: VPC peering is for connectivity between VPCs, not for reaching managed AWS service endpoints. It is not the right mechanism for private service access.

Keep the files in S3 Standard indefinitely so retrieval is always fast.

Why wrong: S3 Standard provides fast access, but it is unnecessarily expensive for multi-year retention of footage that is rarely needed.

Copy the files to a single EBS volume for lower per-GB cost.

Why wrong: EBS is block storage and is not suitable for massive archival libraries with lifecycle and retention requirements like these.

Point all queries to the writer endpoint so Aurora can balance reads and writes internally.

Why wrong: The writer endpoint is intended for writes and for transactional work that must go to the primary instance. Sending all reads there concentrates load on the primary and reduces the benefit of replicas.

Enable Multi-AZ standby for the cluster to increase the number of read-only connections.

Why wrong: Aurora Multi-AZ is about availability and failover, not extra read scaling. A standby or passive component does not provide the same read capacity as adding active replicas.

Move the database to a single larger instance class instead of adding replicas.

Why wrong: A larger instance may improve the performance of one node, but it does not provide the horizontal scaling needed for a read-heavy workload. The question asks for more read throughput without changing the application design, which is exactly what replicas and the reader endpoint provide.

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.

Deploy a NAT Gateway in each Availability Zone and route artifact traffic through it.

Why wrong: A NAT Gateway would work for connectivity, but it creates exactly the cost the team wants to remove. The gateway endpoint is the cost-optimized private option.

Use the S3 static website endpoint because it automatically enforces HTTPS.

Why wrong: S3 website endpoints are not the right choice for private CI uploads and do not provide the required transport and encryption controls. They are intended for public website hosting patterns.

AWS Organizations service control policies

Why wrong: SCPs enforce permissions and do not provide regional failover.

S3 Transfer Acceleration

Why wrong: Transfer Acceleration improves upload paths to S3 but does not provide application failover.

DAX

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

Global secondary indexes

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

Increase the instance size so each server can handle more traffic alone.

Why wrong: A larger instance may improve capacity, but it does not protect against an Availability Zone failure. If the Zone goes down, all instances in that Zone are still lost regardless of their size.

Disable ALB health checks so instances stay registered longer.

Why wrong: Health checks are useful for removing unhealthy targets quickly. Disabling them would make failover and recovery worse because the load balancer could keep sending traffic to broken instances.

Run the whole stack in one Availability Zone for simpler networking.

Why wrong: A single Availability Zone creates a clear single point of failure. Simplicity may be appealing, but it does not meet the goal of surviving a Zone outage.

Store the password in a plain environment variable and update it manually during maintenance windows.

Why wrong: Plain environment variables are easy to expose through logs, crash dumps, or operator mistakes. Manual updates also create avoidable downtime and operational drift.

Use an IAM user access key inside the container so the database password can be embedded in code.

Why wrong: IAM users and embedded credentials are long-lived and difficult to control safely. They are not appropriate for ephemeral workloads that should use task roles instead.

Spread the instances across three Availability Zones for better fault tolerance.

Why wrong: Spreading across AZs improves resilience, but it increases network distance and typically adds latency. The scenario is explicitly about minimizing jitter and latency for frequent east-west traffic within one AZ, so multi-AZ spread is the wrong optimization.

Front the nodes with an Application Load Balancer to balance the internal messages.

Why wrong: An ALB is for HTTP/HTTPS application traffic, not for direct node-to-node messaging performance. It adds a layer that does not solve the underlying east-west latency issue. The workload needs closer physical placement and better networking, not a web load balancer.

Store the messages on EBS volumes so the nodes avoid network communication.

Why wrong: EBS is block storage for persistent data, not a low-latency message bus. Writing messages to disk would add storage latency and does not create efficient inter-node communication. It also changes the workload architecture in an unsupported way for this requirement.

A memory-optimized family, because extra RAM always increases compute throughput.

Why wrong: Memory-optimized instances help when memory is the bottleneck, such as large in-memory databases or caching layers. They do not automatically improve a CPU-bound rendering workload.

A storage-optimized family, because local storage bandwidth is the main factor for rendering performance.

Why wrong: Storage-optimized families are useful when disk throughput or IOPS are the bottleneck. This scenario states that the workload is CPU-bound, so storage optimization is not the primary concern.

A burstable family, because CPU credits make sustained rendering faster during long runs.

Why wrong: Burstable instances are meant for baseline workloads with occasional CPU spikes. They are not a good fit for sustained batch rendering, where predictable CPU performance matters more than burst credits.

Keep sending all traffic to the writer endpoint because it always has the freshest data.

Why wrong: Incorrect. Although the writer has the most recent committed data, forcing all reads through it creates a bottleneck and defeats Aurora's read-scaling design. A reader endpoint is the appropriate choice for read traffic.

Replace Aurora with a single larger RDS instance and continue using the same read pattern.

Why wrong: Incorrect. A larger single instance may provide more CPU or memory, but it still concentrates reads and writes on one node and does not provide the same horizontal read scaling or failover abstraction as Aurora replicas and cluster endpoints.

Move PostgreSQL to Amazon DynamoDB without redesigning the application.

Why wrong: DynamoDB is a different database model and is not a drop-in replacement for PostgreSQL. Using it would require significant application and data-model changes, so it does not fit the goal of a low-friction cost and operations improvement.

Replace RabbitMQ with another EC2-based broker cluster for more control.

Why wrong: This keeps the same operational burden because the team still has to patch, back up, and scale the broker infrastructure. More control is not the same as lower cost or lower management overhead.

Keep the same design and increase instance sizes to simplify maintenance.

Why wrong: Larger instances may temporarily reduce tuning pressure, but they do not remove the operational work of managing a database and broker. The scenario is about reducing self-managed infrastructure overhead, not only increasing raw capacity.

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

Why wrong: Single-AZ does not improve restoration from data corruption. It removes high availability and does not change the mechanics of point-in-time recovery.

Delete the corrupted rows manually and continue without restoring.

Why wrong: Manual cleanup is error-prone and may miss related changes, orphaned rows, or application-level side effects. The requirement is to return to a known-good point in time, which restore achieves more reliably.

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

Why wrong: A read replica is meant for read scaling and reporting, not as the primary mechanism for exact point-in-time recovery. It may not provide the precise recovery point needed for this incident.