Hard Difficulty Questions

S3 Glacier Flexible Retrieval: Data accessed infrequently but requires rapid access when needed; retrieval time milliseconds

Why wrong: S3 Glacier Flexible Retrieval is an archival storage class with data access times ranging from 1 minute to several hours, not milliseconds as the scenario requires. The scenario describing rapid access with millisecond retrieval matches S3 Standard-IA, so assigning Glacier Flexible Retrieval is incorrect because it cannot meet the sub-second latency requirement and would also introduce unnecessary retrieval costs.

S3 Glacier Deep Archive: Data that can be retrieved within 1-5 minutes

Why wrong: S3 Glacier Deep Archive is the lowest-cost storage class, intended for long-term archival data with retrieval times of 12–48 hours. The scenario specifies data that can be retrieved within 1–5 minutes, which is characteristic of Glacier Flexible Retrieval, not Deep Archive; hence this option is wrong as it would fail to satisfy the defined retrieval-time constraint.

S3 mounted as a POSIX file system without a file gateway

Why wrong: Amazon S3 is object storage, not a POSIX file system, and a direct FUSE mount such as s3fs only emulates file-system behavior with weak consistency, no file locking, and suboptimal performance for concurrent warehouse workloads. Amazon File Gateway is the intended bridge to expose S3 as NFS/SMB, but without it, mounting S3 as POSIX is not a valid shared file-storage solution.

Instance store volumes

Why wrong: Instance store volumes are ephemeral block devices physically attached to a single EC2 host; their data is lost when the instance is stopped, terminated, or fails, and they cannot be shared across multiple instances. While they offer high I/O performance, they lack durability and shared access, making them entirely unsuitable as a persistent shared file system for a warehouse integration service.

An EBS volume attached to all instances

Why wrong: A standard EBS volume is a zonal block-storage device bound to a single EC2 instance; it cannot be attached to 'all instances' for concurrent shared file access. EBS Multi-Attach exists only for specific io1/io2 volumes on Nitro instances and supports a few instances without full POSIX file-locking semantics, so it does not satisfy shared file storage for a warehouse integration service.

Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.

Why wrong: On-demand already scales capacity automatically, and the problem here is hot, repeated reads with cacheable data rather than missing capacity.

Create a global secondary index on tenantId to distribute the load across more partitions.

Why wrong: A GSI changes access paths, but it does not cache repeated reads and may add write overhead without solving the hot-read pattern.

Move the dashboard data into S3 and use Lambda functions to read it on demand.

Why wrong: That would replace a low-latency database with an object-storage workflow and would worsen the user-facing read path.

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.

A larger deployment package

Why wrong: A larger package can increase cold-start time.

Reserved concurrency only

Why wrong: Reserved concurrency limits and reserves capacity but does not pre-initialize execution environments.

CloudTrail data events

Why wrong: CloudTrail records API activity and does not reduce Lambda latency.

Keep unattached volumes around for troubleshooting after instance termination.

Why wrong: Leaving volumes attached to nothing after instance termination means you continue paying for storage that no workload is using, directly inflating your EBS bill. While such volumes might occasionally be needed for troubleshooting, keeping them indefinitely without a policy is a major cost leakage. The proper approach is to either delete unattached volumes immediately or protect them with a snapshot and a DLM retention plan, then delete the volume after the snapshot is taken.

Raise provisioned IOPS on every volume so snapshot restore time feels faster.

Why wrong: Increasing provisioned IOPS on all volumes is a misunderstanding of how EBS snapshot restore works: the restore operation streams data from the snapshot to a new volume and is bounded by the snapshot's storage tier and the volume's size, not by the destination volume's later IOPS capability. Provisioned IOPS only affect steady-state performance, not the initial volume initialization or snapshot hydration speed, so this change would raise costs without making restores feel any faster. Furthermore, the core issue here is unnecessary storage retention, not restore latency, so spending extra on IOPS does not address the real problem.

A security group rule that allows HTTPS to S3

Why wrong: Security groups are attached to ENIs and cannot be applied directly to an S3 bucket, because S3 is a managed regional service outside the VPC. Even if you allow outbound HTTPS, that only permits network traffic; it does not restrict access to a specific bucket or prove that traffic traversed a VPC endpoint. To enforce endpoint-only access, you must use a bucket policy condition such as aws:sourceVpce, not a security group rule.

A condition that matches aws:RequestedRegion to the bucket Region

Why wrong: aws:RequestedRegion limits the AWS Region in which an API call is executed, but it does not constrain the network path the request takes. A request could originate from the public internet, an on-premises network, or any VPC and still satisfy the condition if it targets the same regional endpoint. Therefore, this condition is insufficient to guarantee that your EC2 instance's traffic used the VPC endpoint.

A deny statement for all IAM users except the EC2 role

Why wrong: A deny statement for all IAM users except the EC2 role controls identity, not network reachability; it only prevents unauthenticated or other principals from calling S3. The EC2 role itself could be used by an instance in another subnet, and an attacker with the role credentials could make requests from outside the VPC endpoint. This does not enforce that the traffic actually flows through the endpoint, which is the core requirement.

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

Why wrong: Deploying a NAT Gateway in each Availability Zone would technically provide outbound internet access for private instances, but it's the exact cost the team wants to remove: NAT Gateways incur an hourly charge per gateway and per-GB data processing fees. For S3 access, a gateway VPC endpoint is free and more direct because it bypasses the internet path entirely. Using NAT Gateways adds unnecessary cost, introduces an internet dependency, and does not improve security or encryption controls over the bucket policies, making it an inferior and overly expensive solution.

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

Why wrong: The S3 static website endpoint is designed for public hosting of static content and does not support private VPC access or bucket policy enforcement the same way. It does not automatically enforce HTTPS—clients can still use the HTTP endpoint—and it lacks support for VPC endpoint routing, so private instances would require a NAT Gateway or other internet path. Additionally, static website endpoints cannot enforce SSE-KMS or require transport security via aws:SecureTransport conditions, so they fail the security and connectivity requirements for private CI artifact uploads.

Increase the CloudFront price class to include more edge locations.

Why wrong: A broader price class can change geographic reach and pricing, but it does not address the real problem: the cache key is fragmented by headers and query strings that do not affect the content of these versioned static assets.

Disable CloudFront and serve the files directly from S3 to avoid cache invalidation overhead.

Why wrong: Serving directly from S3 removes the caching layer entirely, which increases origin requests and data transfer from S3 while also reducing performance for global users. It would likely increase overall cost rather than reduce it.

Use Lambda@Edge to rewrite every request into a unique path so that clients never receive stale files.

Why wrong: Using Lambda@Edge to generate a unique path per request is counterproductive: it deliberately bypasses CloudFront's cache reuse by making every request logically distinct, so the cache hit ratio plummets and S3 receives far more origin fetches. It also adds per-request compute charges for Lambda execution and adds complexity to the request flow, whereas versioned filenames already provide natural cache invalidation by changing the URL only when the content changes. Instead, keep the URL stable and let CloudFront's cache key rely on that versioned filename with a long TTL.

Enable CloudFront compression and configure the origin to return Cache-Control: no-store for all files.

Why wrong: Although CloudFront compression reduces transfer size via gzip/Brotli, setting Cache-Control: no-store on every file instructs CloudFront and browsers to bypass caching entirely. That forces each viewer request to traverse all the way back to the origin, collapsing edge cache hits and multiplying origin load—the opposite of improving the hit ratio for immutable JavaScript and CSS. Versioned assets should instead use long-lived immutable Cache-Control directives (e.g., max-age=31536000, immutable), and no-store also overrides any default CloudFront caching behavior, making the combination counterproductive.

Forward all viewer headers to the origin so CloudFront can personalize every request.

Why wrong: Forwarding every header makes the cache key highly fragmented and usually reduces hit ratio sharply. Static JavaScript and CSS files should be cached by content identity, not by per-user metadata that the origin does not need.

Enable S3 Object Lock in compliance mode.

Why wrong: Object Lock protects objects from deletion or overwrite, which is useful for retention and immutability, but it does not provide audit visibility into who downloaded the files. It is a preventive and retention control, not the detective control requested here.

Turn on default bucket encryption with SSE-KMS.

Why wrong: Default encryption ensures new objects are stored encrypted at rest, but it does not create an audit trail for object downloads or KMS Decrypt activity. The question asks for investigative visibility, not just encryption configuration.

Enable MFA Delete on the bucket.

Why wrong: MFA Delete is a versioning safety control that requires multi-factor authentication to permanently delete an object version or change the bucket's versioning state. It does not generate or expose any audit trail of object-level operations such as GetObject, PutObject, or even DeleteObject calls — CloudTrail logs the API call but MFA Delete does not add data-event logging. Since the investigation needs to determine who downloaded objects and when, MFA Delete's deletion-prevention capability is irrelevant to identifying exfiltration activities.

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.

Disable CloudWatch Logs entirely and rely on application local files for 90 days.

Why wrong: Local files are not a durable or centralized substitute for CloudWatch Logs. This would increase operational risk, make retention harder to enforce, and reduce the team’s ability to search and audit logs across the fleet.

Increase the number of CloudWatch alarms so that metrics are collected less expensively.

Why wrong: Adding more CloudWatch alarms cannot lower metric collection costs because alarms are billed per alarm and simply evaluate the same underlying metric data. The recurring costs in the exhibit come from detailed monitoring (1-minute metrics) enabled on all 200 EC2 instances and from CloudWatch Logs retention set to indefinitely retain logs; neither of these charges is affected by the number of alarms. In fact, each standard alarm has its own monthly price, so increasing alarm count would increase the bill, not reduce it.

Export all logs to Amazon S3 immediately and keep detailed monitoring enabled on every instance.

Why wrong: Exporting logs to S3 can help with archival economics, but it does not reduce the detailed monitoring charge, which is one of the largest costs in the exhibit. Keeping detailed monitoring on every instance preserves the major recurring cost driver.

Use a NAT gateway for outbound access and rely on security groups to block internet destinations.

Why wrong: A NAT gateway routes traffic from the private subnet to the internet through an internet gateway, meaning requests to public S3 and Secrets Manager endpoints traverse the public network rather than remaining wholly on the AWS private backbone. Security groups are stateful filters based on IP addresses and ports; they cannot differentiate between public and private endpoints by service name or URL, nor can they force traffic to stay on private connectivity. This design fails the requirement for private network-only access, incurs NAT data processing charges, and does not provide the same performance or security as directly using VPC endpoints.

Create interface VPC endpoints for both S3 and Secrets Manager and enable private DNS.

Why wrong: Secrets Manager requires an interface endpoint, but S3 is more appropriately reached with a gateway endpoint. Using interface endpoints for both is not the best fit for the scenario and adds unnecessary cost and complexity.

Use VPC peering to a public subnet that hosts a proxy for S3 and Secrets Manager access.

Why wrong: VPC peering does not provide access to AWS service endpoints by itself, and introducing a proxy in a public subnet creates unnecessary exposure. It also adds operational overhead and does not satisfy the simplest private connectivity design.

Attach DeployBoundary to the automation role only, because that automatically forces every created role to inherit the same boundary.

Why wrong: A boundary on the creator role does not automatically propagate to newly created roles. The new role must either be created with the boundary or be blocked unless it includes the approved boundary. Creator boundaries and target-role boundaries are separate controls.

Create an SCP that denies iam:CreateRole and iam:PutRolePermissionsBoundary unless aws:RequestTag equals DeployBoundary.

Why wrong: Request tags are useful for tagging governance, but they do not validate which permissions boundary is attached to the new role. The enforcement must check the permissions boundary parameter or the boundary ARN condition, not a general request tag.

Use AWS Access Analyzer to automatically attach the approved boundary whenever a role is created without one.

Why wrong: Access Analyzer is a detection and analysis service, not an enforcement mechanism that modifies IAM resources. It can help identify overly broad access, but it cannot automatically attach permissions boundaries to IAM roles during creation.

Pilot light, because only the database needs to be running in the secondary Region.

Why wrong: Pilot light keeps only a minimal set of components active in the secondary Region. In this exhibit, the database replica is already current, but the measured recovery time still exceeds the RTO because the application tier must be started from zero.

Active-active, because both Regions should always serve traffic to guarantee the RTO.

Why wrong: Active-active can provide very fast recovery, but it requires both Regions to run at production scale and introduces significant operational complexity. The requirement asks for the least always-on cost, so this is more than necessary.

Backup and restore, because restoring from backups is the least expensive DR model available.

Why wrong: Backup and restore is the lowest-cost disaster recovery model, but it is the slowest to recover. In this scenario, the measured recovery time already exceeds the 15-minute RTO at 18 minutes even with a warm database replica, and a true backup/restore approach would require rehydrating snapshots, rebuilding EC2 instances, and redeploying the application stack—typically taking hours, not minutes. It would also introduce RPO risk because any data changes after the last backup would be lost, making it unsuitable for this workload's recovery objectives.

Spread placement group, because it places each instance on distinct underlying hardware.

Why wrong: A spread placement group is optimized for availability by reducing correlated failure risk across individual instances. It intentionally separates instances across distinct hardware, which is useful for fault tolerance but not for minimizing east-west latency or jitter for a tightly coupled cluster.

Partition placement group, because it isolates nodes across rack partitions.

Why wrong: Partition placement groups help large distributed systems reduce the impact of correlated infrastructure failures by separating instances into logical partitions. They are a resilience feature, not a performance feature, and they do not provide the close network proximity needed for the lowest-latency message exchange.

Move the workload behind an Application Load Balancer so node-to-node traffic is balanced more efficiently.

Why wrong: An Application Load Balancer operates at Layer 7 and is designed to distribute external client requests across a fleet of instances or containers, not to mediate server-to-server (east-west) traffic. Placing an ALB between cluster nodes would insert an extra proxy hop, adding latency and jitter rather than reducing it, and it would terminate and re-establish TCP connections, which is catastrophic for a tightly coupled analytics cluster that relies on persistent, high-throughput streams. Furthermore, ALB does not alter the physical placement of instances, so it cannot shorten the underlying network path that determines east-west latency.

Buy EC2 Instance Savings Plans for the baseline and run the nightly batch on On-Demand instances.

Why wrong: Buying EC2 Instance Savings Plans would lock the account into one instance family in one Region, reducing architectural flexibility if the team shifts to a different EC2 family over time. More importantly, running the nightly batch on On-Demand instances ignores that these replica workers are explicitly interruption-tolerant and checkpointed, so Spot Instances could slash batch compute costs by up to 90% without harming the job. This combination therefore underutilizes the workload's tolerance of interruption and leaves money on the table.

Purchase Standard Reserved Instances for all 12 instances and keep the current families fixed.

Why wrong: Reserved Instances can reduce cost, but they lock you into more specific EC2 characteristics. They are less flexible than a Compute Savings Plan and do not take advantage of Spot savings for interruption-tolerant batch work.

Run both tiers entirely on Spot Instances and rely on automatic restarts for the baseline web tier.

Why wrong: Running the 24/7 web tier entirely on Spot Instances is risky because EC2 can reclaim capacity with only a two-minute warning, which would trigger HTTP 503s, dropped connections, and degraded user experience even if Auto Scaling replaces the instances. The baseline web tier requires consistent, available capacity; it is not a fault-tolerant batch job that can simply restart at the next transaction boundary. While Spot is perfect for the checkpointed nightly batch, using it for the always-on production web layer is not a cost optimization — it is an availability gamble.

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.