Cloudfront practice questions

AWS Lambda with scheduled scaling

Why it fails: Lambda cannot run or scale the existing EC2 fleet, and scheduled scaling triggers on time, not CPU utilisation. It is tempting because Lambda is serverless and event-driven, and would be correct for scheduled batch jobs or event-triggered functions rather than load-driven EC2 scaling.

Amazon CloudFront with origin scaling

Why it fails: CloudFront caches and delivers content at edge locations; it has no origin scaling capability and cannot add EC2 capacity from CPU metrics. It is tempting because it fronts web applications, and would be correct for reducing latency and offloading static content, not for scaling compute.

AWS Elastic Beanstalk with environment scaling

Why it fails: Elastic Beanstalk manages its own environment and scaling policies, which conflicts with the requirement to scale the existing EC2 fleet behind an Application Load Balancer directly from CPU metrics. It is tempting as a managed platform, and would be correct for deploying a new application without existing infrastructure.

Store session state in Amazon DynamoDB

Why it fails: DynamoDB is a key-value store, not a session cache; it adds per-request latency and cost compared with ElastiCache, and the ALB cannot route by session ID. It is tempting because DynamoDB offers durable, highly available storage, and would suit persistent user profile or order data rather than ephemeral session state.

Store session state on the local instance store of each EC2 instance

Why it fails: Instance store is ephemeral and tied to one EC2 instance, so sessions vanish on stop or replacement and are invisible to other instances behind the ALB. It is tempting for its low latency and zero cost, and would be correct for scratch data or temporary caches that can be regenerated.

Store session state in Amazon S3

Why it fails: S3 offers no low-latency atomic read-modify-write for concurrent session updates, and the ALB cannot route requests by session ID. It is tempting because S3 is durable, highly available and cheap, and would be correct for storing static assets, logs or backups rather than live session state.

Deploy EC2 instances in multiple AWS Regions and use Route 53 latency-based routing.

Why it fails: Multi-Region EC2 with latency-based routing duplicates the entire application stack, requiring data replication, deployment pipelines and failover management across Regions — far from least operational effort. It is tempting because latency routing genuinely directs users to the closest healthy endpoint, and would be correct when full regional isolation or disaster recovery is also required.

Move the dynamic content to Lambda@Edge functions running at CloudFront edge locations.

Why it fails: Lambda@Edge cannot serve the origin EC2 dynamic content; it only runs JavaScript or Python at edge locations in response to CloudFront events, so the single-Region origin remains the bottleneck. It is tempting because Lambda@Edge genuinely reduces latency for request and response manipulation, and would be correct for header rewriting or lightweight personalisation at the edge.

Add an Amazon ElastiCache cluster in front of the EC2 instances to cache dynamic responses.

Why it fails: ElastiCache caches repeated reads but does not move content closer to distant users; each uncached request still traverses the globe to the single-Region EC2 origin, so latency for distant users persists. It is tempting because ElastiCache genuinely reduces database load and response times, and would be correct for read-heavy workloads with repeated queries from a concentrated user base.

Store session data on an Amazon EBS volume attached to each instance

Why it fails: An EBS volume attaches to a single Availability Zone and one instance, so session data written there is invisible to other instances behind the ALB. It is tempting as low-latency block storage for a single server, but it cannot be shared concurrently across a fleet.

Store session data in an Amazon RDS database

Why it fails: RDS stores session rows durably, but every read and write incurs a database round trip and connection overhead, making it costlier and slower than an in-memory store for high-churn session data. It is tempting because RDS is the default managed persistence layer for relational application data.

Enable sticky sessions (session affinity) on the ALB

Why it fails: Sticky sessions pin each user to one EC2 instance, so session data is never shared across the fleet; losing that instance loses the session, and load becomes uneven. It is tempting because affinity requires no external store, but it defeats the ALB's distribution and horizontal scalability.

AWS Global Accelerator and Amazon CloudFront

Why it fails: AWS Global Accelerator routes traffic over the AWS backbone to regional endpoints; it does not cache content at edge locations, so it fails the content delivery requirement. It is tempting because Global Accelerator improves latency and absorbs DDoS, and would suit TCP/UDP acceleration for non-cacheable workloads.

Amazon Route 53 and AWS Shield

Why it fails: Amazon Route 53 provides DNS resolution and AWS Shield adds DDoS protection, but neither caches content at edge locations, so no CDN is delivered. It is tempting because both are commonly paired for resilient global DNS, and would suit directing users to healthy endpoints rather than caching content.

AWS WAF and Amazon CloudFront

Why it fails: AWS WAF filters HTTP requests against web exploits, and CloudFront caches content, but WAF alone does not provide the volumetric DDoS absorption the scenario requires. It is tempting because WAF integrates with CloudFront, and would suit blocking SQL injection or bot traffic on a web application.

Use lifecycle hooks to save session data to Amazon S3 before instance termination.

Why it fails: Lifecycle hooks fire on termination and cannot persist sessions for requests already in flight, so users still lose state during scale-in. They suit graceful draining, deregistration or cleanup tasks, not continuous session storage that must survive instance replacement.

Enable sticky sessions (session affinity) on the Application Load Balancer.

Why it fails: Session affinity pins a client to one instance, so terminating that instance still destroys the session; it cannot preserve state across scale-in. Sticky sessions suit short-lived state or caching on stable fleets, not sessions that must survive instance termination.

Increase the Auto Scaling group's cooldown period to prevent rapid scaling.

Why it fails: Cooldown merely delays subsequent scaling activities; it does not stop the terminating instance from discarding its in-memory sessions. Cooldown periods suit smoothing flapping metrics and avoiding thrashing, not preserving state that must outlive any individual instance.

Amazon CloudFront

Why it fails: CloudFront is a content delivery network that caches and serves content from edge locations; it does not load-balance traffic across EC2 instances in an Auto Scaling group. It is tempting because it fronts origins, but the required distribution is handled by Application Load Balancer or Network Load Balancer.

AWS Global Accelerator

Why it fails: Global Accelerator routes traffic over the AWS global network to regional endpoints using static anycast IP addresses; it does not balance requests across EC2 instances in an Auto Scaling group. It is tempting for multi-Region failover, but the required distribution uses Application Load Balancer or Network Load Balancer.

Amazon Route 53

Why it fails: Route 53 is a DNS service that resolves names to endpoints, including weighted and latency routing; it does not distribute traffic across instances within an Auto Scaling group. It is tempting because it can steer traffic between regions, but here the load balancing is done by Application Load Balancer or Network Load Balancer.

Rewrite the entire application as microservices from scratch and deploy them in a new AWS environment. Cut over all traffic at once after testing.

Why it fails: A full from-scratch rewrite with a single all-traffic cutover maximises risk and cannot realistically finish within six months, contradicting the minimal-disruption requirement. It is tempting because greenfield microservices avoid legacy constraints, and rewriting would be correct for a small application with no continuity pressure.

Use AWS Blue/Green deployment for the monolith to reduce downtime, then migrate to microservices after the deployment is stable.

Why it fails: Blue/green deployment of the monolith reduces cutover downtime but keeps the monolith intact, deferring the microservices, serverless, and operational-overhead goals beyond the six-month window. It is tempting because blue/green is genuinely the right pattern when the goal is safe like-for-like migration without re-architecting.

Perform a lift-and-shift migration of the monolith to EC2 instances, then gradually refactor into microservices over the next year.

Why it fails: Lift-and-shift to EC2 preserves the monolith and defers modernisation, so it cannot deliver microservices or serverless within the six-month window; it merely relocates the operational burden. It is tempting because rehosting minimises migration risk and downtime, and would suit a scenario where speed of exit from a data centre outweighs architectural change.

Use AWS WAF with rate-based rules and associate it with the ALB.

Why it fails: AWS WAF rate-based rules throttle request volume per source IP at the ALB, but the ALB still terminates the flood, so attack traffic reaches the origin and TLS 1.3 termination is not provided. It is tempting because WAF filters application-layer exploits, which suits blocking SQL injection or bad bots rather than volumetric absorption at the edge.

Use an AWS Network Firewall and configure stateful rules to block malicious IPs.

Why it fails: Network Firewall inspects traffic entering a VPC, sitting behind the ALB rather than at the edge, so it cannot absorb a volumetric flood before it reaches the load balancer, and it does not terminate TLS 1.3 for clients. It is tempting because stateful rules block malicious IPs, which suits east-west or egress filtering inside a VPC.

Enable AWS Shield Standard and use security groups to restrict traffic.

Why it fails: Shield Standard is automatically enabled and only mitigates common layer 3/4 attacks; security groups filter instance traffic after the ALB, so they cannot absorb a flood at the edge or terminate TLS 1.3. It is tempting because Shield Standard is free and always on, which suits basic protection when no edge absorption or TLS requirement exists.

Add an Amazon ElastiCache Redis cluster in front of DynamoDB to cache session data.

Why it fails: Adding an ElastiCache Redis cluster would cache session data in memory, reducing read latency for DynamoDB queries. However, the stem specifies that the application already stores session state in DynamoDB; the performance bottleneck is read-heavy workloads on that table, not session retrieval. Redis is tempting because it excels at low-latency caching for frequently accessed key-value data, and would be correct if the goal were to offload repeated reads from a relational database or reduce DynamoDB read capacity costs.

Use an Auto Scaling group to add more EC2 instances during peak hours.

Why it fails: Adding EC2 instances scales compute capacity, but the read latency originates from the DynamoDB table, so the bottleneck remains untouched. Auto Scaling is correct for CPU-bound or connection-bound web tiers, not for reducing data-store read latency.

Increase the size of the EC2 instances to handle more concurrent users.

Why it fails: Scaling EC2 instance size adds compute capacity but leaves DynamoDB read latency untouched, since the bottleneck is the database layer, not the application tier. It is tempting because vertical scaling genuinely helps CPU-bound workloads, and it would be the right choice if the stem described application processing limits rather than read-heavy DynamoDB access.

Use distribution style AUTO and let Redshift decide

Why it fails: AUTO leaves distribution to Redshift's heuristics and may not co-locate the large joined tables, causing redistribution over the network. It is tempting because AUTO adapts as workload patterns change, which is the right choice when query patterns are unknown or genuinely mixed.

Use distribution style EVEN on all tables

Why it fails: EVEN spreads rows round-robin, so matching join keys land on different slices and every large join triggers data redistribution across nodes. It is tempting because EVEN balances storage and parallel scans, which suits tables never joined on a common column.

Use distribution style ALL on all large tables

Why it fails: Distribution style ALL copies every row of a table to every compute node. For large tables this multiplies storage and slows loads and vacuum operations, while joins still require redistribution. ALL suits small dimension tables; large fact tables need KEY or EVEN distribution to avoid excessive data movement.

Attach an Internet Gateway to the VPC

Why it fails: An Internet Gateway enables inbound and outbound internet traffic for a VPC, which is irrelevant to reaching an internal VPC resource. It is tempting because Lambda needs network pathing, but the function must instead be attached to private subnets within the VPC.

Set up a VPC peering connection

Why it fails: VPC peering connects two VPCs to each other, so it cannot place a Lambda function inside the VPC containing the resource. It is tempting because peering links networks, but the function must be configured with VPC subnet and security group settings.

Configure a NAT Gateway in the public subnet

Why it fails: A NAT Gateway provides outbound internet access for private subnets; it does not give Lambda access to a VPC resource. It is tempting because Lambda needs subnet routing, but the requirement is attaching the function to private subnets with appropriate security groups.

Use multiple EC2 instances behind an Application Load Balancer with sticky sessions.

Why it fails: Using multiple EC2 instances behind an ALB with sticky sessions still ties state to individual instances. If an instance fails, its sessions are lost, and scaling requires rebalancing sessions. This does not achieve true HA or scalability for state.

Lift and shift to a single Amazon EC2 instance with an EBS volume.

Why it fails: A single EC2 instance with one EBS volume remains a single point of failure and cannot scale horizontally, so the availability and scalability goals go unmet. It is tempting as the quickest lift-and-shift, and would suit a workload needing minimal change with no HA or scaling requirement.

Use an EC2 Auto Scaling group with lifecycle hooks to persist state to EBS snapshots.

Why it fails: Auto Scaling lifecycle hooks manage instance launch and termination, but EBS snapshots cannot serve as shared live state for a stateful application across instances. This approach suits stateless fleets needing graceful deregistration, not persistent per-node data.

Increase the number of read replicas to distribute the load.

Why it fails: Adding read replicas spreads query load but each replica still applies changes asynchronously, so lag persists. It is tempting because it scales read throughput, and would be correct when read capacity, not consistency, is the bottleneck.

Implement Amazon ElastiCache to cache read results.

Why it fails: ElastiCache serves cached copies that can be stale after a write, so read-after-write consistency is not guaranteed. It is tempting because it offloads repeated reads, and would be correct for read-heavy workloads tolerant of eventual consistency.

Use Amazon RDS Proxy to route read queries to the read replica.

Why it fails: RDS Proxy pools and shares database connections; it does not eliminate replica lag, so reads still return stale data. It is tempting because it improves scalability and failover, and would be correct for connection exhaustion or faster failover scenarios.

Use TCP listener on port 443 and forward to instances on port 80. Enable proxy protocol v2.

Why it fails: Network Load Balancer would be needed for TCP, but ALB is required for HTTP features.

Use TCP listener on port 443 and forward to instances on port 443. Install SSL certificate on instances.

Why it fails: SSL termination on instances adds management overhead and does not preserve client IP in logs unless configured.

Use HTTPS listener on port 443, provide the SSL certificate, and forward to instances on port 443. Disable proxy protocol.

Why it fails: Instances would need to handle SSL again, and client IP may not be preserved.

Switch to strongly consistent reads to improve consistency.

Why it fails: Strongly consistent reads consume twice the RCU of eventually consistent reads, so switching doubles capacity consumption on an already saturated table and worsens throttling. It is tempting because consistency sounds like an improvement, and strongly consistent reads would be correct where the application cannot tolerate stale data.

Create a global secondary index (GSI) on the table to offload reads.

Why it fails: A GSI duplicates the table's data and consumes its own provisioned capacity, adding cost and write amplification without relieving the base table's exhausted 1000 RCU. It is tempting because GSIs do serve different query patterns, and a GSI would be correct when reads need an alternative partition or sort key.

Increase the provisioned read capacity to 2000 RCU.

Why it fails: Raising provisioned capacity to 2000 RCU doubles the hourly cost of the table while leaving the underlying hot-partition or access-pattern cause of the latency unaddressed. It is tempting because throttling from exhausted capacity looks like the obvious culprit, and scaling RCU would be correct for genuinely uniform read growth across partitions.

Use Amazon ElastiCache for Memcached as a read cache.

Why it fails: While ElastiCache for Memcached can reduce read load by caching frequently accessed data, it fails here because the bottleneck is provisioned RCU saturation, not a lack of caching. The correct solution must increase read capacity or use DAX, which integrates directly with DynamoDB’s API and handles cache invalidation automatically. Memcached is tempting because it offloads database reads in general, but it would require custom application logic to manage cache misses and staleness, making it less direct for DynamoDB’s eventual consistency model.

Use signed URLs to serve content.

Why it fails: Signed URLs control who may access objects, not how long CloudFront caches them, so stale content persists. It is tempting because signed URLs are a real CloudFront access-control feature, and they would be correct when restricting private content distribution rather than refreshing cached objects.

Enable compression on the S3 bucket.

Why it fails: S3 compression reduces object transfer size; it does not affect CloudFront's cached copies or their expiry, so users still receive outdated content. It is tempting because compression is a legitimate S3 and CloudFront optimisation, but it would be the right choice for reducing bandwidth, not for cache freshness.

Reduce the TTL to 0 in the CloudFront distribution.

Why it fails: Setting the minimum TTL to 0 still lets CloudFront serve cached objects until the origin's Cache-Control max-age expires, so stale content remains. It is tempting because TTL governs caching, but the correct fix is invalidating objects or setting the origin's cache headers to no-cache.

Store static assets in a public S3 bucket.

Why it fails: A public S3 bucket exposes static assets to anonymous internet access, removing an access-control layer rather than adding one, which contradicts defence in depth. It is tempting because S3 and CloudFront commonly serve static content, and a public bucket would be the right choice for a deliberately public website hosting openly distributable assets.

Place EC2 instances in public subnets for easier management.

Why it fails: Public subnets give instances routable addresses and a path to the internet gateway, exposing them directly and bypassing the ALB as the sole ingress point. It is tempting because public subnets simplify SSH administration and outbound patching, and they would be correct for bastion hosts or NAT instances that genuinely require public addressing.

Allow direct internet access to the EC2 instances.

Why it fails: Allowing direct internet access to the EC2 instances creates a second ingress path that circumvents the ALB's listener rules, TLS termination and WAF integration. It is tempting because direct access simplifies troubleshooting and deployment, and it would be correct for instances that must receive traffic independently of a load balancer.

Replace the ALB with a Network Load Balancer and associate an ACM certificate with it.

Why it fails: NLB with TLS listener can use ACM, but it's not a direct replacement and may require additional configuration.

Change the ALB listener to TCP and use a self-signed certificate on the EC2 instances.

Why it fails: TCP listener does not terminate TLS; encryption would be end-to-end but requires instance-level configuration.

Place a CloudFront distribution in front of the ALB and configure HTTPS between viewers and CloudFront.

Why it fails: While possible, it adds unnecessary complexity and cost.

Elastic Load Balancing

Why it fails: Elastic Load Balancing distributes traffic across targets within a Region; it provides no global anycast routing or edge absorption of volumetric DDoS. It is tempting because it fronts web applications, but that suits regional traffic distribution, not global entry, where Amazon CloudFront with AWS Shield fits.

AWS Global Accelerator

Why it fails: Global Accelerator improves performance by routing traffic over the AWS network but does not cache content or provide the same DDoS protection as CloudFront.

Amazon Route 53

Why it fails: Amazon Route 53 resolves DNS names to endpoints; it does not proxy traffic, cache content at edge locations, or absorb DDoS at the network edge. It is tempting because it offers latency-based routing, but that suits DNS resolution, not traffic entry, where Amazon CloudFront with AWS Shield fits.