Cloudfront practice questions

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.

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.

RDS read replicas

Why wrong: Read replicas do not accelerate static content delivery from S3.

A larger S3 bucket

Why wrong: Bucket size does not affect user latency.

An EC2 Auto Scaling group in one Region

Why wrong: More EC2 instances do not cache static S3 content globally.

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.

Enable public read access on the S3 bucket and rely on WAF alone for authorization because WAF can validate signatures.

Why wrong: WAF is not meant to replace authorization signatures for content protection, and public S3 access undermines security. Even if WAF blocks some traffic, public access allows requests that bypass your intended controls if misconfigured. Signed cookies/URLs are the appropriate edge authorization mechanism.

Configure CloudFront with signed URLs but do not change the S3 bucket access settings; leaving public access enabled is acceptable since CloudFront can filter traffic.

Why wrong: If the S3 bucket remains public, clients can bypass CloudFront entirely by accessing the S3 object URLs directly. Signed URLs protect only requests going through CloudFront behaviors, not direct S3 origin access. The origin must be restricted so content cannot be retrieved outside CloudFront.

Use WAF at CloudFront but omit signed cookies/URLs because rate limiting and exploit blocking already provide access control for private files.

Why wrong: WAF protections can reduce threats but do not implement business authorization for specific customers. Rate limiting and exploit blocking do not prevent an authorized user from sharing links or retrieving content without required authentication. Signed cookies/URLs are specifically for controlling content access.

Add a global secondary index for every frequently viewed product attribute.

Why wrong: A GSI helps with alternative query patterns, but it does not function as an in-memory cache for repeated reads of the same items. Creating more indexes also increases write cost and design complexity. The workload already has a good key design, so the real problem is read latency on hot items, not the absence of a query path.

Switch the table to on-demand capacity mode to reduce latency.

Why wrong: On-demand capacity simplifies scaling, but it does not provide caching or directly reduce per-request latency for repeated reads. It helps absorb traffic variability, yet the underlying read path still goes to DynamoDB. In this scenario, the issue is fast access to hot items, so capacity mode alone is not enough.

Move the catalog to Aurora and use a read replica for every region.

Why wrong: Migrating to Aurora would introduce a different database model and does not address the immediate problem in the simplest way. Read replicas can help with relational read scaling, but they are not a drop-in optimization for this DynamoDB workload. The question specifically asks for the least disruptive change, and DAX preserves the current architecture.

Create a cache policy that forwards the query string to the origin and varies the cache key by all query parameters.

Why wrong: If the cache key varies by all query parameters, then every unique tracking value produces a different cache key. That creates cache fragmentation (many near-duplicate objects), which lowers the cache hit ratio and increases origin requests—directly opposing the goal.

Enable S3 origin access control and keep the existing default cache policy, because origin access changes caching behavior automatically.

Why wrong: S3 origin access control restricts how CloudFront can access the S3 bucket (security/authorization). It does not change how CloudFront constructs the cache key. If the existing cache policy forwards or varies on the tracking query string, the hit ratio will still drop.

Set the CloudFront Time-to-Live (TTL) to 0 seconds to ensure the origin always serves the latest asset content.

Why wrong: TTL of 0 effectively disables caching for the objects, causing cache misses for most requests. That increases origin traffic and usually worsens both performance and cost. The problem here is cache key fragmentation, not stale content.

Increase the ALB idle timeout to allow the origin to absorb more concurrent requests.

Why wrong: ALB idle timeout affects how long an existing connection can remain open, not how many requests a hostile client can generate. Increasing it may actually increase resource consumption at the origin instead of stopping the abuse.

Add an Amazon Route 53 health check to fail over traffic to another DNS name.

Why wrong: Route 53 health checks and failover are used for endpoint availability and regional failover, not for filtering or rate-limiting abusive requests from a single client IP. This would not stop the malicious traffic from reaching the origin.

Enable AWS Shield Advanced and rely on automatic DDoS protection for all request bursts.

Why wrong: AWS Shield Advanced is useful for broader DDoS resiliency, especially for large-scale network and transport layer attacks, but the precise control for this HTTP request pattern is AWS WAF with a rate-based rule. The scenario calls for request-level edge filtering, not only infrastructure-level DDoS protection.

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.

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.

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.

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.

Upload website files to S3, then create S3 bucket and enable static website hosting, then create CloudFront distribution, then configure CloudFront, then update DNS.

Why wrong: This order is incorrect because you should enable static website hosting before uploading files to ensure the bucket is properly configured with index and error documents. While technically possible, it's not the recommended sequence and can lead to misconfiguration.

Create S3 bucket and enable static website hosting, then create CloudFront distribution, then upload website files, then configure CloudFront, then update DNS.

Why wrong: This order is incorrect because you should upload files to S3 before creating a CloudFront distribution. The distribution needs the origin bucket to have content to cache and serve; otherwise, you'd have to update the distribution after upload, which is inefficient.

Create S3 bucket and enable static website hosting, then upload website files, then create CloudFront distribution, then update DNS, then configure CloudFront.

Why wrong: This order is incorrect because you must configure the CloudFront distribution (e.g., alternate domain names, SSL certificate) before updating DNS. DNS should point to the CloudFront distribution domain name only after it is fully configured and deployed.

Configure a larger ALB deregistration delay so that old targets remain longer before termination.

Why wrong: ALB deregistration delay affects how long existing targets are kept during scale-in events and connection draining behavior. It does not reduce the initialization/warm-up time of newly launched instances. If new instances cannot become healthy until warm-up completes, customers can still see 5xx responses during the initial minutes after scale-out.

Increase the number of desired instances immediately without using scaling policies, and then rely on manual reconfiguration.

Why wrong: Manually changing desired capacity can work in an operational sense, but it is not a direct improvement to application warm-up time, and it is not responsive/automated for demand variability. It also doesn’t solve the core issue: newly created instances still require the same warm-up duration before they pass ALB health checks.

Switch from ALB to NLB so instances become reachable sooner without waiting for health checks.

Why wrong: NLB does not inherently remove the application’s initialization requirement. While health check behavior differs by load balancer type (e.g., NLB often uses TCP-level checks), the application still needs time to become ready to handle requests successfully. Switching to NLB may change routing and health-check characteristics, but it does not directly address the ~4-minute warm-up bottleneck.

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.

A security group rule that allows HTTPS to S3

Why wrong: Security groups do not attach to S3 buckets and cannot enforce S3 bucket access.

A condition that matches aws:RequestedRegion to the bucket Region

Why wrong: RequestedRegion limits API calls by Region but does not prove traffic used the endpoint.

A deny statement for all IAM users except the EC2 role

Why wrong: This controls identity but does not enforce the network path through the endpoint.

Enable S3 Transfer Acceleration on the bucket to speed up uploads.

Why wrong: S3 Transfer Acceleration is designed to speed up data *uploads* to S3 buckets, particularly from clients geographically distant from the bucket's region. The question focuses on *serving* video content, which involves downloads/reads by viewers. Therefore, while useful for content ingestion, it does not directly improve the performance of content delivery to end-users.

Use Amazon ElastiCache for Memcached to cache video metadata at the edge.

Why wrong: Amazon ElastiCache for Memcached is a managed in-memory caching service typically deployed within an AWS VPC in a specific region. It is not designed to operate at CloudFront's global edge locations, which are geographically distributed points of presence. CloudFront's own caching mechanisms handle content and metadata caching at the edge.

Enable S3 default encryption using AWS KMS to improve data transfer performance.

Why wrong: Enabling S3 default encryption using AWS Key Management Service (KMS) secures data at rest within the S3 bucket, fulfilling security and compliance requirements. However, encryption and decryption operations, especially when integrated with KMS, introduce processing overhead. This process does not improve data transfer performance; rather, it can marginally increase the time required for data access.

Enable CloudFront standard logging

Why wrong: Logging records requests but does not block direct S3 access.

Enable S3 static website hosting

Why wrong: Website hosting requires public-style access patterns and does not protect the origin.

Keep Authorization in the CloudFront cache key, but increase the origin response minimum TTL to 1 day.

Why wrong: A longer TTL can reduce some re-fetches, but varying the cache key by Authorization still creates separate cache entries for different Authorization values. That fragmentation remains the primary driver of a low hit ratio, and time-to-live settings do not change cache-key uniqueness.

Switch the S3 origin from the current bucket to a website endpoint to enable automatic caching headers.

Why wrong: Changing the origin type (REST endpoint vs website endpoint) does not remove cache-key variation caused by the Authorization header. CloudFront cache-key behavior is controlled by CloudFront cache policy/origin request policy, not by the origin endpoint type. This change also can introduce additional differences in behavior and error handling.

Enable CloudFront to forward all headers to S3 so origin can decide caching behavior per request.

Why wrong: Forwarding all headers typically reduces caching effectiveness because many header values vary per request, leading to more unique combinations and more cache misses. In this scenario, the key issue is cache-key configuration that includes Authorization; forwarding headers does not fix the underlying cache fragmentation and can make cache reuse worse.