Select Two (Multi-Select) Questions

Internet gateway attached to the VPC

Why it fails: An internet gateway only enables public IPv4 connectivity for resources with public addresses; private subnets have no route to it, so S3 and Parameter Store traffic cannot traverse it. It is tempting because it is the standard egress path for public subnets, and would be correct if the instances held Elastic IPs and the requirement permitted internet routing.

NAT gateway in each Availability Zone

Why it fails: A NAT gateway routes traffic to the public internet via an internet gateway, which the stem explicitly forbids; it also cannot reach S3 or Parameter Store without public endpoints. It is tempting because NAT gateways are the usual answer for private-subnet egress, and would be correct if outbound internet access were permitted.

Disable CloudTrail logging

Why it fails: Disabling CloudTrail logging is unrelated to EBS storage cost optimization because CloudTrail records API activity and does not manage or reduce the storage footprint of EBS volumes or snapshots. Doing so actually degrades governance and audit compliance, making it harder to identify who created or deleted orphaned volumes, which is the opposite of the careful, verifiable cleanup this scenario requires.

Stop all EC2 instances in the account

Why it fails: Stopping all EC2 instances halts instance compute charges, but it does not remove the underlying EBS volume storage fees: every volume remains allocated and billed per GB-month regardless of whether the instance is running or stopped. Moreover, this action is overbroad because not all instances necessarily have unnecessary EBS usage, and it fails to address separate snapshot costs that accumulate independently of instance state.

Internet gateway attached to the VPC

Why it fails: An internet gateway is a horizontally scaled, redundant component that enables communication between a VPC and the public internet. It is not used by private subnets because private subnets have no route to an internet gateway, and even if one were added, traffic would traverse the public internet and not be private. Internet gateways also do not provide private connectivity to AWS services, so this option cannot satisfy the requirement.

NAT gateway in each Availability Zone

Why it fails: A NAT gateway allows instances in private subnets to initiate outbound internet traffic, but it does so by routing packets through the internet gateway to the public internet. For private access to Systems Manager, this would mean traffic leaving the AWS network and traveling over public infrastructure, violating the requirement for private connectivity. Additionally, NAT gateways incur hourly charges and data processing fees, and they are not designed as a private endpoint service.

Attach an IAM policy in Account B that grants s3:* on the bucket and its objects.

Why it fails: An identity policy in Account B alone cannot authorize access to a bucket in another account. S3 also requires a matching resource policy or equivalent cross-account trust, and broad s3:* is unnecessary for least privilege.

Create an S3 gateway endpoint in Account B so the application can reach the bucket privately.

Why it fails: An S3 gateway endpoint is a networking feature that provides private connectivity from Account B's VPC to S3, but it does not grant any data-plane authorization. The AccessDenied error occurs because the bucket policy and KMS key policy in Account A do not yet permit the external role, not because traffic traverses the public internet. Even with the endpoint configured, S3 will still evaluate the bucket policy and KMS key policy and deny the request if the role lacks s3:GetObject and kms:Decrypt permissions, so this option does not address the root cause.

Add an SCP in Account A that allows the Account B role to bypass KMS encryption checks.

Why it fails: Service control policies (SCPs) are guardrails applied at the AWS Organizations account or OU level that limit the maximum permissions for principals within that account; they can only restrict, never grant, permissions to an external role. An SCP in Account A cannot authorize an Account B role to bypass KMS encryption checks because KMS decisions are always governed by the key policy in Account A, and SCPs do not override that policy. To fix the encryption failure, the Account B role must be explicitly added to the KMS key policy with kms:Decrypt, alongside the bucket policy for s3:GetObject, so this option is both conceptually and technically incorrect.

Global secondary indexes

Why it fails: Global secondary indexes (GSIs) are maintained as copies of a DynamoDB table's data reorganized around an alternative partition and sort key so that you can run fast queries on non-primary attributes. They offer no resilience or recovery capabilities; they are stored as part of the same table's physical infrastructure, and when the base table is dropped the GSIs disappear with it. They solve access-pattern problems, not durability or availability problems.

DAX

Why it fails: DAX (DynamoDB Accelerator) is an in-memory write-through cache that offloads repeated reads from the underlying table, cutting read latency to microseconds for hot keys. It holds data transiently and is not a durable, independently restorable store; a cached item can be stale, and if the source table is corrupted or deleted, DAX only propagates the loss or continues serving cached values that no longer exist. It is a performance optimization, not a point-in-time recovery mechanism.

Switch from SQS to Amazon SNS for reliable buffering.

Why it fails: Amazon SNS is a publish/subscribe notification service that immediately pushes messages to all active subscribers; it does not provide durable message buffering or queue semantics. SNS does not retain messages when there are no subscribers, does not allow consumers to poll for messages at their own pace, and lacks visibility timeouts or per-message lifecycle controls. Therefore, switching to SNS would remove the buffering capacity that SQS provides and would increase the chance of message loss, not prevent duplicate processing. SQS remains the appropriate service for reliable work queues where messages must persist until processed and deleted.

Shorten the queue retention period so messages expire quickly.

Why it fails: The queue retention period defines how long a message remains in the queue if it is not deleted by a consumer, typically ranging from 1 minute to 14 days. Shortening this period does not affect the at-least-once delivery behavior of SQS; duplicates can still occur as long as a message exists. Worse, a shortened retention period increases the risk that valid messages expire before a consumer can process them, especially during a prolonged outage or a backlog. This approach not only fails to address duplicate deliveries but also makes the system less reliable, as it can lead to permanent message loss.

Disable retries in the consumer application.

Why it fails: Disabling retries in the consumer application is a flawed response to duplicate messages because retries are essential for handling transient failures like temporary network blips, throttling limits, or brief downstream service outages. Without retries, a single temporary error causes the message to remain unprocessed and eventually be redelivered by SQS, so the underlying problem is not solved; instead, the message may ultimately be lost if the consumer gives up permanently. SQS itself relies on consumers to retry and delete messages after successful processing, and disabling application-level retries makes the workload more brittle, not less. The correct strategy is to keep retries for transient failures and use idempotent processing to safely handle any duplicates that result from those retries.

Stop all EC2 instances in the account

Why it fails: Stopping all EC2 instances does not reduce EBS storage costs because the underlying block storage volumes remain allocated and continue to incur per-GB-month charges independent of the instance state. Moreover, stopping instances does nothing to delete old snapshots, which are billed separately, and it unnecessarily disrupts production workloads if any are still running. A targeted approach is to identify and delete only unused volumes and snapshots.

Disable CloudTrail logging

Why it fails: Disabling CloudTrail logging is not a storage cost optimization for EBS because CloudTrail records API activity and its costs are unrelated to volume or snapshot storage. Even with CloudTrail disabled, unattached volumes and stale snapshots continue to accrue charges at the same rate. Disabling auditing also weakens your governance and security posture, potentially masking unapproved API calls or resource deletions, and it fails to address the actual drivers of EBS cost.

Stop all EC2 instances in the account

Why it fails: Stopping EC2 instances only transitions them to a stopped state; the underlying EBS volumes remain attached to the instance and continue to incur per-GiB-month charges. To eliminate storage costs, you must either detach and delete the volumes or terminate the instance with the 'Delete on Termination' flag set for root volumes. Simply stopping an instance does not remove volume or snapshot charges, so this option fails to address the stated storage cost issue.

Disable CloudTrail logging

Why it fails: Disabling CloudTrail logging would stop recording API activity, but it does nothing to reduce EBS volume or snapshot storage fees, which are billed based on allocated capacity and snapshot data. Audit logs are not part of the EBS storage footprint; turning them off only weakens your ability to detect unauthorized configuration changes and compromises security posture, making it a counterproductive optimization that sacrifices governance without saving storage costs.

AWS Organizations service control policies

Why it fails: SCPs govern maximum permissions for accounts in an organisation; they cannot detect endpoint health or trigger cross-Region failover. They are tempting because they enforce guardrails centrally, which is the right tool for restricting services across accounts, not for resilience routing.

S3 Transfer Acceleration

Why it fails: S3 Transfer Acceleration speeds uploads to a bucket via edge locations; it neither monitors endpoint health nor redirects traffic between Regions. It is tempting for globally distributed uploads where latency, not failover, is the design driver.

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

Why it fails: A NAT gateway routes traffic through the public subnet and the internet, giving instances public-facing egress and contradicting the requirement to avoid both. It is tempting because NAT gateways commonly grant private-subnet access to AWS services, and would be correct if internet egress were permitted.

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

Why it fails: Public IPv4 addresses expose the instances to the internet and route S3 and Secrets Manager traffic over public endpoints, breaching the no-public-IP requirement. It is tempting because security groups can restrict inbound access, and would be correct if internet-based access with tight filtering were acceptable.

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

Why it fails: VPC peering connects VPCs to each other, not to AWS service endpoints, and S3 and Secrets Manager are not reachable through a peering connection. It is tempting because peering keeps traffic on the AWS backbone, and would be correct for private connectivity between two customer VPCs.

Use AWS Systems Manager Parameter Store with SecureString parameters and manually update the credentials every 90 days.

Why it fails: Parameter Store SecureString can store encrypted values, but it does not provide built-in automatic rotation for database credentials. Manual updates do not meet the automatic rotation requirement. While it integrates with IAM, it lacks the rotation feature of Secrets Manager. This option adds manual effort and risk of stale credentials.

Store the database credentials in an encrypted Amazon S3 object and grant the EC2 instance role access to read the object.

Why it fails: Storing credentials in an S3 object does not provide automatic rotation or a managed secret lifecycle. It also requires custom code to read and parse the object. While S3 can be encrypted, it is not the appropriate service for secret management. This approach fails the automatic rotation requirement and adds operational overhead.

Embed the database credentials in the EC2 user data script and encrypt the script with AWS KMS.

Why it fails: Embedding credentials in user data, even encrypted, still exposes them in the instance metadata and launch configuration. User data is not a secure secret store and does not support automatic rotation. This approach violates the requirement to avoid hardcoding credentials. It also creates operational risk if the script is accessible.

Migrate to DynamoDB immediately because every relational workload is more expensive.

Why it fails: DynamoDB is non-relational, so the reporting application's SQL joins and schema would need rewriting, which the business explicitly excluded. It is tempting because DynamoDB removes server management and scales elastically, making it the right choice for new key-value or document workloads with known access patterns.

Increase provisioned IOPS permanently so the monthly bill drops.

Why it fails: Raising provisioned IOPS permanently increases the hourly storage charge, so the bill rises rather than falls. It is tempting because IOPS tuning genuinely fixes throttling on steady high-throughput databases, making it correct when sustained I/O demand, not a three-hour daily peak, drives performance.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: Memory-optimized families like the R5 or X2gd are built for workloads that need to hold large datasets in RAM, such as in-memory databases or real-time analytics, not for tasks that are compute-constrained. Adding extra RAM to a CPU-bound rendering job does not reduce the time spent on CPU calculations, because memory capacity is not the limiting factor. Choosing one of these instances would overprovision memory, increasing costs while providing no measurable rendering performance benefit.

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

Why it fails: Storage-optimized instances (e.g., I3en, D2) prioritize high random I/O performance, ephemeral NVMe storage, and large data throughput, making them suitable for data-heavy workloads like Hadoop clusters or log processing. In this scenario, the batch rendering service is CPU-bound, meaning disk throughput is not the bottleneck, and a high-I/O instance will not accelerate the CPU calculations. Therefore, a storage-optimized family would incur unnecessary cost for storage resources that remain idle.

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

Why it fails: Burstable instances (T3, T4g) are designed for workloads with a modest baseline CPU level and occasional spikes, using CPU credits to support short-term bursts. Sustained rendering workloads need constant, predictable CPU performance; once credits are exhausted, the instance is throttled to the baseline, causing slower render times and unstable batch completion durations. This makes the burstable family unsuitable for a CPU-bound service that runs continuously, where compute-optimized or Graviton-based instances are more appropriate.

Create a DynamoDB global secondary index on the partition key used by the tracking queries and project all attributes into the index.

Why it fails: A global secondary index improves query flexibility and can serve different access patterns, but it is not a backup mechanism and provides no delete protection. Because the index depends on the base table, deleting the table also removes the index, so this does not mitigate the accidental-deletion scenario.

Enable DynamoDB Streams on the table and write a consumer that copies every change into an Amazon S3 bucket for long-term retention.

Why it fails: DynamoDB Streams captures item-level changes and can feed a replication consumer, but it does not protect against table deletion or provide point-in-time restore of the table itself. Streams records expire after 24 hours, and a table deletion stops the stream, so this is not a reliable safeguard for the stated risks.

Convert the DynamoDB table to use provisioned capacity mode with auto scaling so that read and write capacity automatically adjusts during traffic spikes.

Why it fails: Provisioned capacity with auto scaling tunes throughput and cost, but it has no bearing on Availability Zone resilience of the compute tier or on protecting the table from deletion. The table itself is already replicated across zones by DynamoDB, so this change does not address either stated requirement.