Cloudfront practice questions

AWS Secrets Manager

Why it fails: Secrets Manager is designed to manage database credentials, API keys, and other sensitive configuration strings. It does not provide the specialized infrastructure required to serve SSL/TLS certificates for public-facing load balancers. While you could store certificates here, it lacks the integration to automatically attach them to an ALB.

AWS Key Management Service (KMS)

Why it fails: KMS is primarily used for creating and controlling cryptographic keys used to encrypt data at rest within various AWS services. It is not intended for managing public SSL/TLS certificates used for identity verification and encryption in transit for web traffic, as it lacks public certificate authority trust.

IAM Server Certificate Upload

Why it fails: Uploading certificates to IAM is a legacy method used primarily for specific AWS services that do not support ACM integration. It requires manual tracking of certificate expiration dates and manual replacement, making it an operationally inefficient and insecure practice for modern ALB deployments when ACM is available.

Manually add more Aurora Replicas during peak hours.

Why it fails: Manual intervention is inefficient and prone to human error, often resulting in delayed responses to traffic spikes. While adding replicas increases read capacity, doing so manually does not provide the elasticity required for unpredictable workloads. This approach leads to either performance bottlenecks during sudden surges or wasted costs when traffic levels drop.

Increase the instance size of the primary Aurora instance.

Why it fails: Scaling up the primary instance increases the overall cost and may cause downtime during the modification process. While a larger instance provides more resources, it does not specifically address the need for distributed read capacity. Using multiple read replicas is a more effective strategy for handling high-volume read traffic than vertical scaling alone.

Use Amazon SQS to buffer incoming read requests.

Why it fails: Amazon SQS is a message queuing service intended for asynchronous processing and decoupling components, not for caching or buffering synchronous database read requests. Implementing SQS for read traffic would introduce significant latency and architectural complexity. It is not a suitable solution for improving the performance of a real-time, read-heavy relational database application.

Amazon CloudFront.

Why it fails: Amazon CloudFront is a Content Delivery Network (CDN) optimized for caching and delivering HTTP/S content. While it can improve performance for web traffic, it does not support UDP-based protocols. For gaming applications using custom UDP packets, CloudFront is not a viable solution for improving end-to-end network performance and latency.

Amazon Route 53 with Geolocation routing.

Why it fails: Route 53 Geolocation routing helps direct users to specific endpoints based on their geographic location. However, once the DNS resolution is complete, the actual application traffic still travels over the public internet to reach the destination. It does not provide the network path optimization or static IP benefits offered by Global Accelerator.

AWS Direct Connect.

Why it fails: AWS Direct Connect establishes a dedicated private network connection between a customer's on-premises data center and AWS. It is not designed for improving the performance of individual end-users (players) distributed across the globe. It is a site-to-site connectivity solution and does not address the requirement for a global, low-latency application entry point.

The S3 bucket is in a different region than the EC2 instances.

Why it fails: While cross-region S3 access can increase latency and costs, it would not result in a 403 Forbidden error due to this specific policy unless the VPC Endpoint itself is region-specific. The primary issue here is the logical denial based on the source VPC endpoint ID.

The IAM role assigned to the EC2 instances lacks S3:GetObject permissions.

Why it fails: The prompt states that users have the 'correct IAM permissions.' Even if IAM permissions were granted, the explicit Deny in the bucket policy for non-matching VPC endpoints would take precedence, making the IAM permissions irrelevant until the networking path is corrected to use the endpoint.

The S3 bucket has Object Lock enabled, preventing data retrieval.

Why it fails: S3 Object Lock is used to prevent objects from being deleted or overwritten for a fixed amount of time. It does not prevent users from downloading or reading objects (GetObject). Therefore, Object Lock would not cause a 403 Forbidden error for standard read operations.

Data is preserved when the instance is stopped and started.

Why it fails: Data in an instance store volume is lost when the instance is stopped, terminated, or if the underlying hardware fails. This ephemeral nature is a key distinction from EBS, which persists data independently of the instance's lifecycle, necessitating a different strategy for data durability.

Volumes can be detached and reattached to different instances.

Why it fails: Unlike EBS volumes, which are network-attached and can be moved between instances, instance store volumes are fixed to a specific host. They cannot be detached or moved, which limits their flexibility but contributes to their superior local I/O performance characteristics.

Storage capacity can be increased without stopping the instance.

Why it fails: The size of the instance store is determined by the EC2 instance type and cannot be modified. If more instance store capacity is needed, the application must be migrated to a larger instance type, whereas EBS volumes allow for dynamic resizing via Elastic Volumes.

Enable DynamoDB Streams and use Lambda to update ElastiCache.

Why it fails: While this approach can work for caching, it involves significant architectural complexity and development effort. The application would need to manage cache invalidation and consistency manually, whereas DAX provides a seamless, API-compatible caching layer that requires no code changes.

Increase the Provisioned Read Capacity Units (RCUs) for the table.

Why it fails: Increasing RCUs allows for a higher volume of requests but does not inherently reduce the latency of an individual request. DynamoDB's native latency is typically in the single-digit to low-double-digit millisecond range, which is still slower than the microsecond latency provided by DAX.

Use Global Tables to replicate data closer to the application nodes.

Why it fails: Global Tables reduce latency for users in different geographic regions by providing local endpoints. However, if the application and the database are already in the same region, Global Tables will not reduce the base latency of DynamoDB below its standard millisecond range.

Configure the Application Load Balancer to use stickiness with a duration-based cookie.

Why it fails: Duration-based cookies rely on the specific instance remaining healthy. If the instance is terminated by the Auto Scaling group during a scale-in event, the session data stored in memory is permanently lost, and the user will be forced to re-authenticate, providing no true state protection.

Store the session state in an Amazon S3 bucket with versioning enabled.

Why it fails: Amazon S3 is designed for object storage and introduces significant latency for session-based read/write operations compared to in-memory stores. Using S3 for high-frequency session updates is inefficient and performance-prohibitive for web applications requiring low-latency access to user state information.

Replicate the session data across all EC2 instances using a broadcast script.

Why it fails: Broadcasting session data across instances creates a synchronization bottleneck and increases network overhead significantly. This approach is not scalable, prone to race conditions, and does not handle the dynamic nature of an Auto Scaling group effectively as new instances would require full state replication.

It allows all users to retrieve objects from the bucket if they are using any IP address.

Why it fails: The inclusion of the 'IpAddress' condition explicitly limits the scope of the permission. If a user tries to access the bucket from an IP address outside the defined range, the request will be denied. This policy is restrictive rather than permissive for all global traffic.

It denies access to anyone from the 192.0.2.0/24 range and allows everyone else.

Why it fails: The policy uses an 'Allow' effect with a condition that must be met. Therefore, it permits access only for the specified IP range. It does not deny the specified range nor does it grant broad access to the rest of the internet; it effectively creates an IP-based allowlist.

It grants full administrative access to the bucket for the 192.0.2.0/24 IP range.

Why it fails: The policy only grants the 's3:GetObject' action. It does not grant administrative actions like 's3:DeleteBucket', 's3:PutObject', or 's3:PutBucketPolicy'. Administrative access requires a wider set of permissions than what is defined in the action list, so this is not a full administrative policy.

Configure the Application Load Balancer to use source IP stickiness.

Why it fails: Source IP stickiness ties a client to a specific backend instance. If that instance fails or the Auto Scaling group terminates it, the session state is lost. This approach creates a dependency on individual instance health, violating the principle of designing stateless, resilient application tiers.

Use Amazon EBS multi-attach to share session files across instances.

Why it fails: EBS volumes can only be attached to instances within the same Availability Zone. If the AZ fails, the data becomes inaccessible, creating a single point of failure. Furthermore, file-based locking mechanisms are inefficient and prone to corruption in high-concurrency environments compared to dedicated caching services.

Replicate session files using a cron job across all web instances.

Why it fails: Replicating files via cron jobs introduces significant latency and synchronization challenges. As the number of instances grows, the overhead of maintaining consistency becomes unmanageable and error-prone. This design lacks the robustness and sub-millisecond performance required for modern, scalable, and resilient cloud-native web applications.

Support for multi-threaded execution.

Why it fails: Redis is primarily a single-threaded engine for command execution, although recent versions have introduced some background threading for I/O. Memcached is typically the choice for multi-threaded performance, but it lacks the complex data structures and high availability features like Multi-AZ and replication required in this scenario.

Automatic data compression at the cache level.

Why it fails: Amazon ElastiCache does not provide native automatic data compression at the service level. Compression is typically handled by the application code before the data is sent to the cache. Relying on the cache for compression would introduce unnecessary latency and CPU overhead on the cache nodes.

Use of UDP protocol for low-latency writes.

Why it fails: Redis uses the TCP protocol to ensure reliable delivery of data and commands. While UDP can be faster in some networking contexts, it is not supported by ElastiCache for Redis because reliability and data integrity are paramount for a persistent data store and caching engine.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is primarily focused on protecting applications against Distributed Denial of Service (DDoS) attacks at Layers 3, 4, and 7. While it includes AWS WAF at no extra cost, WAF itself is the specific service that provides the filtering for SQL injection and XSS attacks.

Amazon GuardDuty

Why it fails: Amazon GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior across your AWS accounts and workloads. It can detect compromised instances or unusual API calls, but it is not an inline firewall capable of blocking SQL injection or XSS in real-time.

Amazon Inspector

Why it fails: Amazon Inspector is an automated vulnerability management service that scans EC2 instances, container images, and Lambda functions for software vulnerabilities and unintended network exposure. It is a proactive scanning tool rather than a reactive firewall for blocking incoming web-based attacks like SQL injection or XSS.

Store sessions in a local file on the web server.

Why it fails: Storing sessions locally makes the application stateful, preventing easy horizontal scaling. If a user is routed to a different server due to load balancing, their session will be lost. This is a significant anti-pattern for scalable, distributed web applications and results in poor user experiences.

Store sessions in a relational database like RDS.

Why it fails: Storing session data in a relational database is slow due to disk I/O and query overhead. As session volume increases, the database becomes a bottleneck for the entire application. In-memory storage like ElastiCache is specifically designed for this type of high-frequency, low-latency access requirement.

Use sticky sessions on the Application Load Balancer.

Why it fails: Sticky sessions force a user to connect to the same backend instance. While this solves the session issue, it creates uneven load distribution and prevents the application from truly scaling horizontally. If an instance fails, the session is lost. It is less robust than using external session storage.

Use a Simple Scaling Policy with a large cooldown period.

Why it fails: Simple scaling policies are less responsive than target tracking because they wait for a specific alarm and cooldown period before taking further action. Large cooldown periods can lead to performance degradation during rapid traffic spikes because the system cannot add new instances quickly enough to meet demand.

Provision IOPS (io2) for all EC2 root volumes.

Why it fails: While provisioned IOPS improve disk performance, they do not address the scaling requirements of a web application facing traffic spikes. Root volumes for web servers typically do not require high IOPS for request handling; instead, the bottleneck is usually CPU, memory, or network bandwidth.

Implement vertical scaling by increasing instance sizes manually.

Why it fails: Vertical scaling requires stopping and starting instances to change their size, which causes downtime and is not a viable strategy for handling unpredictable traffic spikes. Horizontal scaling through Auto Scaling is the preferred AWS architecture for ensuring high performance and availability for web applications.

Amazon S3 Cross-Region Replication.

Why it fails: S3 Cross-Region Replication is used for data redundancy and disaster recovery, not for content delivery. It does not provide the performance-optimized edge location delivery that CloudFront offers. Users would still need to access regional S3 endpoints, which would be slower than fetching from a nearby CloudFront edge location.

AWS Global Accelerator.

Why it fails: Global Accelerator is designed to optimize the path to your applications running on EC2 or Load Balancers by using the AWS global network. It is not designed to cache static content. CloudFront is the correct service for static content delivery, whereas Global Accelerator is for general network traffic and non-HTTP protocols.

Amazon Route 53 Geolocation Routing.

Why it fails: Route 53 Geolocation routing helps direct users to specific resources based on their location, but it does not cache or distribute the content itself. It is a traffic management tool. Without an underlying delivery mechanism like CloudFront, the actual data retrieval speed would still be limited by the origin server location.

Update the IAM policy to include s3:ListBucket.

Why it fails: Adding s3:ListBucket only allows the application to view the contents of the bucket. It does not address the underlying performance issue related to network latency or data transfer speeds. IAM permission changes do not impact the underlying network throughput between the EC2 instance and the S3 service.

Deploy an Amazon CloudFront distribution in front of the S3 bucket.

Why it fails: CloudFront uses edge locations to cache content, drastically reducing the latency for S3 object retrieval. For high-performance requirements, caching data closer to the compute source provides much faster response times than standard S3 requests, effectively mitigating network congestion and latency issues encountered during high-frequency data access.

Change the S3 bucket storage class to S3 Intelligent-Tiering.

Why it fails: Storage classes relate to cost management and data lifecycle policies, not performance. Changing the storage class does not influence the network latency or retrieval speeds of the files themselves. Performance optimization requires architectural changes to the delivery mechanism, such as caching or improved network routing, not storage class.

Increase the DefaultTTL and MinTTL values.

Why it fails: Increasing TTL values determines how long an item stays in the cache once it is already there. However, if every request is treated as unique due to the query string configuration, the items will never be reused regardless of how long their expiration time is set.

Set CookieBehavior to 'all' to include session data.

Why it fails: Including all cookies in the cache key would actually further decrease the cache hit ratio. Since cookies often contain unique session IDs or user-specific data, caching based on them would ensure that almost every request is treated as a unique object, putting even more stress on the origin.

Enable HeaderBehavior for the 'Host' header.

Why it fails: Forwarding headers and including them in the cache key generally reduces the cache hit ratio because it adds another variable that must match for a cache hit. While the Host header is often necessary for multi-site origins, it would not solve the specific performance issue caused by query strings.

AWS Shield Standard.

Why it fails: AWS Shield Standard provides protection against Layer 3 and Layer 4 DDoS attacks. It does not provide Layer 7 protection against SQL injection or XSS. While useful, it is not the correct tool for addressing application-level web exploits, which require the deep packet inspection capabilities provided by AWS WAF.

Amazon GuardDuty.

Why it fails: GuardDuty is a threat detection service that monitors logs for suspicious activity, such as malicious API calls or compromised instances. It does not actively block web exploits in real-time at the application layer. While it can detect an ongoing attack, it is not an inline firewall solution like WAF.

Network ACLs.

Why it fails: Network ACLs operate at the network layer (Layer 3/4) by controlling traffic based on IP addresses and ports. They lack the intelligence to inspect the content of HTTP/HTTPS requests to identify SQLi or XSS patterns. Therefore, they are insufficient for protecting against application-layer exploits as requested in the scenario.

Enable S3 Transfer Acceleration on the bucket.

Why it fails: S3 Transfer Acceleration is designed to speed up uploads to S3, not downloads or static website hosting for end users. It utilizes the AWS edge network to ingest data into the AWS network, which is useful for large file transfers but does not optimize website content delivery performance.

Configure the S3 bucket to use Multi-Region replication.

Why it fails: Multi-Region replication is used for disaster recovery and data compliance, not for content delivery performance. While it keeps data in different regions, it does not provide a mechanism to deliver that content to the end user with low latency, as CloudFront does through edge location caching.

Upgrade the S3 storage class to S3 Intelligent-Tiering.

Why it fails: S3 storage classes are meant for cost optimization based on access patterns, not for performance enhancement. Moving between storage classes does not impact the speed at which files are served to users. Performance is primarily driven by how close the content is to the user, which CloudFront manages.

Deploy all instances in one AZ and use a Route 53 failover policy to a secondary region.

Why it fails: Relying on a single AZ creates a single point of failure within the region, violating high availability requirements. While multi-region failover provides disaster recovery, it does not address the need for low-latency, resilient local traffic distribution between AZs as requested by the architectural design scope.

Use an Auto Scaling group with a single AZ and enable Cross-Zone Load Balancing on the ALB.

Why it fails: Cross-zone load balancing distributes traffic across instances in multiple AZs, but if the single AZ fails, the entire application becomes unavailable. Resilience requires distributing instances across multiple physically separate AZs to ensure that infrastructure failures in one location do not impact the overall application availability.

Use a Network Load Balancer (NLB) with static IP addresses for each instance in one AZ.

Why it fails: Static IP addressing provides reachability but does not provide fault tolerance if the AZ housing the instances suffers a failure. Resilience is achieved by decoupling the traffic entry point from specific compute locations, allowing the architecture to survive the loss of an entire data center facility.