Cloudfront practice questions

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.

Enable S3 static website hosting and disable CloudFront, because website hosting blocks direct object URL access.

Why wrong: S3 website hosting often requires specific configuration and does not inherently provide origin-only access controls for security.

Add a WAF rule that rate-limits requests to the S3 bucket domain to make direct access impractical.

Why wrong: WAF typically applies at CloudFront/web front ends; rate limiting does not provide guaranteed access restriction at the bucket.

Turn on S3 object versioning so that attackers cannot read previous objects.

Why wrong: Versioning affects recovery and deletion semantics, not whether objects are publicly readable via S3.

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.

Use AWS WAF CloudFront (global) scope and associate the web ACL with the ALB

Why wrong: CloudFront scope is designed for CloudFront distributions. ALB traffic is handled by regional WAF, not the CloudFront (global) scope, so this association path would not provide the intended protection.

Use AWS Shield Advanced and rely on it to inspect payloads for SQL injection and XSS

Why wrong: Shield Advanced primarily focuses on DDoS protection. AWS WAF provides rule-based inspection and blocking of application-layer threats such as SQL injection and XSS via managed rules/custom rules.

Use security groups only, because they can detect SQL injection patterns in HTTP requests

Why wrong: Security groups control network traffic (protocols/ports/IPs). They do not inspect HTTP payload content, so they cannot detect and block application-layer exploit patterns like SQL injection or XSS.

Application Load Balancer (ALB) using HTTP/HTTPS listeners with host-based routing

Why wrong: ALB is a Layer 7 (application) load balancer designed for HTTP/HTTPS. It does not natively load balance arbitrary TCP protocols that do not use HTTP semantics.

Classic Load Balancer (CLB) configured for TCP health checks only

Why wrong: CLB is an older generation load balancer. For new designs needing high performance for TCP traffic and modern feature support, NLB is the recommended choice.

API Gateway with a VPC Link to forward raw TCP traffic

Why wrong: API Gateway is designed for HTTP APIs (REST/HTTP/WebSocket). It does not provide Layer 4 raw TCP load balancing for arbitrary TCP application protocols.

S3 Cross-Region Replication

Why wrong: CRR replicates objects and does not optimize dynamic application routing.

CloudFront only with long TTLs

Why wrong: CloudFront is strongest for cacheable HTTP content; long TTLs can be wrong for dynamic responses.

AWS Backup cross-Region copy

Why wrong: Backup copies do not reduce live user latency.

AWS Backup Vault Lock

Why wrong: Backup Vault Lock protects backups, not CloudFront delivery.

IAM Access Analyzer

Why wrong: Access Analyzer reviews permissions and does not serve cached content.

S3 Select

Why wrong: S3 Select retrieves subsets of object data and does not increase origin outage tolerance.

Increase the origin response Cache-Control max-age header on S3 so CloudFront caches longer even with different rnd values.

Why wrong: Increasing TTL affects how long each cached object remains, but it does not change how CloudFront partitions the cache. If rnd is part of the cache key, you will still generate a distinct cache entry per rnd value, keeping hit ratio low regardless of TTL.

Disable compression on CloudFront so the response body is identical byte-for-byte and cache hits improve.

Why wrong: Compression settings affect how the response is transferred and can change which variants are stored, but they do not address the primary driver of low hit ratio here: different cache keys caused by varying query parameters. If rnd remains in the cache key, cache misses will persist.

Switch the origin from S3 to an ALB so CloudFront can cache based on ALB target health checks instead of the query string.

Why wrong: CloudFront cache keys are determined by the Cache Policy (headers/query strings/cookies, etc.), not by the origin type or target health checks. Changing the origin to an ALB adds complexity and does not fix cache fragmentation caused by rnd being included in the cache key.

AWS Backup Vault Lock

Why wrong: Backup Vault Lock protects backups, not CloudFront delivery.

IAM Access Analyzer

Why wrong: Access Analyzer reviews permissions and does not serve cached content.

S3 Select

Why wrong: S3 Select retrieves subsets of object data and does not increase origin outage tolerance.

Deploy a single-node Redis cluster and rely on application-level retries when cache misses occur.

Why wrong: A single-node setup has no automatic failover, so AZ impairment can fully break cache availability.

Move the cache into the VPC but keep it in one Availability Zone to reduce network latency.

Why wrong: Network placement does not address AZ-level redundancy; keeping one AZ still creates a single point of failure.

Use a Memcached cluster and configure only client-side connection pooling without failover support.

Why wrong: Memcached differs operationally and connection pooling does not implement node-level failover in another AZ.

AWS Direct Connect

Why wrong: Direct Connect improves private network connectivity, but it does not provide edge caching for public content.

Amazon Route 53 health checks

Why wrong: Route 53 health checks help with DNS failover, not caching or content delivery performance.

Amazon EFS

Why wrong: EFS is a shared file system service and does not solve global delivery of static web assets.

Add an S3 bucket policy Deny statement that blocks requests unless the principal uses MFA.

Why wrong: MFA affects authentication for interactive identity flows. It does not provide any guarantee about the network path or whether the request traversed a specific VPC endpoint, so it cannot enforce the required endpoint-level routing constraint.

Enable Block Public Access and remove the public bucket policy statement.

Why wrong: Block Public Access prevents public exposure of the bucket, but it does not restrict access to a specific VPC endpoint. Private requests from other network locations (that can still reach S3 with valid credentials) would remain possible.

Attach an IAM policy to the workload role that allows s3:PutObject only to the bucket ARN.

Why wrong: Least-privilege IAM limits which actions and resources are permitted, but IAM cannot constrain the origin network path (for example, forcing traffic to traverse vpce-0abc123example). A valid principal could still call S3 from anywhere that has network reachability and credentials.

A WAF rule that blocks requests without valid JWTs, without using signed URLs

Why wrong: WAF can inspect and block requests, but it is not the primary built-in CloudFront mechanism for time-limited, resource-scoped authorization. Implementing expiring per-user access with JWT validation via WAF is possible in some architectures, but it is not the most direct, native CloudFront feature described for this requirement.

Turning on S3 bucket public access block, without any CloudFront viewer authentication

Why wrong: Blocking public access ensures the objects can’t be fetched directly from S3, but it does not automatically ensure only authenticated users can fetch via CloudFront. If the CloudFront distribution allows access (and the origin access/OAC configuration permits it), requests can still reach CloudFront without user authentication and without a 1-hour expiry control.

Enabling CloudFront geo restriction to allow only one country

Why wrong: Geo restriction limits access by geographic location, not by user authentication and not by time-limited authorization. It does not provide expiring per-user/per-session access.

Reboot the DB instance and rely on the corrupted data being overwritten by storage-level changes.

Why wrong: Rebooting the DB instance does not undo logical data changes (for example, corrupted rows caused by an application release). It preserves the current database contents; it does not restore a previous state.

Restore only the most recent automated backup snapshot, even if it is after the corruption timestamp.

Why wrong: A “most recent snapshot” may have been taken after the corruption occurred. If the snapshot includes the corrupted rows, restoring it would not meet the requirement to revert to the 10:00–10:30 UTC state.

Create a read replica of the current DB instance and overwrite the corrupted table using SELECT queries from the replica.

Why wrong: A read replica continuously replicates from the source and will receive the corruption as well. It cannot recreate the pre-corruption data state needed for a time-based rollback.

Attach an AWS WAF Web ACL to CloudFront and allow public reads on the S3 bucket so WAF can block direct object access.

Why wrong: WAF evaluates requests that arrive at CloudFront; it does not control access to objects requested directly from S3 using the S3 endpoint. If the bucket allows public reads, anyone who knows the object URL can download it without passing through CloudFront/WAF.

Create IAM users with s3:GetObject permissions and share the IAM credentials with customers so they can fetch objects directly from S3.

Why wrong: Providing customers with long-lived credentials violates least-privilege and significantly increases the blast radius of any credential leak. It also does not prevent direct S3 access; customers would still be able to call the S3 endpoint directly.

Enable S3 static website hosting on the bucket and use the S3 website endpoint as the CloudFront origin so access controls can be enforced at CloudFront.

Why wrong: S3 static website endpoints do not support the same access control model as S3 REST endpoints used with OAC. As a result, this commonly leads to weaker origin protection and does not provide the strict origin authorization guarantees that bucket policies + OAC provide for private content.

Increase the table’s provisioned read capacity units while keeping partition key = customerId.

Why wrong: Increasing provisioned read capacity can raise the overall throughput, but it does not address the root cause of hot partitions: all reads for a given customerId target the same partition(s). If a single partition must serve most reads, throttling can still occur even with more total capacity.

Remove the sort key and use timestamp as the partition key to increase cardinality.

Why wrong: Using timestamp as the partition key may increase the number of distinct partition key values, but it does not guarantee distribution aligned with the customer’s read hotspot. During a campaign, traffic volume per customer is still the dominant factor; reads could still concentrate on the same time windows or key values relative to query patterns.

Switch to on-demand capacity and rely on DynamoDB to automatically distribute reads across partitions.

Why wrong: On-demand capacity can absorb bursts by provisioning capacity dynamically, but it does not change how requests map to partitions. If the partition key design causes a single partition key value to receive a disproportionate share of traffic, throttling behavior can still appear for that hot partition even in on-demand mode.

Include the Authorization header in the cache key so responses vary correctly

Why wrong: Including Authorization in the cache key causes CloudFront to treat requests with different Authorization values (for example, different tokens per user) as different cache objects, fragmenting the cache and lowering hit ratio for public assets.

Disable caching and always fetch from S3

Why wrong: Disabling caching eliminates reuse and forces every request to hit the origin (higher latency and higher S3/origin load), which is the opposite of improving cache hit ratio.

Forward all headers and cookies to the origin to improve correctness

Why wrong: Forwarding extra headers/cookies typically increases cache fragmentation unless they are excluded from the cache key. For public static assets, forwarding does not improve cache reuse and usually worsens hit ratio.

IAM Access Analyzer

Why wrong: Access Analyzer reviews permissions and does not serve cached content.

AWS Backup Vault Lock

Why wrong: Backup Vault Lock protects backups, not CloudFront delivery.

S3 Select

Why wrong: S3 Select retrieves subsets of object data and does not increase origin outage tolerance.

Use an Application Load Balancer because path-based routing improves throughput for binary protocols.

Why wrong: Incorrect because ALB is an HTTP/HTTPS layer-7 load balancer. Its routing features do not help a custom TCP protocol and add unnecessary protocol overhead.

Expose the service through API Gateway because it supports raw TCP and UDP pass-through.

Why wrong: Incorrect because API Gateway is for API protocols such as HTTP and WebSocket, not raw TCP or UDP pass-through. It is not the right fit for a custom binary telemetry stream.

Lower the CloudFront minimum TTL to 0 seconds so cached objects revalidate more often, reducing origin fetch volume.

Why wrong: Setting TTLs closer to 0 typically increases revalidation/refresh frequency and can increase origin contact. It does not address the root cause here: cache key fragmentation caused by including a unique `reqId` value.

Set the S3 bucket to use compression and enable S3 Transfer Acceleration to reduce origin fetch charges.

Why wrong: The observed increase is driven by higher origin fetch *request* volume caused by poor cache key hit ratio. Compression and Transfer Acceleration may change payload size or transfer characteristics but do not fix the caching failure caused by `reqId` being part of the cache key.

Disable forwarding of the query string to the origin, but keep using the full query string (including `reqId`) in the cache key.

Why wrong: Even if CloudFront does not forward query strings to the origin, the cache key still determines cache reuse. If `reqId` remains part of the cache key, CloudFront will still create mostly unique cache entries, so origin fetches remain high.