SAA-C03 (SAA-C03) — Questions 76–150

Leaving ACLs enabled contradicts the requirement to eliminate ACL management, and ACLs do not restrict access by prefix—they grant permissions on individual objects, which is not scalable for multiple producers and teams.

In a scenario where objects are uploaded by a single producer and each object needs individual permissions (e.g., a shared bucket with per-object access control for different users), and the company is willing to manage ACLs.

Candidates may think ACLs provide a straightforward way for producers to control access to their uploaded objects, overlooking the management overhead and the requirement to avoid ACLs.

Amazon EFS provides a shared file system, but the question specifies scratch data for a single instance that benefits from very high local I/O throughput. EFS is network-attached and has higher latency than local storage, making it unsuitable for high local I/O needs.

Amazon S3 is designed for durable, highly available object storage with high latency, not for high local I/O throughput scratch space. It cannot provide the very high local I/O performance required for temporary scratch data.

A question where multiple instances need to concurrently access and share temporary files with low administrative overhead, and the workload can tolerate network latency. For example, a distributed data processing job that requires a common scratch space across nodes.

A scenario where the workload requires durable, scalable, and accessible storage for data that must persist across instance terminations and be shared across multiple applications or regions, such as storing backup files or static website assets.

Candidates may think a shared file system is beneficial for any temporary data, overlooking that the question emphasizes local I/O throughput and single-instance scratch space, not multi-instance sharing.

Candidates may think S3's durability and accessibility make it suitable for any data, overlooking the specific need for high local I/O throughput and the tolerance for data loss in this scratch data use case.

Adding a GSI for every frequently viewed attribute does not reduce read latency for repeated reads of the same items; it adds storage and write costs without addressing the latency caused by repeated reads from disk.

Switching to on-demand capacity mode addresses throughput provisioning, not read latency. Latency issues from repeated reads are better solved by caching, not capacity mode changes.

Moving to Aurora and using read replicas is a much more disruptive change than enabling DAX, and it does not address the core issue of caching frequently accessed items in memory for low-latency reads. Aurora is a relational database, not a key-value store like DynamoDB, and the question specifies the team wants the least disruptive change.

A question where the app needs to query items by non-key attributes (e.g., filtering or sorting by product category) and the current table key does not support those access patterns efficiently.

A DynamoDB table experiences frequent throttling errors due to unpredictable traffic spikes, and the team wants to avoid manual capacity management. On-demand capacity mode would be correct to automatically scale throughput.

This option would be correct in a scenario where the application requires complex SQL queries, joins, or transactions that DynamoDB cannot support, and the team is already considering migrating to a relational database. For example: 'A company needs to run complex analytical queries on product catalog data and requires high availability across multiple regions.'

Candidates may think that indexing more attributes will speed up reads, but GSIs are for alternative query patterns, not for caching repeated reads of the same items.

Candidates may confuse throughput provisioning with latency optimization, assuming that 'on-demand' automatically reduces latency by scaling instantly.

Candidates may think that moving to a more powerful database like Aurora with read replicas will solve latency issues, especially if they are more familiar with relational databases than DynamoDB caching solutions. They might also overestimate the disruption of enabling DAX compared to a full database migration.

Reserved Instances require a 1-year commitment and are cost-effective only for steady-state, predictable workloads. The nightly ETL job runs only 2-4 hours per day, so the discount does not offset the cost of paying for 24/7 reserved capacity, making it more expensive than Spot Instances.

Auto Scaling does not reduce cost; it adds more instances, increasing cost. The job already runs within the deadline, so scaling out is unnecessary and more expensive.

Disabling checkpointing removes the ability to resume from the last checkpoint on interruption, which is critical for Spot Instances that can be terminated at any time. Without checkpointing, the job would have to restart from scratch, likely missing the 7:00 AM deadline.

A company runs a 24/7 web server fleet with consistent baseline usage. They need to reduce costs for the always-on instances and can commit to a 1-year or 3-year term. Reserved Instances would provide a significant discount over On-Demand for this steady-state workload.

A question where the ETL job is at risk of missing a tight deadline due to variable runtime, and cost is not the primary concern. For example: 'A batch job must complete within 1 hour, but often takes 90 minutes on a single instance. Which change ensures it finishes on time?'

If the ETL job were idempotent and very short (e.g., under 5 minutes), or if checkpointing introduced unacceptable overhead, then disabling it might be acceptable. For example, a simple data transformation that runs in under 5 minutes and can be safely restarted without data loss.

Candidates know Reserved Instances offer discounts and may assume any usage benefits, overlooking that the discount applies only to the reserved capacity, which is wasted when the instance is idle for most of the day.

Candidates may think Auto Scaling always reduces cost by optimizing resource usage, but here it would increase cost by adding instances without need.

Candidates may think simplifying the application by removing checkpointing reduces complexity and overhead, not realizing that checkpointing is essential for fault tolerance with Spot Instances to meet deadlines.

Replacing instances with a larger family increases headroom but does not dynamically adjust capacity based on actual traffic patterns, leading to overprovisioning during off-peak hours and not specifically addressing latency during peak traffic.

Scheduled scaling adds instances only during a fixed time window, but peak traffic may vary day-to-day or occur outside business hours, leading to either underprovisioning or overprovisioning. It does not dynamically adapt to actual traffic patterns.

Replacing the ALB with a Network Load Balancer reduces latency at the network layer but does not address the root cause of latency during peak traffic, which is insufficient compute capacity. The question asks for a change to reduce latency without overprovisioning, and NLB does not affect the fleet's ability to handle request load.

This would be correct if the question asked for a solution to improve performance for a consistently high-traffic application where the current instance type is underpowered, and cost is not a primary concern.

If the question states that traffic spikes are predictable and occur at the same time every day (e.g., a known business hours peak), and the goal is to ensure capacity is ready exactly when needed without relying on dynamic scaling metrics, then scheduled scaling would be the best choice.

In a scenario where the application is latency-sensitive at the transport layer (e.g., for UDP traffic or extreme low-latency requirements) and the ALB's processing overhead is the bottleneck, replacing it with an NLB would be correct. The question would specify that compute capacity is adequate and the latency issue stems from the load balancer itself.

Candidates may think larger instances inherently reduce latency by providing more resources, overlooking that this approach wastes capacity during low traffic and doesn't adapt to variable demand.

Candidates may think scheduled scaling is a simple, cost-effective way to handle peak traffic, overlooking that it cannot adapt to variable or unexpected load, and that the question emphasizes 'without overprovisioning' which requires dynamic adjustment.

Candidates may think that any latency reduction is beneficial and assume a faster load balancer directly solves peak traffic latency, overlooking that the real issue is insufficient instances to handle request volume.

On-Demand Instances are the most expensive option for steady, 24/7 workloads, as they lack the discounts of committed-use plans. The question specifically asks for the lowest cost, so On-Demand does not meet that requirement.

Standard Reserved Instances lock you into a specific instance type and Availability Zone, which contradicts the requirement to choose different instance families in the future without re-buying compute discounts.

Spot Instances can be interrupted with a 2-minute notice, making them unsuitable for a steady, continuous 24/7 workload that must run without interruption.

On-Demand Instances would be correct for a question where the workload is unpredictable, short-term, or variable, and the priority is maximum flexibility with no upfront commitment, such as for a new application with unknown usage patterns.

A company has a predictable, steady workload that requires a specific instance type and is willing to commit to an Availability Zone for maximum discount, and does not need flexibility to change instance families.

For a fault-tolerant, stateless application that can handle interruptions (e.g., batch processing, big data, or containerized workloads) and where the lowest possible compute cost is desired, Spot Instances would be the correct choice.

Candidates may think On-Demand is the simplest and most flexible choice, and they might overlook the cost savings of committed-use plans for steady workloads, focusing only on the flexibility aspect mentioned in the option.

Candidates may assume Reserved Instances always offer the best savings for steady workloads, overlooking the flexibility limitations that make Compute Savings Plans more suitable here.

Candidates may assume Spot Instances are always the cheapest option and overlook the interruption risk, focusing only on cost without considering the workload's need for continuous availability.

Single-AZ RDS with manual backup restoration does not provide automatic failover; it requires manual intervention and incurs significant downtime, failing the requirement for automatic failover within the same Region.

A read replica is not designed for automatic failover; promoting it requires manual intervention or additional scripting, which does not meet the 'automatically fail over' requirement with minimal application changes.

Multi-AZ disabled means no automatic failover; increasing IOPS improves performance but does not provide high availability across AZs, so it fails the requirement of automatic failover during an AZ failure.

If the requirement were to minimize costs and allow for some data loss (RPO of hours) and downtime (RTO of hours), with no need for automatic failover, then a single-AZ instance with periodic backups would be acceptable.

This option would be correct if the requirement was to offload read traffic from the primary database and have a standby for manual failover in a disaster recovery scenario, where some downtime is acceptable and application changes are allowed.

If the requirement were to improve database performance for a read-heavy workload without needing automatic failover, increasing IOPS on a single-AZ instance would be correct.

Candidates may think that restoring from backups is a valid disaster recovery method, but they overlook the requirement for automatic failover with minimal application changes.

Candidates may think a read replica in a different AZ provides automatic failover similar to Multi-AZ, but they overlook that read replicas require manual promotion and do not provide automatic, seamless failover.

Candidates may confuse performance improvements (IOPS) with availability features, thinking that faster storage can compensate for lack of redundancy.

IAM user access keys are long-term credentials and do not solve cross-account access; the app in account A needs to assume a role in account B, not use a user with a policy attached directly.

Option C grants s3:PutObject to all principals in account A, which violates least privilege by not restricting to the specific app role, and it does not address the missing trust relationship needed for cross-account access via role assumption.

The problem is lack of cross-account trust, not an SCP. SCPs deny actions at the OU/account level but don't grant permissions; they would only block access if already allowed, and here no trust exists.

If the question asked for a solution where a single IAM user in account A needs to upload objects to an S3 bucket in account B without using roles, and the bucket policy allows access based on user ARN, then creating access keys for that user and attaching the necessary permissions would be correct.

This option would be correct if the question stated that the app in account A uses an IAM user with programmatic access keys (not a role) and the requirement is to allow that user to write to the bucket without assuming a role, using a bucket policy that grants access to the entire account A.

An SCP denying sts:AssumeRole unless MFA is used would be correct in a question where an organization wants to enforce MFA for all cross-account role assumptions, and the issue is that a role is being assumed without MFA.

Candidates may think that attaching a policy to access keys is a straightforward way to grant permissions, overlooking the cross-account nature of the problem and the need for role assumption.

Candidates may think a bucket policy is the simplest way to grant cross-account S3 access, overlooking that the app's IAM role still needs explicit permission to assume a role in account B, and that a bucket policy alone does not replace the need for a trust relationship.

Candidates may confuse SCPs with IAM policies or think that any denial of access can be fixed by adding a deny statement, not realizing SCPs are a guardrail, not a solution for missing trust relationships.

EBS multi-attach does not support attaching a single volume to instances across different Availability Zones; it only works within a single AZ. Therefore, cross-AZ tasks cannot share the same EBS volume.

S3 does not provide a POSIX-compliant shared filesystem with low-latency file locking and immediate consistency needed for streaming intermediate artifacts between tasks; it is an object store, not a filesystem.

Instance store is ephemeral and not shared across tasks, so tasks in different AZs cannot access a common filesystem. SQS message copying adds latency and complexity, failing the low-latency shared filesystem requirement.

If all ECS tasks are running in the same Availability Zone and require a shared block storage with low latency and consistent performance, EBS multi-attach would be the correct choice for a shared filesystem.

A question where the requirement is to store and process large volumes of static artifacts with event-driven workflows, and low-latency shared filesystem access is not needed. For example: 'A data pipeline processes uploaded images and triggers a Lambda function to generate thumbnails.'

A question where tasks need high-speed local scratch storage and can tolerate eventual consistency, such as a batch processing job that processes independent chunks and only needs to aggregate results via a queue.

Candidates may think EBS multi-attach provides cross-AZ sharing similar to EFS, but they overlook the single-AZ limitation of EBS multi-attach.

Candidates may think S3 can serve as a shared filesystem due to its durability and event notifications, overlooking the need for low-latency POSIX semantics and concurrent file access.

Candidates may think instance store offers high performance and SQS can coordinate file transfers, overlooking that instance store is ephemeral and not shared, and that SQS cannot provide a POSIX filesystem.

AWS Config does not generate GetObject logs; it tracks resource configuration changes and compliance, not data plane operations like S3 object access.

VPC Flow Logs capture IP traffic metadata (source/destination IP, ports, protocol) but do not log S3 API operations like GetObject or PutObject; they lack object-level details.

Denial events from a bucket policy that denies GetObject requests do not provide visibility into successful object access or writes; they only log denied attempts, not the actual GetObject or PutObject operations needed for detective controls.

A question asking how to automatically detect and alert on S3 bucket policies that allow public access or are noncompliant with security standards, using AWS Config rules.

A question asking for network-level visibility into traffic to/from an S3 gateway endpoint (e.g., to detect unusual data transfer volumes or IP addresses) would make VPC Flow Logs the correct answer.

If the question asked for a method to enforce encryption in transit for S3 access and log any non-compliant requests for security auditing, then adding a bucket policy that denies GetObject unless TLS is used would be correct, as it generates denial logs for non-TLS requests.

Candidates may confuse AWS Config's compliance monitoring with logging capabilities, thinking it can produce object-level access logs when it only evaluates configuration states.

Candidates may confuse network traffic logs with application-level API logs, assuming that all data movement is captured at the network layer, or they may overestimate the granularity of VPC Flow Logs.

Candidates may think that any policy action that generates logs provides visibility, but they overlook that detective controls require logging of successful operations, not just denials.

Spread placement groups are designed to reduce correlated failures by placing instances across distinct hardware, but they do not provide the low-latency, high-bandwidth network performance required for microsecond-level latency. Additionally, placing instances across multiple Availability Zones increases network distance and latency.

Partition placement groups are designed to reduce correlated hardware failures for large distributed workloads like HDFS or Cassandra, not to minimize network latency. They do not provide the low-latency, high-bandwidth network performance required for microsecond-level inter-node communication.

An Application Load Balancer (ALB) operates at Layer 7 and introduces significant latency (milliseconds), which is unacceptable for microsecond-sensitive trading. It also distributes traffic across AZs, increasing latency further.

A question requiring high availability and fault isolation for a small number of critical instances, such as a distributed application that must survive an Availability Zone failure, where low latency is not the primary concern.

A question asks for a fault-tolerant deployment for a large-scale data processing job (e.g., Hadoop or Kafka) that must tolerate rack-level failures while still providing some network isolation. Partition placement groups spread instances across logical partitions, each with its own rack, to reduce the impact of a single rack failure.

For a web application requiring high availability, fault tolerance, and automatic scaling across multiple Availability Zones, with traffic distributed at the application layer (e.g., HTTP/HTTPS).

Candidates may think that spreading instances across multiple Availability Zones improves both fault tolerance and performance, but they overlook that this increases latency, which is unacceptable for latency-sensitive applications.

Candidates may confuse partition placement groups with cluster placement groups, assuming both offer low latency, or they may think that any placement group within one AZ improves network performance, overlooking the specific design goals of each type.

Candidates may think load balancing always improves performance and availability, overlooking the extreme low-latency requirement that makes ALB's overhead unsuitable.

Option B is wrong because cross-account KMS access requires the key policy in the key-owning account (Company A) to explicitly grant permissions to the external principal (Company B's role). Without that, Company B's IAM policy alone cannot authorize KMS actions on Company A's key.

Using a KMS key from Company B would not allow Company A to decrypt the objects, as Company A's S3 bucket is configured with its own key for SSE-KMS. The partner application must use Company A's key to encrypt objects so that Company A can decrypt them.

Removing all policy statements from the KMS key disables all access control, making the key effectively public and insecure. This violates the principle of least privilege and is not a secure solution.

This option would be correct if the KMS key policy in Company A already allowed Company B's account or role to use the key, but the partner role lacked the necessary IAM permissions. In that case, adding the KMS actions to Company B's IAM policy would resolve the access denial.

This option would be correct if the requirement was for Company A to access objects encrypted by Company B using Company B's key, and Company A's bucket policy grants cross-account access with appropriate KMS permissions. For example, if Company A needs to retrieve logs that Company B encrypts with its own key and shares via S3 cross-account access.

If the question asked for the quickest way to allow all principals to use the key without any security considerations, or if the key was intended to be fully public (e.g., for a public demo environment with no sensitive data), then disabling key policy restrictions might be acceptable.

Candidates may assume that IAM policies in the partner account are sufficient for cross-account access, overlooking that KMS key policies are resource-based and must explicitly grant access to external principals.

Candidates may think that using a key from the partner's account simplifies permissions by avoiding cross-account KMS policy changes, but they overlook that the S3 bucket's default encryption is tied to Company A's key, and Company A must be able to decrypt the data.

Candidates may think that removing restrictions is the simplest fix to resolve access denied errors, overlooking the severe security implications and the fact that KMS key policies are the primary mechanism for controlling cross-account access.

Application Load Balancer does not support TCP at the transport layer; it operates at Layer 7 (HTTP/HTTPS) and cannot handle custom TCP protocols. It also does not provide static IP addresses.

Amazon API Gateway does not support custom TCP protocols; it only handles HTTP/HTTPS and WebSocket traffic, and it does not provide static IP addresses at the load-balancing layer.

An Application Load Balancer would be correct for a web application requiring advanced HTTP/HTTPS routing (e.g., path-based or host-based routing) with SSL termination, where static IPs are not needed and clients use HTTP/HTTPS.

A question asking for a fully managed service to expose RESTful APIs or WebSocket endpoints with throttling, caching, and authentication, where the backend is an AWS service like Lambda or HTTP endpoints.

Candidates may assume ALB supports all protocols because it is a common load balancer, or they confuse its Layer 7 capabilities with Layer 4, overlooking the requirement for custom TCP and static IPs.

Candidates may think API Gateway can handle any protocol because it supports WebSocket, or they confuse its throttling and routing features with load balancing capabilities.

Keeping a fixed fleet with a higher minimum increases idle capacity and cost, as workers are idle most of the day. The goal is to reduce idle capacity, not increase it.

Reserved Instances require a 1- or 3-year commitment and are cost-effective only for steady-state workloads. The bursty, idle-most-day pattern means RIs would be wasted during idle periods, increasing cost without reducing idle capacity.

Processing uploads only during a nightly window does not reduce cost or idle capacity; it simply shifts the workload to a specific time, leaving the fleet idle for the rest of the day and potentially requiring larger capacity to handle the burst.

For a steady-state workload with predictable demand that requires consistent compute capacity, such as a 24/7 web server farm, a fixed fleet with a higher minimum in an Auto Scaling group ensures availability and performance.

A question where workers run a steady, predictable workload 24/7 (e.g., a real-time video transcoding pipeline with constant throughput). Reserved Instances would then provide significant cost savings over On-Demand.

This option would be correct if the question required meeting a compliance or business rule that all processing must occur during off-peak hours (e.g., to avoid interfering with other systems), and cost reduction was not the primary goal.

Candidates may think a fixed fleet simplifies management and ensures capacity, overlooking the bursty nature of the workload and the cost of idle resources.

Candidates know Reserved Instances reduce costs and may assume any cost-saving measure applies, overlooking that RIs are ill-suited for variable or bursty demand.

Candidates may think that batching work into a fixed window increases utilization and reduces idle time, but it actually concentrates demand, requiring more resources to handle the peak and leaving resources idle outside the window.

NACLs are stateless, not stateful; they do not automatically track connections. The issue is missing outbound ephemeral port rules in the NACL, not security group inbound rules for client source ports.

The question describes connection timeouts due to missing outbound NACL rules for ephemeral ports, not health check failures. ALB health checks are not mentioned as failing, and changing the health check port does not address the stateless NACL issue.

The issue is not about internet connectivity; instances are in private subnets but the ALB is in a public subnet and handles internet-facing traffic. A NAT gateway is for outbound internet access from private instances, not for fixing return traffic blocked by a stateless NACL.

This option would be correct if the question stated that NACLs are stateful and the security group was blocking return traffic. For example: 'An application uses a stateful firewall (like a security group) and clients see timeouts; what is the fix?'

In a scenario where an ALB target group health check is failing because the health check path or port is not configured correctly (e.g., the application listens on port 8080 but health check targets port 80), updating the health check to the correct port would resolve the issue.

In a scenario where EC2 instances in private subnets need to download updates from the internet, and the outbound NACL blocks ephemeral ports, adding a NAT gateway would be correct to allow outbound traffic and its return traffic.

Candidates may confuse NACLs with security groups, assuming NACLs are stateful like security groups, and think the fix involves adding inbound rules to the security group for client ports.

Candidates may confuse connectivity issues with health check misconfigurations, especially when ALB is involved, and assume that adjusting health check settings can fix general traffic flow problems.

Candidates may confuse network connectivity issues with internet access requirements, assuming private subnets always need a NAT gateway for any traffic flow, even when the traffic is internal to the VPC via an ALB.

S3 Transfer Acceleration speeds up uploads over long distances but does not protect against accidental deletion or overwrite, nor does it create a cross-region copy for disaster recovery.

Lifecycle policies to move objects to Glacier provide cost optimization for long-term storage, but do not protect against accidental overwrite/deletion or provide cross-region recovery.

Block Public Access prevents public access to S3 objects but does not protect against accidental overwrite or deletion by authorized users, nor does it provide cross-region replication for disaster recovery.

A company needs to upload large files from multiple global locations to a central S3 bucket and requires faster upload speeds. Enabling Transfer Acceleration would be the correct action to reduce upload latency.

An architect needs to reduce storage costs for infrequently accessed data that must be retained for compliance, with no requirement for immediate retrieval or cross-region redundancy.

An exam question where the requirement is to prevent public access to sensitive data stored in S3, such as financial records or personal information, and no other access controls are specified.

Candidates may confuse 'acceleration' with 'protection' or think it helps with replication, not realizing it only optimizes data transfer speed, not durability or availability.

Candidates may confuse lifecycle policies with data protection mechanisms, assuming moving to Glacier inherently secures data, or they may think Glacier's durability alone addresses the requirements.

Candidates may mistakenly think Block Public Access provides general data protection, confusing it with versioning or replication features that actually prevent overwrites and enable recovery.

Increasing Lambda timeout does not address database throttling or duplicate records; it only allows the function to wait longer, but the database will still throttle under load, and retries will still create duplicates.

SNS pushes messages to all subscribers immediately without buffering or throttling, so it does not help with database throttling or retry management; it would still overwhelm the database and cause duplicate processing.

Disabling retries entirely would cause order writes to fail permanently during throttling, losing data and increasing timeouts, which contradicts the need for safe retry behavior.

If the question were about handling a slow database that occasionally takes longer than the default Lambda timeout (e.g., 3 seconds) but never throttles, and idempotency is already handled, increasing the timeout would prevent timeouts.

A question where the goal is to fan out a single event to multiple downstream services (e.g., order placed triggers email, SMS, and analytics) and immediate delivery is acceptable, with no need for buffering or retry control.

In a scenario where duplicate processing is unacceptable and the system can tolerate occasional data loss (e.g., non-critical logging), and retries are handled externally (e.g., by a queue with DLQ), disabling Lambda retries prevents duplicate records.

Candidates think that giving Lambda more time will solve the throttling issue, but they overlook that the root cause is database capacity, not Lambda execution time.

Candidates may confuse SNS with SQS, thinking any messaging service provides buffering, or they may overvalue 'immediate delivery' without considering the need for decoupling and retry safety.

Candidates may think that disabling retries directly solves the duplication problem without considering that it also eliminates the ability to recover from transient failures, leading to data loss.

Keeping the bucket public allows anyone with the S3 URL to access thumbnails directly, bypassing CloudFront. Signed cookies control access via CloudFront but do not prevent direct S3 access, so this fails to meet the requirement.

Enabling S3 static website hosting exposes the S3 bucket via its website endpoint, allowing users to bypass CloudFront and access thumbnails directly, which violates the requirement to prevent direct access.

WAF rules at CloudFront can block certain requests but do not prevent direct access to the S3 bucket; users could still bypass CloudFront and access the bucket directly if the bucket policy allows it.

If the requirement were to restrict access to thumbnails while allowing both CloudFront and direct S3 access for authorized users, signed cookies (or signed URLs) could be used with a public bucket to control access at the CloudFront level, but the bucket itself would remain accessible.

This option would be correct if the requirement was to serve static content (e.g., a single-page application) directly from S3 without CloudFront, and the question asked for the simplest way to host a static website with public access.

In a scenario where the S3 bucket is already configured to allow only CloudFront access (e.g., via OAI/OAC) and the goal is to add an additional layer of security to block specific request patterns (e.g., SQL injection) at the CloudFront edge, a WAF rule would be appropriate.

Candidates may think signed cookies provide comprehensive access control, but they overlook that the bucket policy must also restrict direct access. The option seems to address user authentication without considering the need to block direct S3 access.

Candidates may confuse 'static website hosting' with a security feature, thinking it restricts access, or they may mistakenly believe it integrates with CloudFront to block direct access.

Candidates may think that a WAF rule at CloudFront can enforce access control globally, misunderstanding that WAF operates at the application layer and does not restrict network-level access to the S3 bucket.

Tuning health check settings does not address the root cause of tasks waiting for EC2 capacity; it only affects task stability, not instance availability.

Pinning tasks to a single Availability Zone does not address the root cause of insufficient EC2 capacity; it actually reduces fault tolerance and may increase placement constraints, making scaling slower.

Switching to Fargate eliminates EC2 scaling concerns but does not address the existing EC2 capacity scaling issue; the question specifically asks for faster scale-out of underlying EC2 capacity, not a migration to a different compute type.

If the question described tasks frequently failing health checks and being replaced, causing unnecessary scaling events, then tuning health check settings (e.g., increasing grace period or interval) would be the best first step to reduce churn.

If the question described a scenario where tasks are failing due to cross-AZ data transfer costs or latency, and the goal is to minimize network overhead, then pinning tasks to a single AZ could be correct.

This option would be correct in a scenario where the team wants to eliminate EC2 management entirely and is willing to migrate to serverless compute, such as when the primary goal is to reduce operational overhead and avoid scaling EC2 instances altogether.

Candidates may confuse task-level health issues with capacity scaling problems, assuming that fixing health checks will reduce the need for new instances.

Candidates may think that reducing the number of zones simplifies scheduling and speeds up placement, but they overlook that capacity shortage is the real issue, not placement overhead.

Candidates may choose this because Fargate abstracts infrastructure management, making it seem like a simple fix to avoid EC2 scaling problems, without recognizing that the question explicitly asks for a step to improve EC2 scaling, not replace it.

CloudFront is a content delivery network for caching and accelerating downloads, not uploads. It does not improve upload performance to an S3 bucket because uploads go directly to the origin, not through CloudFront.

Provisioned IOPS EBS volumes attached to a transfer server do not improve upload speeds to S3; they improve disk I/O for an intermediate server, but the bottleneck is network latency to S3, not local disk performance.

Amazon EFS is a shared file system for EC2 instances, not a direct upload destination for users. The question requires users to upload directly to S3, and EFS cannot replace S3 as the upload target.

A company needs to reduce latency for global users downloading static content (e.g., images, videos) from an S3 bucket. Enabling CloudFront would cache content at edge locations, improving download speeds and reducing load on the origin.

A question where an application requires high-performance, low-latency storage for a database or transactional workload running on a single EC2 instance, and the storage must meet specific IOPS requirements.

A company needs a shared file system accessible from multiple EC2 instances across different AWS regions for low-latency file access, with automatic scaling and high durability. Enabling EFS with mount targets in each region would be correct.

Candidates may assume CloudFront accelerates all data transfer (both upload and download) because it improves delivery speed, but it does not optimize the upload path to S3.

Candidates may think that faster local storage on a transfer server will speed up uploads, but the real issue is network distance to S3, not the server's disk speed.

Candidates may think that having EFS mount targets in multiple regions would reduce latency for uploads, but they overlook that EFS is not a direct upload endpoint for users and does not replace S3 for object storage.

Weighted routing requires manual weight adjustments during incidents, which contradicts the requirement for automated DNS-based failover without manual changes.

Latency-based routing does not support health checks; it routes based solely on latency, not availability. If the primary region fails but still has low latency, traffic would still be sent there, causing downtime.

This option requires manual IP updates during failure, which contradicts the requirement for automated DNS-based failover without manual changes.

A scenario where traffic needs to be distributed across multiple endpoints with controlled proportions, and manual adjustments are acceptable, such as gradually shifting traffic during a planned migration.

This option would be correct for a global application that requires optimal performance for users worldwide, where all endpoints are active and healthy, and the goal is to minimize latency without needing failover based on health.

If the question required a static IP for whitelisting and the application had a single-region deployment with a manual failover process to a backup IP, using a static A record updated manually could be acceptable.

Candidates may think weighted routing can be used for failover by setting weights to zero, but they overlook the need for automation and health checks.

Candidates may assume latency-based routing inherently avoids unhealthy endpoints because high latency could indicate issues, but Route 53 does not use health checks with latency routing, so it cannot detect failures.

Candidates may think a static IP simplifies DNS management and overlook the automation requirement, or they may confuse NAT gateway with a static endpoint for failover.

Increasing volume size does not address the 'first touch' latency caused by lazy loading of data from snapshot to S3; it only provides more storage capacity.

Moving database files to Amazon EFS after restore does not address the slow reads caused by lazy loading of data from EBS snapshots (snapshot hydration). EFS is a network file system with its own performance characteristics and does not eliminate the need to initialize EBS blocks.

Magnetic standard volumes (st1/sc1) also suffer from snapshot hydration delays and have lower baseline performance than gp2/gp3, making them unsuitable for avoiding slow reads on previously unused blocks.

A scenario where the database is running out of storage space and experiencing performance degradation due to insufficient IOPS or throughput, and increasing volume size would also increase the volume's baseline performance.

A scenario where the application requires shared access to the database files across multiple EC2 instances, or where the database needs to be accessed from different Availability Zones for high availability, and the performance impact of snapshot hydration is acceptable or mitigated by other means.

A question asks for the most cost-effective storage for a large, sequential-access data warehouse that is rarely accessed and can tolerate lower IOPS. Magnetic volumes would be correct due to their low cost per GB.

Candidates may think larger volumes inherently perform better or that more free space reduces fragmentation, but the issue is specifically about snapshot hydration delays, not capacity.

Candidates may think that using a different storage service like EFS, which is fully managed and scalable, could bypass the EBS snapshot hydration issue, not realizing that the problem is specific to EBS volumes restored from snapshots.

Candidates may think that older, simpler technology (magnetic) avoids the 'hydration' issue because they misunderstand that all EBS snapshots lazily restore blocks, regardless of volume type.

Enabling ALB stickiness does not address the root cause: the ASG has no healthy targets in the only AZ, so the ALB cannot route traffic to any instance, causing timeouts regardless of stickiness.

The issue is that EC2 instances are only in one AZ, so adding a NAT gateway does not provide healthy targets in the other AZ; NAT gateways enable outbound internet access but do not affect ALB target availability.

Creating a second ALB in the same AZ does not address the lack of healthy targets in the other AZ; the ALB is already spanning two AZs, but the ASG only has instances in one AZ. DNS failover would still route to the same AZ if both ALBs are in the same AZ, failing to provide resilience against an AZ failure.

This option would be correct in a scenario where the application is stateful and sessions are stored locally on instances, and the goal is to maintain session persistence to avoid data loss during normal operations (not AZ failure).

This option would be correct if the question described private subnets without internet access, and the EC2 instances needed to download updates or access external APIs for the application to function properly.

This option would be correct in a scenario where the ALB is only in one AZ and you need to achieve cross-AZ failover for the load balancer itself. For example, if the ALB is deployed in a single AZ and you want to ensure high availability by placing a second ALB in another AZ with DNS failover using Route 53.

Candidates may think stickiness helps during failures by keeping users on the same instance, but it does not solve the problem of having zero healthy targets in the only AZ.

Candidates may confuse network connectivity (NAT) with high availability, thinking that internet access is required for the ALB to route traffic to instances, or they may misattribute the timeout issue to a lack of outbound connectivity.

Candidates may think that adding a second ALB provides redundancy, but they overlook that the root cause is the ASG's single-AZ deployment, not the ALB's availability. The ALB already spans two AZs, so the issue is the lack of targets in the second AZ.

Option A uses long-lived access keys, violating the requirement for temporary credentials. IAM users with access keys are not temporary and increase security risk.

Using KMS to encrypt long-lived access keys does not eliminate the security risk of having permanent credentials; the pipeline still uses static keys, violating the requirement for temporary credentials.

This option would be correct if the question specified that the CI system cannot assume IAM roles (e.g., due to network restrictions or lack of STS support) and the security policy allows long-lived keys with regular rotation.

A scenario where the pipeline must use pre-existing long-lived access keys (e.g., legacy CI system that cannot assume roles) and the goal is to protect the keys at rest in the CI system's storage, with KMS encryption required by compliance.

Candidates may default to using IAM users and access keys because it's a familiar pattern for CI/CD integration, overlooking the explicit requirement for temporary credentials.

Candidates may think that encrypting the keys with KMS satisfies security best practices, overlooking that the core requirement is temporary credentials, not just encryption of static keys.