SAA-C03 (SAA-C03) — Questions 376–450

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.

Creating a read replica in another AZ does not provide automatic failover; manual promotion introduces downtime, failing the requirement for continuous serving if the current AZ fails.

Increasing the automated backup retention period does not provide high availability or automatic failover; it only extends the point-in-time recovery window, which does not help if the current Availability Zone fails.

Resizing the DB instance to a larger class improves performance but does not provide failover capability if the current Availability Zone fails. It does not address high availability across AZs.

This option would be correct if the question required offloading read traffic from the primary database to reduce load, with the ability to promote the replica for disaster recovery, but without a strict requirement for automatic failover.

If the question were about meeting a compliance requirement to retain daily backups for 30 days for audit purposes, then increasing the automated backup retention period to 30 days would be the correct answer.

This option would be correct in a scenario where the database is experiencing performance bottlenecks due to insufficient compute or memory resources, and the question asks for a solution to improve performance without changing the architecture.

Candidates may think that a read replica in another AZ provides high availability, but they overlook that failover is manual and not automatic, which is essential for continuous service during an AZ failure.

Candidates may confuse backup retention with disaster recovery, thinking that longer backups ensure availability during an AZ failure, but backups require manual restoration and do not provide automatic failover.

Candidates may think that a larger instance class inherently provides more reliability or redundancy, confusing vertical scaling with high availability.

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.

AWS WAF is a web application firewall that protects against web exploits and bots, but it does not reduce read latency for DynamoDB queries. The latency issue here is due to high read frequency on a few keys, not bot traffic.

Multi-region writes in DynamoDB Global Tables improve write availability and disaster recovery, but they do not reduce read latency for frequently accessed hot keys because reads still go to the local region's DynamoDB table without caching. The question specifically asks for lower read latency without changing the partition key design, which DAX addresses via caching.

Adding more read capacity units increases throughput but does not reduce latency for hot keys; it only prevents throttling. The question specifically asks for lower read latency, which caching addresses directly.

A question where an application experiences high read latency due to malicious bot traffic overwhelming DynamoDB, and the requirement is to filter out bot requests before they reach the database, while maintaining low latency for legitimate users.

A question asks: 'An application requires low-latency writes and reads across multiple geographic regions, with automatic conflict resolution for the same items written in different regions. Which DynamoDB feature should be used?' In that scenario, DynamoDB Global Tables would be correct.

If the question described an application that is experiencing read throttling (ProvisionedThroughputExceededException) on DynamoDB due to insufficient read capacity, and the team wants to eliminate throttling without changing the partition key, then increasing read capacity units would be correct.

Candidates may think that blocking bots with WAF will reduce overall load and thus latency, but they overlook that the latency issue is caused by legitimate high-frequency reads on hot keys, not by bots.

Candidates may think that having a local replica in each region automatically speeds up reads, but Global Tables replicate writes, not reads; reads still hit the local DynamoDB table without caching. The term 'locally' misleads them into believing it reduces read latency.

Candidates may think that more capacity automatically means faster reads, overlooking that latency for hot keys is limited by DynamoDB's internal architecture and that caching is the standard solution for sub-millisecond read latency.

Increasing the function timeout does not affect concurrency limits; it only extends the maximum execution duration. Throttling occurs due to hitting the account-level concurrency limit, not timeout.

Provisioned Concurrency for every Lambda would waste resources and cost, and it does not guarantee that the important Lambda has reserved capacity during spikes; it only pre-warms instances, but all functions still share the same regional concurrency limit.

Reducing IAM policies does not affect Lambda concurrency limits; it only reduces permissions, which does not prevent throttling from shared concurrency.

A question where a Lambda function is timing out before completing its task, causing errors or retries, and the requirement is to ensure it finishes processing without failure.

A question where the goal is to reduce cold starts for all functions in a latency-sensitive application, and cost is not a primary concern. For example: 'A company wants to ensure all its Lambda functions have minimal latency during unpredictable traffic spikes. Which action should be taken?'

In a scenario where a Lambda function is failing due to permission errors (e.g., AccessDeniedException) and you need to minimize the attack surface, reducing unnecessary IAM policies would be correct to follow the principle of least privilege.

Candidates may confuse timeout with concurrency, thinking longer execution reduces the chance of being throttled, or believe that throttling is related to execution duration.

Candidates may think Provisioned Concurrency reserves capacity, but it only pre-initializes instances; it does not prevent other functions from consuming the shared pool. The term 'Provisioned' sounds like reserving capacity, leading to confusion with Reserved Concurrency.

Candidates may mistakenly think that reducing IAM policies reduces resource usage or overhead, thereby preventing throttling, but IAM policies have no impact on concurrency limits.

Sending events directly from EventBridge to Lambda without a queue provides no buffering during traffic spikes, so Lambda retries still cause throttling and message loss. It also lacks a dead-letter queue to isolate repeatedly failing messages.

SNS fan-out without retry logic or a DLQ does not provide buffering, automatic retries, or isolation of failed messages, which are explicitly required to handle throttling and prevent message loss.

S3 event notifications have no built-in retry logic or dead-letter queue; if Lambda fails, the event is lost after the retry limit, failing to isolate repeatedly failing messages for inspection.

A question where the requirement is to minimize latency and cost for a low-volume, predictable event flow, and where message loss is acceptable. For example: 'A logging system processes non-critical events that can tolerate occasional drops; the team wants the simplest architecture.'

A system needs to broadcast the same event to multiple independent downstream services (e.g., notification, analytics, audit) simultaneously, and each service has its own retry and error handling. SNS fan-out is ideal for this parallel distribution.

For a batch processing system where raw data must be durably stored for compliance and reprocessing, and failures are handled by a separate monitoring process, S3 triggering Lambda immediately is appropriate.

Candidates may think removing the queue simplifies the architecture and reduces latency, overlooking the need for buffering and retry isolation during spikes.

Candidates may think SNS fan-out adds reliability through multiple subscribers, but they overlook that without retries and a DLQ, failed messages are lost, failing to meet the question's requirements for buffering and error isolation.

Candidates may think S3 provides durable storage and automatic event triggers, overlooking the lack of retry and DLQ capabilities needed for handling transient failures and isolating poison messages.

This option requires manual failover, which contradicts the requirement for minimal manual intervention and fast failover.

Frequent EBS snapshots provide point-in-time recovery but do not enable fast, automatic failover; restoring from a snapshot requires manual intervention and takes significant time, failing to meet the minimal manual intervention and fast failover requirements.

Higher CPU credits prevent CPU-related throttling but do not address database failover speed or minimize manual intervention, which is the core requirement for fast failover in a single-AZ deployment.

A question where the application can tolerate some downtime but needs to offload read traffic, and the exam asks for a cost-effective way to improve read scalability without automatic failover.

A question where the goal is to minimize data loss (low RPO) for a non-critical application that can tolerate downtime for recovery, and the requirement is to implement a cost-effective backup strategy without needing automatic failover.

For a question where the application experiences intermittent performance degradation due to CPU credit exhaustion on a burstable instance (e.g., t3/t4g), and the goal is to eliminate CPU-related throttling without changing architecture.

Candidates may think a read replica in a different AZ provides high availability, but they overlook that failover is manual and not automatic.

Candidates may confuse backup and restore (snapshots) with high availability, thinking that more frequent backups can serve as a failover mechanism, or they underestimate the time and manual effort required to restore from a snapshot.

Candidates may mistakenly think that preventing CPU issues is equivalent to ensuring high availability, or they may confuse performance tuning with failover mechanisms.

The trust policy on the IAM role must explicitly allow the external account to assume the role; attaching a policy to the vendor's IAM user does not grant cross-account sts:AssumeRole permissions because the role's trust policy controls who can assume it.

GetCallerIdentity does not grant cross-account access; it only returns details about the caller's own identity. The vendor needs to assume a role to access resources in the other account, not just check who they are.

The error is 'Not authorized to perform: sts:AssumeRole', which is a trust policy issue, not a permissions policy issue. Enabling MFA on the vendor's IAM user and adding an MFA condition to the role's permissions policy does not grant the vendor permission to assume the role; the trust policy must explicitly allow the vendor account to call sts:AssumeRole.

If the vendor needed to access resources in your account using their own IAM user (not assuming a role), you would attach a resource-based policy (e.g., S3 bucket policy) allowing the vendor's user ARN. In that case, the vendor's user policy would need to allow the corresponding API calls (e.g., s3:GetObject).

When troubleshooting an IAM permissions issue within the same account, GetCallerIdentity can be used to verify the identity and permissions of the caller without needing to assume a role.

A question where the vendor is already allowed to assume the role (trust policy is correct) but the role's permissions policy restricts access unless MFA is present. For example, a security requirement that all cross-account role assumptions must be authenticated with MFA. In that case, adding an MFA condition to the permissions policy would be the correct fix.

Candidates may think that adding a policy to the vendor's IAM user is sufficient to allow cross-account access, but they overlook that the role's trust policy is the gatekeeper for sts:AssumeRole.

Candidates may confuse GetCallerIdentity with a method to gain permissions, thinking it can infer or grant access, when it is only a diagnostic API.

Candidates may think that adding MFA strengthens security and thus solves authorization issues, or they confuse the trust policy (who can assume the role) with the permissions policy (what actions the role can perform). They might also believe that MFA is a universal solution for access denied errors.

Deleting logs after 1 day prevents troubleshooting access for incidents that may occur later, and the requirement is to reduce cost automatically over time, not eliminate data immediately.

S3 Lifecycle policies cannot apply compression at read time; they only transition or expire objects. Compression at read time is not a storage cost reduction feature and would not automatically reduce costs over time.

Changing encryption from SSE-S3 to SSE-KMS does not reduce storage cost; in fact, SSE-KMS incurs additional KMS key usage charges, increasing cost.

An S3 lifecycle policy that deletes objects after a set number of days would be correct if the requirement is to automatically remove logs after a retention period (e.g., compliance mandates deletion after 90 days) and no longer-term access is needed.

An S3 Lifecycle policy that keeps all objects in S3 Standard and applies compression at read time would be correct if the question asked for a solution to reduce data transfer costs or improve read performance for frequently accessed logs, while maintaining immediate access without storage class transitions.

A question where the requirement is to enforce customer-managed encryption keys for compliance or to control key rotation, and cost is not the primary concern.

Candidates may think deleting old logs is the simplest way to reduce cost, overlooking the need for occasional troubleshooting access and the availability of lower-cost storage classes.

Candidates may think compression reduces storage costs, but S3 does not support server-side compression at read time, and the option incorrectly implies that compression can be applied automatically via a lifecycle policy.

Candidates may mistakenly believe that using a more advanced encryption method like KMS reduces storage costs, or they confuse encryption cost with storage cost.

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.

Disabling CloudFront caching forces every request to the S3 origin, increasing origin fetches and data transfer costs, which is the opposite of the goal to reduce them.

A NAT Gateway is used to enable private subnets to access the internet or other AWS services, not to reduce bandwidth charges for CloudFront origins. It does not affect CloudFront caching or origin fetch behavior.

A question asks for the most direct way to ensure users always see the latest version of an object without any delay, and cost is not a concern. Disabling caching would guarantee fresh content from S3 on every request.

In a scenario where an application in a private subnet needs to access an S3 bucket (or other internet resource) and you want to avoid using a public IP or an internet gateway, a NAT Gateway would be the correct solution to provide outbound internet access.

Candidates may think that disabling caching simplifies configuration or avoids stale content, but they overlook that caching is the primary mechanism to reduce origin load and costs.

Candidates may mistakenly think that a NAT Gateway can reduce data transfer costs because it is associated with network address translation and cost management, but it does not apply to CloudFront-to-S3 data transfer.

Increasing desired capacity adds more instances but does not fix the health check configuration; the ASG still uses EC2 status checks, which may not detect application-level failures, so unhealthy instances are not replaced.

The question is about replacing unhealthy instances based on application process failure, not about failover speed. An NLB does not provide application-level health checks, so it would not detect application process failures.

Increasing HealthCheckGracePeriod only delays the start of health checks, but does not fix the root cause: the ASG is using EC2 status checks (default) instead of ELB health checks, so it never detects application-level failures.

In a scenario where the ASG is correctly configured to replace unhealthy instances but the application needs to handle sudden traffic spikes without downtime, increasing desired capacity ensures enough healthy instances are always available to absorb load.

When the requirement is to handle sudden traffic spikes with minimal latency and the application can tolerate connection-level health checks, or when the architecture needs to preserve the source IP address of clients.

This option would be correct in a scenario where instances are being prematurely terminated because health checks begin before the application finishes booting, causing false positives. Increasing the grace period gives the application more time to become healthy.

Candidates think that adding more instances provides redundancy, but they overlook that the core issue is the health check type not detecting application failures, so extra instances won't be triggered to replace unhealthy ones.

Candidates may think that an NLB's faster failover and lower latency would improve recovery, but they overlook that the issue is about detecting application-level health, which requires an ALB's HTTP health checks.

Candidates may think that giving instances more time to stabilize will prevent unnecessary replacements, but they overlook that the ASG must first be configured to use ELB health checks to detect application failures at all.

Option B is wrong because attaching AmazonS3FullAccess to the instance profile role in Account A does not grant cross-account access to an S3 bucket in Account B. The bucket's bucket policy must explicitly allow the role from Account A, and using long-lived access keys is not avoided.

SCPs (Service Control Policies) are used to restrict permissions in AWS Organizations accounts, not to grant cross-account access. They cannot allow actions; they only deny or limit permissions. Thus, adding an SCP to Account A does not enable the workload to access the S3 bucket in Account B.

Enabling S3 versioning does not grant cross-account access permissions; it only preserves object versions. Cross-account access requires explicit IAM policies and bucket policies, not versioning.

Option B would be correct if the S3 bucket is in the same account as the workload (Account A) and the goal is to grant full S3 access to an EC2 instance using an instance profile role, without requiring cross-account access.

An SCP would be correct if the question asked: 'How can an organization administrator prevent all accounts in the organization from deleting an S3 bucket in a specific account?' In that case, adding an SCP that denies s3:DeleteBucket actions for that bucket would be appropriate.

A question asks how to protect against accidental deletion or overwriting of objects in an S3 bucket. Enabling versioning would be the correct answer because it allows recovery of previous object versions.

Candidates may think that attaching a full-access policy to the instance profile role is sufficient for any S3 access, overlooking the need for cross-account bucket policies and the requirement to avoid long-lived keys.

Candidates may confuse SCPs with resource-based policies or IAM policies, thinking SCPs can grant cross-account access, or they may overestimate the scope of SCPs as a general permission-granting mechanism.

Candidates may mistakenly think versioning enables cross-account trust or that it automatically resolves access control issues, confusing versioning with bucket policies or resource-based permissions.

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.

The application role in Account B already has an identity policy allowing s3:GetObject on the bucket prefix, so adding another IAM policy granting s3:* is redundant and does not address the cross-account permission issue or the KMS key policy requirement.

The error is AccessDenied, not connectivity issues. S3 Gateway Endpoints only provide private network access to S3, but do not grant IAM permissions or resolve KMS decryption authorization failures.

SCPs (Service Control Policies) cannot grant permissions; they only restrict permissions. Additionally, SCPs cannot bypass KMS encryption checks; the KMS key policy must explicitly allow the Account B role to use kms:Decrypt.

This option would be correct if the application role in Account B did not already have the necessary S3 permissions, and the question asked for a single-account setup where the bucket and role are in the same account, requiring only IAM policy updates.

A question where an application in a VPC cannot reach S3 due to public internet routing restrictions (e.g., no NAT gateway, no internet gateway) and the bucket is in the same region. Adding an S3 Gateway Endpoint would provide private connectivity.

An SCP would be correct in a question where an organization wants to prevent all accounts from disabling encryption on S3 buckets, and the correct action is to add an SCP that denies s3:PutBucketEncryption or similar actions to enforce encryption requirements.

Candidates may think that granting broader S3 permissions (s3:*) will override any missing permissions, not realizing the core issue is cross-account access and KMS key policy, not insufficient IAM permissions in Account B.

Candidates may confuse network connectivity problems with authorization failures, assuming that a private endpoint can bypass IAM or KMS permission issues.

Candidates may confuse SCPs with resource policies or think SCPs can grant cross-account access, or they may misunderstand that SCPs can override KMS permissions, leading them to select this option as a shortcut to fix the access issue.