SAA-C03 SAA-C03 Questions 151–225 | Page 3/5

151

MCQmedium

You run a web application on an EC2 Auto Scaling group behind an Application Load Balancer (ALB). During scheduled traffic spikes, new instances launch but customers occasionally see 5xx errors for the first few minutes after scale-out. Operational logs show instances need ~4 minutes to warm up (load caches and initialize dependencies). ALB target health becomes healthy only after this warm-up. Which change most directly improves performance during spikes by reducing the time to serve traffic after scaling?

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

B.Use an Auto Scaling warm pool so instances are pre-initialized and ready to register quickly when the ASG scales out.

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

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

AnswerB

With a warm pool, Auto Scaling can launch and keep a set of instances in a pre-initialized state (for example, instances are already booted and have completed parts of startup/initialization as supported by warm pool behavior). When scaling triggers, these instances can transition to service faster and begin registering with the ALB. Because your bottleneck is that instances take ~4 minutes to become truly ready, warming them ahead of time most directly reduces the gap between scale-out and customer-ready capacity (and therefore reduces 5xx occurrences while waiting for targets to pass ALB health checks).

Why this answer

B is correct because a warm pool pre-initializes instances (e.g., loading caches and dependencies) before they are added to the Auto Scaling group. When the ASG scales out, these pre-warmed instances can be quickly moved into service, bypassing the ~4-minute warm-up delay and reducing the window for 5xx errors.

Exam trap

The trap here is that candidates may think NLB bypasses health checks entirely, but in reality NLB still requires health checks to mark targets as healthy, and the application warm-up delay remains the bottleneck.

How to eliminate wrong answers

Option A is wrong because increasing the deregistration delay keeps old targets alive longer, which does not help new instances serve traffic faster; it only delays termination of existing instances. Option C is wrong because manually setting desired instances without scaling policies is not automated and does not address the root cause of warm-up latency during spikes. Option D is wrong because switching to NLB does not eliminate the need for health checks or application warm-up; NLB health checks are still required and instances still need time to become healthy, so 5xx errors would persist.

Full explanation →

152

MCQmedium

A telemetry pipeline uses RDS MySQL and receives many read-only reporting queries that slow down the primary database. What should the architect add?

A.Multi-AZ standby and route reads to the standby

B.RDS read replica and route reporting queries to it

C.S3 lifecycle policy

D.A larger NAT gateway

AnswerB

Read replicas offload read traffic from the primary instance.

Why this answer

RDS Read Replicas are designed specifically to offload read-heavy workloads from the primary database. By creating a read replica and routing the reporting queries to it, the primary database is freed from processing these read-only queries, reducing contention and improving overall performance. This is the most cost-effective and architecturally appropriate solution for read scaling in RDS MySQL.

Exam trap

The trap here is confusing Multi-AZ standby (which is for failover, not read scaling) with a read replica, leading candidates to incorrectly choose Option A.

How to eliminate wrong answers

Option A is wrong because a Multi-AZ standby is for high availability and disaster recovery, not for read scaling; the standby does not accept read traffic unless a failover occurs. Option C is wrong because S3 lifecycle policies manage object storage tiers and expiration, which have no relevance to offloading database read queries. Option D is wrong because a larger NAT gateway increases outbound internet bandwidth for private subnets, but does not address database read performance or query offloading.

Full explanation →

153

MCQeasy

A company serves public JavaScript and CSS files from S3 using CloudFront. After a frontend change, customers report a low CloudFront cache hit ratio. Requests now include an Authorization header, but these assets do not require authentication. The CloudFront distribution is configured such that Authorization is included in the cache key. Which change best maximizes cache reuse?

A.Include the Authorization header in the cache key so responses vary correctly

B.Use a CloudFront Cache Policy that excludes Authorization from the cache key

C.Disable caching and always fetch from S3

D.Forward all headers and cookies to the origin to improve correctness

AnswerB

Because the assets are public and do not depend on Authorization, excluding Authorization from the cache key allows all users to share the same cached objects. This reduces cache fragmentation and increases cache hit ratio.

Why this answer

Excluding the Authorization header from the cache key ensures that all users, regardless of their authentication token, receive the same cached object. Since the static assets (JavaScript/CSS) do not require authentication, including Authorization in the cache key creates multiple cache entries for the same file, drastically reducing the cache hit ratio. A CloudFront cache policy that omits Authorization from the cache key maximizes reuse while still allowing the header to be forwarded to the origin if needed.

Exam trap

The trap here is that candidates may assume including the Authorization header is necessary for correctness, but for public static assets, excluding it from the cache key is the correct way to maximize cache reuse without affecting delivery.

How to eliminate wrong answers

Option A is wrong because including the Authorization header in the cache key would cause CloudFront to cache separate copies for each unique token value, which is exactly the problem that reduces the cache hit ratio. Option C is wrong because disabling caching entirely would increase latency and origin load, violating the goal of maximizing cache reuse. Option D is wrong because forwarding all headers and cookies to the origin would not only include unnecessary Authorization values but also further fragment the cache, worsening the hit ratio and adding overhead.

Full explanation →

154

MCQmedium

A microservice runs in private subnets and must read exactly one AWS Secrets Manager secret using its IAM task role: arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/db-pass-AbCdEf Security requires that every Secrets Manager API call comes only through a specific Interface VPC Endpoint (vpce-0a1b2c3d4e5f6g7h), and must not be reachable over any other network path. Which IAM policy change best enforces this requirement?

A.In the task role policy statement for secretsmanager:GetSecretValue on the secret ARN, add a condition that allows the action only when aws:SourceVpce equals vpce-0a1b2c3d4e5f6g7h.

B.Add a condition that allows secretsmanager:GetSecretValue only when aws:SourceIp is within 10.0.0.0/8.

C.Require TLS by adding a condition on aws:SecureTransport for the Secrets Manager permission.

D.Add a KMS condition using kms:ViaService=secretsmanager.us-east-1.amazonaws.com instead of restricting Secrets Manager directly.

AnswerA

For Interface VPC endpoints, aws:SourceVpce can be used as a condition key so KMS/Secrets Manager API authorization succeeds only when the request originates from the specified endpoint. Restricting the IAM permission to aws:SourceVpce=vpce-... directly matches the requirement that calls must not traverse other network paths (e.g., via NAT/egress).

Why this answer

The condition `aws:SourceVpce` in the IAM policy restricts the `secretsmanager:GetSecretValue` API call to originate only from the specified VPC Endpoint (vpce-0a1b2c3d4e5f6g7h). This ensures that the secret can only be accessed via that specific Interface Endpoint, blocking any other network path (e.g., internet, NAT gateway, or other VPC endpoints). The task role is attached to the microservice, so the policy directly enforces the security requirement at the API level.

Exam trap

The trap here is that candidates often confuse `aws:SourceVpce` with `aws:SourceIp` or `aws:SourceVpc`, thinking any network-level condition will work, but only `aws:SourceVpce` uniquely identifies the specific Interface VPC Endpoint required for this strict enforcement.

How to eliminate wrong answers

Option B is wrong because `aws:SourceIp` condition key is not effective for requests made through a VPC Endpoint; the source IP is replaced by the endpoint's private IP, making the condition unreliable for restricting traffic to a specific endpoint. Option C is wrong because requiring TLS (`aws:SecureTransport`) only ensures encryption in transit, not that the API call comes through a specific VPC Endpoint; it does not restrict the network path. Option D is wrong because `kms:ViaService` restricts KMS key usage to a specific AWS service (Secrets Manager), but it does not control which network path (e.g., VPC Endpoint) the Secrets Manager API call uses; it addresses KMS authorization, not network-level restriction.

Full explanation →

155

Multi-Selectmedium

An order lookup API repeatedly reads the same few items from DynamoDB. The application can tolerate slightly stale data for a few seconds, and the team wants the lowest-latency design with minimal application changes. Which two changes should they make? Select two.

Select 2 answers

A.Put Amazon DynamoDB Accelerator (DAX) in front of the table.

B.Use eventually consistent reads where the application can tolerate slightly stale data.

C.Switch all access to strongly consistent reads for faster results.

D.Increase the item size so fewer requests are needed.

E.Replace the table with Amazon EBS volumes mounted on EC2 instances.

AnswersA, B

DAX is an in-memory cache for DynamoDB reads, so repeated lookups for the same keys can be served with much lower latency than direct table reads. It is especially effective for hot-item access patterns like order lookups, product metadata, and profile reads.

Why this answer

Amazon DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that provides microsecond read latency, which is ideal for repeated reads of the same few items. Since the application can tolerate slightly stale data, DAX's default write-through caching with a TTL of 5 minutes ensures low latency without requiring application code changes beyond adding the DAX client.

Exam trap

The trap here is that candidates may think strongly consistent reads are always faster, but they actually have higher latency and cannot be cached by DAX, making them unsuitable for this low-latency, minimal-change requirement.

Why the other options are wrong

Strongly consistent reads have higher latency and consume more read capacity units than eventually consistent reads, so switching to them would increase latency, not reduce it.

Increasing item size does not reduce the number of read requests for the same few items; it may increase read costs and latency due to larger data transfer.

EBS volumes do not provide a managed, low-latency caching layer for DynamoDB; they require significant application changes to migrate from DynamoDB to a self-managed database, contradicting the 'minimal application changes' requirement.

When would these options actually be correct?

If the application requires the most up-to-date data and cannot tolerate any staleness, and the team is willing to accept higher latency and cost, then strongly consistent reads would be the correct choice.

When the application needs to reduce the number of read requests to DynamoDB to lower costs or avoid throttling, and the items are frequently accessed together, combining them into a single larger item can be correct.

A question requiring a durable, block-level storage solution for a legacy application that needs to run on EC2 with low-latency local access, and where the team is willing to manage the database layer themselves, would make EBS the correct choice.

Why candidates pick the wrong answer

Candidates may mistakenly believe that 'strongly consistent' implies 'faster' because it sounds more authoritative, or they may not understand the trade-off between consistency and latency in DynamoDB.

Candidates may think larger items mean fewer requests, but the question specifies repeatedly reading the same few items, so request count is already low; larger items don't help latency.

Candidates may think EBS offers lower latency than DynamoDB because it is directly attached to EC2, overlooking the complexity of replacing a managed NoSQL service with a self-managed storage solution.

Full explanation →

156

MCQhard

Based on the exhibit, a static asset distribution site uses Amazon CloudFront with an S3 origin. The assets are versioned by filename, but the cache hit ratio remains low after each release. Which CloudFront change is the best way to improve cache reuse without changing the origin objects?

A.Keep the current cache key and increase the S3 bucket's storage class.

B.Remove Authorization and unnecessary query strings from the CloudFront cache key.

C.Disable the CloudFront cache so every request is served directly from S3.

D.Switch the origin from Amazon S3 to an Application Load Balancer.

AnswerB

Versioned static assets do not need Authorization in the cache key, and arbitrary query strings can destroy cache efficiency. Excluding those fields lets CloudFront reuse the same cached object across many viewers.

Why this answer

Removing Authorization headers and unnecessary query strings from the CloudFront cache key ensures that multiple requests for the same versioned asset (e.g., style.v2.css) share a single cached object, regardless of user-specific headers or irrelevant query parameters. This directly increases the cache hit ratio without modifying the origin objects, as CloudFront will serve the same cached response for identical cache keys.

Exam trap

The trap here is that candidates may think increasing storage class or switching to an ALB improves caching, but the real issue is the cache key composition—specifically, unnecessary headers or query strings fragmenting the cache—which is solved by adjusting the CloudFront cache key settings.

How to eliminate wrong answers

Option A is wrong because changing the S3 bucket's storage class (e.g., to S3 Standard-IA or Glacier) has no effect on CloudFront's cache key or cache hit ratio; it only affects storage cost and retrieval latency, not caching behavior. Option C is wrong because disabling the CloudFront cache would force every request to go directly to the S3 origin, eliminating all caching benefits and increasing latency and origin load, which is the opposite of improving cache reuse. Option D is wrong because switching the origin from S3 to an Application Load Balancer (ALB) introduces unnecessary complexity and does not address the cache key issue; the ALB would still require the same cache key optimization to improve cache hits, and it would not inherently improve cache reuse.

Full explanation →

157

MCQhard

Based on the exhibit, what is the best change to improve read performance without increasing write latency on the primary database?

A.Create an RDS read replica and direct the reporting queries to the replica endpoint.

B.Convert the DB instance to Multi-AZ so the primary can serve more reads.

C.Increase the primary instance class to a larger size and keep all traffic on one writer.

D.Migrate the reporting workload to DynamoDB to gain faster reads.

AnswerA

A read replica offloads the long-running read-only reports from the primary database, which preserves write performance and reduces read latency for the reporting workload. Because the business accepts slightly stale report data, the asynchronous replication delay is acceptable. This is the most direct and AWS-native way to separate read pressure from writes.

Why this answer

Creating an RDS read replica offloads read-heavy reporting queries from the primary database instance, improving read performance without adding any write latency to the primary. The replica operates asynchronously, so writes on the primary are not blocked or delayed by the replica's lag. This is the standard AWS solution for scaling read traffic on RDS.

Exam trap

The trap here is that candidates confuse Multi-AZ with read scaling, assuming the standby instance can serve reads, when in fact Multi-AZ only provides failover redundancy and the standby is not accessible for read operations.

How to eliminate wrong answers

Option B is wrong because Multi-AZ is designed for high availability and automatic failover, not for scaling read capacity; the standby instance cannot serve reads directly. Option C is wrong because increasing the instance class would improve both read and write performance, but it does not isolate the reporting workload, so it could still increase write latency under heavy read load. Option D is wrong because migrating to DynamoDB is an architectural change that would require application rewrites and does not directly address improving read performance on the existing primary database without increasing write latency.

Full explanation →

158

MCQmedium

A web application runs on an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ASG is currently attached to subnets in only two Availability Zones (AZs). During a planned maintenance window, one AZ becomes unavailable for about 25 minutes. Monitoring shows that targets in the remaining AZ go healthy, and the ALB/target group health checks report normal. However, users still experience intermittent connection failures and slower responses during the AZ outage. What change will most directly improve resilience against an AZ loss while keeping the same ALB-based design?

A.Set the ASG min capacity to 0 so instances can be recreated faster when an AZ recovers.

B.Extend the ASG to use subnets in three AZs so there is placement redundancy during an AZ outage, while continuing to keep traffic behind the ALB.

C.Increase the ALB idle timeout to 120 seconds to reduce connection drops.

D.Disable health checks on the target group so instances are not deregistered during the maintenance window.

AnswerB

An AZ outage reduces the number of AZs where the ASG can place instances. With only two AZs, losing one significantly limits capacity and can cause temporary shortages and uneven load distribution, even if existing targets are marked healthy. Expanding the ASG to subnets in three (or more) AZs provides additional placement options so the ASG can maintain the desired number of instances across the remaining AZ(s). The ALB will continue routing only to healthy targets, and the system is more likely to sustain stable response times during the outage.

Why this answer

B is correct because deploying the ASG across three Availability Zones (AZs) ensures that when one AZ becomes unavailable, the remaining two AZs can handle the full traffic load without overloading the instances. This placement redundancy directly addresses the intermittent connection failures and slower responses, as the ALB can distribute traffic only to healthy targets in the remaining AZs, maintaining capacity and performance. The current two-AZ setup lacks sufficient buffer capacity, causing the single remaining AZ to become overwhelmed during the outage.

Exam trap

The trap here is that candidates may focus on connection-level settings (idle timeout) or health check behavior, missing the fundamental architectural need for multi-AZ redundancy to maintain capacity during an AZ outage.

How to eliminate wrong answers

Option A is wrong because setting the ASG min capacity to 0 does not help during an AZ outage; it would actually allow all instances to be terminated, making the application unavailable, and it does not address the lack of capacity in the remaining AZ. Option C is wrong because increasing the ALB idle timeout to 120 seconds only keeps idle connections open longer, which does not prevent connection failures or slow responses caused by insufficient capacity in the remaining AZ; it may even mask underlying issues. Option D is wrong because disabling health checks on the target group would prevent the ALB from deregistering unhealthy instances, causing traffic to be routed to failed instances in the unavailable AZ, leading to more connection failures and no improvement in resilience.

Full explanation →

159

MCQmedium

A solutions architect is designing an S3 bucket for a claims portal. The objects must never be publicly accessible, even if a developer later adds an overly broad bucket policy. What should the architect configure? The design must avoid adding custom operational scripts.

A.Enable S3 Block Public Access at the account or bucket level

B.Create an IAM policy that denies s3:GetObject to anonymous users

C.Enable server access logging on the bucket

D.Enable S3 Transfer Acceleration

AnswerA

S3 Block Public Access prevents public ACLs and public bucket policies from exposing the bucket.

Why this answer

S3 Block Public Access provides a definitive override that prevents any public access to S3 objects, even if a bucket policy or ACL later grants public access. This setting can be applied at the account or bucket level and ensures that all access is denied to anonymous users, meeting the requirement without custom scripts.

Exam trap

The trap here is that candidates may think an IAM policy can block anonymous users, but IAM policies only apply to authenticated IAM principals, not to anonymous (unauthenticated) requests, making S3 Block Public Access the only effective solution.

How to eliminate wrong answers

Option B is wrong because an IAM policy that denies s3:GetObject to anonymous users is not effective; anonymous users are not IAM principals, so IAM policies do not apply to them. Option C is wrong because server access logging records requests but does not enforce access controls or prevent public access. Option D is wrong because S3 Transfer Acceleration speeds up uploads over long distances but has no effect on access permissions or public accessibility.

Full explanation →

160

MCQhard

Based on the exhibit, a partner account uploads encrypted objects to a central S3 bucket and later reads them back. The S3 permissions are correct, but the requests still fail. What change is required so the partner workload can use the customer-managed KMS key safely?

A.Replace SSE-KMS with S3 object ACLs so the partner account can bypass KMS authorization.

B.Create a new bucket in the partner account and copy the objects there to avoid cross-account encryption.

C.Switch the bucket to SSE-S3 so the partner role no longer needs KMS permissions.

D.Update the CMK key policy, or add a tightly scoped grant, to allow the partner role the required KMS actions through S3.

AnswerD

Cross-account access to SSE-KMS encrypted objects requires KMS authorization in addition to S3 authorization. The key policy must trust the partner role, and the permissions should be limited to the needed KMS actions such as Decrypt, Encrypt, and GenerateDataKey with a service condition for S3. That is why the partner can have valid S3 permissions and still fail until the KMS policy is fixed.

Why this answer

When using a customer-managed KMS key (CMK) for SSE-KMS in a cross-account scenario, the key policy must explicitly grant the partner account's IAM role the necessary KMS actions (kms:Decrypt, kms:GenerateDataKey) to allow S3 to perform the encryption/decryption on behalf of the partner. Without this policy update or a tightly scoped grant, the KMS service will deny the request even if S3 bucket policies are correctly configured.

Exam trap

The trap here is that candidates assume S3 bucket policies alone control all access, forgetting that SSE-KMS introduces a separate authorization layer at KMS that requires explicit cross-account permissions in the key policy.

How to eliminate wrong answers

Option A is wrong because S3 object ACLs cannot bypass KMS authorization; ACLs control access to the object itself, not the encryption key, and removing SSE-KMS would violate security requirements. Option B is wrong because copying objects to a new bucket in the partner account does not resolve the underlying KMS authorization issue; the partner still needs access to the CMK to decrypt the objects. Option C is wrong because switching to SSE-S3 would remove the use of the customer-managed key, which may be a compliance or security requirement, and does not address the need for cross-account access with a CMK.

Full explanation →

161

MCQmedium

A risk simulation workload uses CloudWatch Logs heavily. Retaining all debug logs forever is increasing costs. What should be configured?

A.CloudWatch Logs retention policies per log group

B.AWS Config aggregation

C.CloudWatch detailed monitoring on all instances

D.Route 53 health checks

AnswerA

Retention policies automatically delete older logs after the required period.

Why this answer

CloudWatch Logs retention policies allow you to set per-log-group expiration rules (e.g., 30 days, 90 days) to automatically delete old log events, directly reducing storage costs for debug logs that are no longer needed. This is the most cost-effective and targeted solution for managing log lifecycle without affecting other monitoring or configuration services.

Exam trap

The trap here is that candidates may confuse log retention with monitoring frequency or configuration management, mistakenly thinking that reducing metric collection (detailed monitoring) or using Config aggregation will lower log storage costs.

How to eliminate wrong answers

Option B is wrong because AWS Config aggregation is used to collect and centrally view configuration and compliance data from multiple accounts/regions, not to manage log retention or storage costs. Option C is wrong because CloudWatch detailed monitoring on all instances increases metric frequency (1-minute intervals) and incurs additional costs, doing nothing to control log retention or delete old debug logs. Option D is wrong because Route 53 health checks monitor endpoint availability and DNS routing, not log storage or retention policies.

Full explanation →

162

Multi-Selecthard

A nightly video rendering pipeline runs on Linux EC2 instances and is compatible with ARM64. The jobs are CPU-bound, checkpoint frequently, and can resume if interrupted. The business wants the best throughput per dollar for the batch window. Which two changes should the team make? Select two.

Select 2 answers

A.Use AWS Graviton-based instances for the render workers.

B.Run the workers in an Auto Scaling group with Spot Instances for interruption-tolerant capacity.

C.Use a single large x86 instance with On-Demand pricing to avoid interruptions.

D.Replace the batch workers with a Lambda function to eliminate instance management.

E.Move the workload to a spread placement group to increase cost efficiency.

AnswersA, B

Graviton instances are ARM-based and often deliver better price-performance than comparable x86 instances for CPU-bound workloads. Because the application is already compatible with ARM64, the team can adopt Graviton without rewriting the pipeline. That improves throughput per dollar while keeping the same batch-processing model.

Why this answer

AWS Graviton-based instances use ARM64 architecture, which is explicitly compatible with the video rendering pipeline. They offer up to 40% better price-performance compared to comparable x86 instances for CPU-bound workloads, directly improving throughput per dollar. This makes option A correct for maximizing cost efficiency.

Exam trap

The trap here is that candidates may overlook the compatibility requirement with ARM64 and choose a single large x86 instance for simplicity, or mistakenly think Lambda can handle long-running CPU-bound tasks, missing the cost and throughput benefits of Graviton and Spot Instances.

Full explanation →

163

Multi-Selectmedium

A company is migrating its on-premises workloads to AWS and wants to optimize costs. Which three strategies should the company implement to achieve a cost-optimized architecture? (Choose three.)

Select 3 answers

.Use Reserved Instances or Savings Plans for predictable workloads to reduce costs compared to On-Demand pricing.

.Provision additional EC2 instances to handle peak load at all times, ensuring maximum performance.

.Implement auto scaling to match capacity with demand, avoiding over-provisioning and reducing waste.

.Use Spot Instances for fault-tolerant, flexible workloads to achieve significant cost savings.

.Store all data in Amazon S3 Standard storage class to avoid any data retrieval costs.

.Deploy all resources in a single Availability Zone to minimize data transfer costs.

Why this answer

Reserved Instances or Savings Plans provide significant discounts (up to 72%) over On-Demand pricing for predictable workloads by committing to a specific usage term (1 or 3 years). This directly reduces compute costs for steady-state applications, making it a core cost-optimization strategy.

Exam trap

The trap here is that candidates often confuse 'maximizing performance' with 'cost optimization' and select the option to provision extra instances for peak load, failing to recognize that auto scaling and right-sizing are the correct approaches to balance cost and performance.

Full explanation →

164

MCQmedium

A company runs an application on EC2 instances in private subnets. The instances must access Amazon S3, and the team currently routes all outbound traffic to the internet through a NAT Gateway. Monthly NAT Gateway charges increased significantly, even though the application only needs to call S3 (not access other public internet services). Which change will most directly reduce NAT Gateway charges while keeping S3 access working?

A.Create a gateway VPC endpoint for S3 and update the private route tables so S3 traffic uses the endpoint instead of the NAT Gateway.

B.Enable S3 Transfer Acceleration on the bucket to reduce the number of S3 calls that go through the NAT Gateway.

C.Switch the EC2 instances to public subnets so S3 calls can use direct internet routing without NAT.

D.Increase the NAT Gateway TCP idle timeout so fewer connections are billed separately for S3 traffic.

AnswerA

A gateway VPC endpoint for S3 keeps S3 traffic within the AWS network. After you add the S3 gateway endpoint and update the private subnet route tables for the S3 prefix list to target the endpoint, S3 API calls from the private subnets no longer traverse the NAT Gateway. This directly reduces both NAT Gateway per-hour charges and NAT data-processing charges associated with S3 traffic. If the application truly only needs S3, you can remove the NAT route for those S3 destinations and rely on the endpoint for S3 connectivity.

Why this answer

A gateway VPC endpoint for S3 allows instances in private subnets to access S3 over the AWS network without traversing the internet. By updating the private route tables to direct S3 traffic to the endpoint, the NAT Gateway is bypassed, eliminating the per-GB data processing charges and hourly NAT Gateway fees for that traffic. This directly reduces costs while maintaining secure, private access to S3.

Exam trap

The trap here is that candidates may think S3 Transfer Acceleration or increasing NAT Gateway timeouts will reduce costs, but they fail to recognize that a gateway VPC endpoint eliminates the NAT Gateway entirely for S3 traffic, directly addressing the cost issue without compromising security.

How to eliminate wrong answers

Option B is wrong because S3 Transfer Acceleration speeds up uploads over long distances using AWS edge locations, but it does not reduce the amount of traffic going through the NAT Gateway; it actually adds additional costs per GB transferred and still requires internet routing. Option C is wrong because moving EC2 instances to public subnets exposes them directly to the internet, violating the requirement for private subnets and introducing security risks; it also does not reduce NAT Gateway charges since the NAT Gateway is no longer used, but the question asks for a change that reduces NAT Gateway charges while keeping S3 access working, not for a security redesign. Option D is wrong because increasing the TCP idle timeout does not reduce NAT Gateway charges; it may actually increase costs by keeping connections open longer, and NAT Gateway billing is based on data processing and hourly usage, not per-connection billing.

Full explanation →

165

MCQmedium

A web application for a healthcare document service is behind an Application Load Balancer. The application must be protected from common SQL injection and cross-site scripting attacks with minimum operational overhead. What should the architect deploy? The design must avoid adding custom operational scripts.

A.Security groups on the application instances

B.AWS WAF associated with the Application Load Balancer

C.Network ACLs on the public subnets

D.AWS Shield Advanced only

AnswerB

AWS WAF can inspect HTTP requests and block common web exploits when associated with an ALB.

Why this answer

AWS WAF is a web application firewall that integrates directly with an Application Load Balancer to filter and monitor HTTP/HTTPS requests. It provides managed rules specifically designed to block common attack patterns like SQL injection and cross-site scripting (XSS) without requiring custom scripts or manual rule maintenance, thus meeting the requirement for minimum operational overhead.

Exam trap

The trap here is that candidates often confuse network-layer security controls (security groups, network ACLs, or Shield) with application-layer protection, assuming they can block SQL injection or XSS, when in fact only a web application firewall like AWS WAF can inspect and filter HTTP payloads for such attacks.

How to eliminate wrong answers

Option A is wrong because security groups act as a stateful virtual firewall at the instance level, filtering traffic based on IP addresses, ports, and protocols; they cannot inspect application-layer payloads to detect SQL injection or XSS patterns. Option C is wrong because network ACLs are stateless and operate at the subnet level, only filtering traffic based on IP, port, and protocol rules, with no capability to parse HTTP request bodies or headers for malicious content. Option D is wrong because AWS Shield Advanced provides DDoS protection at the network and transport layers, not application-layer attack mitigation for SQL injection or XSS; it does not include a web application firewall.

Full explanation →

166

Multi-Selectmedium

A central security account stores encrypted log files in S3 using a customer managed AWS KMS key. A partner account already has S3 bucket access through an assumed role and now must also be able to encrypt and decrypt objects that use the same KMS key. Which two actions are required? Select two.

Select 2 answers

A.Update the KMS key policy to allow the partner role or account to use the key.

B.Enable automatic key rotation to solve the cross-account access requirement.

C.Attach IAM permissions in the partner account for kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey on the CMK.

D.Replace the CMK with the AWS managed key alias/aws/s3.

E.Export the KMS key material and share it with the partner account.

AnswersA, C

KMS evaluates the key policy before permitting use of a customer managed key. Cross-account use requires the key policy to trust the external principal or a grant to that principal.

Why this answer

The KMS key policy must explicitly grant the partner account or role permission to use the key for cryptographic operations. Without this cross-account policy statement, the key remains inaccessible to the partner account, even if the partner has S3 bucket access. This is a fundamental requirement for cross-account KMS key usage.

Exam trap

The trap here is that candidates often forget that cross-account KMS access requires both a key policy update in the central account AND IAM permissions in the partner account, not just one of them.

Full explanation →

167

MCQmedium

An S3 bucket in account A uses default server-side encryption with an AWS KMS customer-managed key (CMK) in account A. A team created an IAM role in account B that is allowed by IAM policy to perform s3:GetObject on the bucket. When the account B role tries to read objects, it fails with: AccessDeniedException: 'User is not authorized to perform kms:Decrypt'. Which change is most likely to fix the issue?

A.Add kms:Decrypt permissions to the identity policy in account B only, without modifying the CMK key policy in account A.

B.Update the CMK key policy in account A to allow the account B role principal to call kms:Decrypt (and kms:DescribeKey if needed).

C.Disable SSE-KMS on the S3 bucket so objects use SSE-S3 instead, eliminating the need for KMS permissions.

D.Attach a broad permissions boundary to the account B role allowing all kms:* actions to override the key policy.

AnswerB

Updating the CMK key policy in Account A is the correct approach because KMS key policies are the authoritative resource-based policies that govern access to the key, especially for cross-account scenarios. By explicitly adding the Account B role's ARN as a `Principal` and granting `kms:Decrypt` (and `kms:DescribeKey` for context) within the key policy, Account A explicitly authorizes the external principal to use its CMK, satisfying the two-layer authorization model.

Why this answer

When an S3 bucket uses SSE-KMS with a customer-managed key (CMK) in account A, the account B role must have explicit kms:Decrypt permission on that CMK. The key policy in account A controls access to the CMK, so adding the account B role principal to the key policy with kms:Decrypt (and kms:DescribeKey if needed) is required. Without this, even if the S3 bucket policy and IAM role allow s3:GetObject, the KMS decrypt call will fail.

Exam trap

The trap here is that candidates assume IAM permissions in account B are sufficient for cross-account KMS operations, forgetting that the KMS key policy in the owning account must explicitly grant access to the external principal.

How to eliminate wrong answers

Option A is wrong because adding kms:Decrypt to the identity policy in account B alone is insufficient; the CMK key policy in account A must also grant access to the account B role, as KMS key policies act as a separate authorization layer. Option C is wrong because disabling SSE-KMS and switching to SSE-S3 would change the encryption method and potentially violate security requirements, but it would technically fix the KMS permission issue; however, it is not the most likely fix as it alters the encryption configuration rather than addressing the permission gap. Option D is wrong because a permissions boundary on the account B role cannot override the CMK key policy in account A; the key policy is the ultimate authority for KMS key access, and a boundary only limits the role's maximum permissions within its own account.

Full explanation →

168

MCQmedium

A read-heavy media archive repeatedly queries the same product catalogue data from DynamoDB with millisecond latency requirements. Which service can reduce read latency and table load? The design must avoid adding custom operational scripts.

A.DynamoDB Accelerator (DAX)

B.Amazon Kinesis Data Firehose

C.AWS Glue Data Catalog

D.S3 Transfer Acceleration

AnswerA

DAX is an in-memory cache for DynamoDB that reduces read latency for suitable access patterns.

Why this answer

DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that delivers microsecond read latency, reducing the load on the underlying DynamoDB tables by serving repeated queries from its cache. This directly addresses the read-heavy media archive's millisecond latency requirements without requiring custom operational scripts, as DAX is fully managed and integrates seamlessly with existing DynamoDB API calls.

Exam trap

The trap here is that candidates may confuse DAX with other caching services like ElastiCache, but DAX is purpose-built for DynamoDB and requires no application code changes, whereas ElastiCache would need custom scripts to manage cache invalidation and data population.

How to eliminate wrong answers

Option B (Amazon Kinesis Data Firehose) is wrong because it is a streaming data ingestion service for loading data into data stores like S3 or Redshift, not a caching layer for reducing DynamoDB read latency or table load. Option C (AWS Glue Data Catalog) is wrong because it is a metadata repository for ETL jobs and data discovery, not a low-latency cache for DynamoDB queries. Option D (S3 Transfer Acceleration) is wrong because it speeds up uploads to S3 over long distances using edge locations, but it does not cache DynamoDB data or reduce read latency for repeated queries.

Full explanation →

169

Multi-Selecthard

A company is encrypting sensitive S3 data for a claims portal with AWS KMS. Which two controls help prevent accidental use of the KMS key by unauthorized principals?

Select 2 answers

A.A larger KMS key rotation period

B.IAM policies that grant kms:Decrypt only to required application roles

C.A key policy that limits key administrators and key users

D.S3 Transfer Acceleration

AnswersB, C

IAM permissions should grant least-privilege use of the KMS key to specific roles.

Why this answer

IAM policies can be used to restrict the `kms:Decrypt` action to only the specific IAM roles that require it for the claims portal. This ensures that even if an unauthorized principal has access to the encrypted S3 object, they cannot decrypt it without the explicit IAM permission to use the KMS key. Option C is correct because a key policy that explicitly defines key administrators and key users limits who can manage or use the KMS key, preventing accidental use by unauthorized principals.

Exam trap

The trap here is that candidates often assume that IAM policies alone are sufficient to control KMS key access, but they forget that the key policy must also explicitly allow the IAM principal to use the key, as KMS requires both the key policy and IAM policy to grant access.

Full explanation →

170

MCQmedium

A serverless API built with AWS Lambda serves latency-sensitive requests. The team observes intermittent slow responses during traffic ramp-ups and expects some users to hit the API immediately after a period of inactivity. Which configuration best reduces cold-start latency during these ramp-ups?

A.Enable Lambda provisioned concurrency on a published alias used by the API, and set a minimum provisioned concurrency greater than zero.

B.Increase the Lambda function’s memory setting; cold starts will always be eliminated regardless of traffic patterns.

C.Switch the Lambda runtime to a newer language version and remove any VPC configuration so the function never cold starts.

D.Set an API Gateway stage variable to "warm" the function at request time, which forces immediate initialization.

AnswerA

Provisioned concurrency keeps a defined number of Lambda execution environments initialized and ready behind a specific alias. When traffic ramps up—especially after inactivity—invocations can use pre-initialized environments, reducing or eliminating cold starts for those requests.

Why this answer

Lambda provisioned concurrency keeps a specified number of execution environments initialized and ready to respond immediately, eliminating cold starts for those invocations. By setting a minimum provisioned concurrency greater than zero on the alias used by API Gateway, the function remains warm even after periods of inactivity, ensuring consistent low latency during traffic ramp-ups.

Exam trap

The trap here is that candidates confuse provisioned concurrency with reserved concurrency, or assume that increasing memory or changing runtime settings can fully eliminate cold starts, when only provisioned concurrency guarantees pre-warmed execution environments for latency-sensitive workloads.

How to eliminate wrong answers

Option B is wrong because increasing memory reduces cold-start duration but does not eliminate cold starts; they still occur after inactivity. Option C is wrong because switching runtimes or removing VPC configuration does not prevent cold starts; VPC-enabled functions have additional cold-start overhead, but all Lambda functions can cold start regardless of runtime or VPC settings. Option D is wrong because API Gateway stage variables are static configuration values, not mechanisms to warm functions; they cannot force initialization at request time.

Full explanation →

171

MCQmedium

A ticket booking system runs on EC2 instances behind an Application Load Balancer. The design must tolerate the failure of one Availability Zone. What should the Auto Scaling group configuration include? The architecture review board prefers a managed AWS-native control.

A.Subnets in at least two Availability Zones with health checks enabled

B.All instances in one larger subnet

C.A Network Load Balancer in one subnet

D.A single EC2 instance with detailed monitoring

AnswerA

An Auto Scaling group spanning multiple AZs can replace unhealthy instances and maintain capacity during an AZ failure.

Why this answer

An Auto Scaling group configured with subnets in at least two Availability Zones ensures that if one AZ fails, the remaining AZ(s) can continue to serve traffic. Health checks on the EC2 instances allow the Auto Scaling group to detect and replace unhealthy instances, maintaining the desired capacity across the surviving AZs. This aligns with the requirement for a managed AWS-native control to tolerate an AZ failure.

Exam trap

The trap here is that candidates might think a single large subnet or a Network Load Balancer provides AZ resilience, but subnets are AZ-scoped and an NLB is a separate load-balancing component, not an Auto Scaling group configuration setting.

How to eliminate wrong answers

Option B is wrong because placing all instances in one larger subnet, even if it spans multiple AZs (which is not possible as subnets are AZ-specific), does not provide AZ failure tolerance; a single AZ failure would take down all instances. Option C is wrong because a Network Load Balancer (NLB) is not a component of an Auto Scaling group configuration; the question asks what the Auto Scaling group should include, and an NLB is a separate resource, not a configuration setting within the group. Option D is wrong because a single EC2 instance, even with detailed monitoring, cannot tolerate the failure of one Availability Zone; if that instance resides in the failed AZ, the application becomes unavailable, and detailed monitoring does not provide redundancy.

Full explanation →

172

MCQmedium

A solutions architect is designing an S3 bucket for a order processing API. The objects must never be publicly accessible, even if a developer later adds an overly broad bucket policy. What should the architect configure?

A.Enable S3 Block Public Access at the account or bucket level

B.Enable server access logging on the bucket

C.Create an IAM policy that denies s3:GetObject to anonymous users

D.Enable S3 Transfer Acceleration

AnswerA

Enabling S3 Block Public Access at either the account or bucket level is the most robust and recommended control for preventing unintended public exposure of S3 buckets. This feature provides four distinct settings that can be applied to block public access granted through new or existing bucket policies, access control lists (ACLs), or any combination thereof. By enforcing these settings, S3 Block Public Access acts as a comprehensive safeguard, overriding any conflicting permissions that might otherwise inadvertently grant public read or write access to objects.

Why this answer

S3 Block Public Access provides a definitive override that prevents any public access to objects, regardless of bucket policies or ACLs. By enabling this setting at the account or bucket level, the architect ensures that even if a developer later adds an overly broad bucket policy, the objects remain inaccessible to anonymous users. This is the only option that guarantees no public access can be inadvertently granted.

Exam trap

The trap here is that candidates may think an IAM policy denying anonymous access is sufficient, but they miss that bucket policies can override IAM policies when both are evaluated, making S3 Block Public Access the only foolproof solution.

How to eliminate wrong answers

Option B is wrong because server access logging only records requests made to the bucket; it does not enforce any access restrictions. Option C is wrong because an IAM policy that denies s3:GetObject to anonymous users can be overridden by a later bucket policy that grants public access, as IAM and bucket policies are evaluated together and a bucket policy can explicitly allow what an IAM policy denies. Option D is wrong because S3 Transfer Acceleration is a performance feature that speeds up uploads over long distances; it has no effect on access control or public accessibility.

Full explanation →

173

MCQmedium

A analytics dashboard uses RDS MySQL and receives many read-only reporting queries that slow down the primary database. What should the architect add? The team wants the control to be enforceable during normal operations.

A.S3 lifecycle policy

B.RDS read replica and route reporting queries to it

C.Multi-AZ standby and route reads to the standby

D.A larger NAT gateway

AnswerB

Read replicas offload read traffic from the primary instance.

Why this answer

B is correct because an RDS read replica is designed to offload read-heavy workloads from the primary database instance. By routing reporting queries to the read replica, the primary database is freed from processing these read-only requests, improving overall performance. This solution is enforceable during normal operations as the read replica is always available for reads, unlike a Multi-AZ standby which is not accessible for reads.

Exam trap

The trap here is confusing a Multi-AZ standby (which is not readable) with a read replica (which is readable), leading candidates to incorrectly choose C thinking the standby can serve reads.

How to eliminate wrong answers

Option A is wrong because an S3 lifecycle policy manages object transitions and expirations in S3, not database query routing or read offloading. Option C is wrong because a Multi-AZ standby is a synchronous replica used only for failover and is not accessible for read queries during normal operations; routing reads to it would fail. Option D is wrong because a larger NAT gateway increases outbound internet capacity for private subnets, which does not address database read performance or query routing.

Full explanation →

174

MCQeasy

A retail platform needs disaster recovery across AWS Regions. The business requirement is: RTO up to 6 hours, RPO up to 1 hour, and they want the ability to start serving quickly during a Region outage but do not want to run full production capacity continuously. Which DR strategy best fits these requirements?

A.Backup and restore only, with no continuously running infrastructure in the secondary Region.

B.Pilot light, keeping only the minimum resources needed to bootstrap the environment.

C.Warm standby, keeping a reduced but ready-to-scale environment in the secondary Region.

D.Multi-site active-active, serving production traffic from both Regions at all times.

AnswerC

Warm standby maintains enough infrastructure to reduce recovery time, while not fully running production capacity continuously.

Why this answer

Warm standby is the best fit because it maintains a scaled-down but fully functional copy of the production environment in the secondary Region, allowing the RTO of 6 hours and RPO of 1 hour to be met without running full production capacity continuously. During a disaster, the standby environment can be scaled up quickly to serve traffic, balancing cost and recovery speed.

Exam trap

The trap here is that candidates confuse pilot light with warm standby, assuming that minimal resources (pilot light) can meet the 6-hour RTO, but pilot light requires manual provisioning of compute and scaling, which often exceeds the RTO, while warm standby provides a pre-provisioned, ready-to-scale environment that meets the requirement.

How to eliminate wrong answers

Option A is wrong because backup and restore only would result in an RTO significantly longer than 6 hours, as it requires provisioning infrastructure and restoring data from backups, which cannot meet the 1-hour RPO or 6-hour RTO. Option B is wrong because pilot light keeps only the minimal core resources (e.g., database, DNS) and requires manual provisioning of compute and scaling, which typically exceeds the 6-hour RTO and may not achieve the 1-hour RPO without additional automation. Option D is wrong because multi-site active-active runs full production capacity in both Regions at all times, which violates the requirement to not run full production capacity continuously and incurs unnecessary cost.

Full explanation →

175

MCQmedium

A caching layer uses Amazon ElastiCache for Redis in front of a stateless web service. The service must continue to read cached responses during maintenance events and should automatically fail over to another node if one AZ becomes impaired. Which design change best satisfies this requirement?

A.Deploy a single-node Redis cluster and rely on application-level retries when cache misses occur.

B.Configure an ElastiCache Redis replication group with automatic failover across multiple Availability Zones.

C.Move the cache into the VPC but keep it in one Availability Zone to reduce network latency.

D.Use a Memcached cluster and configure only client-side connection pooling without failover support.

AnswerB

Multi-AZ replication groups provide redundant nodes and automatic failover, improving cache resilience during AZ events.

Why this answer

An ElastiCache Redis replication group with automatic failover across multiple Availability Zones ensures that if the primary node or its AZ becomes impaired, a read-replica in another AZ is automatically promoted to primary. This allows the stateless web service to continue reading cached responses without interruption, satisfying both the maintenance and AZ impairment requirements.

Exam trap

The trap here is that candidates often confuse Memcached's simplicity with Redis's replication capabilities, assuming that client-side connection pooling alone can handle failover, when in fact Memcached lacks any built-in replication or automatic failover mechanism.

Why the other options are wrong

A single-node Redis cluster lacks automatic failover; if the node or its AZ becomes impaired, the service cannot read cached responses until the node is restored, violating the requirement for continued reads during maintenance and AZ impairment.

Keeping the cache in one Availability Zone does not provide automatic failover to another node if that AZ becomes impaired, failing the requirement for high availability during maintenance events.

Memcached does not support automatic failover or multi-AZ replication; if an AZ becomes impaired, the cache becomes unavailable, violating the requirement for continued reads during maintenance.

When would these options actually be correct?

This option would be correct in a scenario where the application can tolerate cache unavailability (e.g., reads from a slower database are acceptable) and the primary goal is cost minimization, with no requirement for high availability or automatic failover.

If the requirement was to minimize latency for a single-AZ application with no high availability needs, and the question explicitly stated that AZ impairment is not a concern, then deploying in one AZ would be appropriate.

If the requirement was for a simple, low-latency cache that can tolerate data loss and does not need automatic failover (e.g., caching non-critical, recomputable data in a single AZ), Memcached with client-side pooling would be appropriate.

Why candidates pick the wrong answer

Candidates may think a single-node cluster is simpler and cheaper, and assume application-level retries are sufficient to handle failures, underestimating the need for automatic failover to maintain cache availability during AZ impairments.

Candidates may think that reducing network latency by keeping the cache in one AZ is more important than high availability, or they may overlook the failover requirement and focus solely on performance.

Candidates may confuse Memcached's simplicity and speed with high availability, or assume that client-side connection pooling alone provides failover, not realizing Memcached lacks built-in replication and automatic failover.

Full explanation →

176

MCQhard

A financial services company must store audit logs in S3 for 7 years and ensure that no one — including the AWS account root user — can delete or overwrite the logs during the retention period. Which S3 Object Lock configuration should a solutions architect use?

A.Object Lock in Compliance mode with a 7-year retention period

B.Object Lock in Governance mode with a 7-year retention period

C.S3 Versioning with a lifecycle rule to transition objects to Glacier after 7 years

D.A bucket policy with Deny for s3:DeleteObject applied to all principals including root

AnswerA

S3 Object Lock in Compliance mode establishes an unalterable Write Once, Read Many (WORM) state for objects. This mode prevents any user, including the AWS account root user, from deleting or overwriting objects until the specified retention period, in this case, 7 years, has expired. The retention period cannot be shortened or removed by anyone, ensuring the highest level of data immutability required for strict financial regulatory compliance.

Why this answer

S3 Object Lock in Compliance mode prevents ALL users — including the root account — from deleting or overwriting objects before the retention period expires. The retention period itself cannot be shortened once set in Compliance mode.

Governance mode also prevents most deletions, but users with s3:BypassGovernanceRetention permission (and the root account) can delete objects or shorten the retention period. For regulatory requirements where not even root can override, Compliance mode is mandatory.

Exam trap

Candidates choose Governance mode because 'governance' sounds strict. In AWS terminology, Governance is the LESS strict option — it can be bypassed by privileged users. Compliance mode is immutable: no one can remove the retention until the period expires.

This distinction is critical for financial regulations like SEC Rule 17a-4 and FINRA requirements.

Why the other options are wrong

Governance mode can be bypassed by the root account and users with s3:BypassGovernanceRetention permission. This does NOT meet the requirement that no one including root can delete the logs.

S3 Versioning prevents accidental deletion by keeping previous versions, but a privileged user can permanently delete all versions. Lifecycle rules manage storage class transitions — they do not prevent deletion. Compliance mode is required.

Bucket policies cannot restrict the root account. IAM policies (including resource-based policies) cannot override root user permissions. Only AWS Organizations SCPs and S3 Object Lock Compliance mode can restrict root's ability to delete S3 objects.

Full explanation →

177

MCQeasy

Based on the exhibit, which Amazon EFS performance mode is the best fit for this workload?

A.Use General Purpose performance mode for low-latency access.

B.Use Max I/O performance mode to optimize for the highest possible latency tolerance.

C.Use One Zone storage class to increase metadata speed.

D.Use Provisioned Throughput mode because it is the only performance mode available.

AnswerA

General Purpose is the best EFS performance mode when the priority is low latency for small file operations. The exhibit describes a moderate number of clients and latency-sensitive metadata access, which matches the strengths of General Purpose. It is the usual choice for most applications unless the workload specifically needs very large-scale parallel throughput.

Why this answer

The General Purpose performance mode is the best fit for this workload because it provides the lowest latency for file operations, which is critical for latency-sensitive applications such as web serving, content management, and development environments. EFS General Purpose mode is optimized for workloads where consistent low-latency access is required, making it the default and recommended choice for most use cases.

Exam trap

The trap here is that candidates confuse performance modes (General Purpose vs. Max I/O) with throughput modes (Bursting vs. Provisioned) or storage classes (Standard vs.

One Zone), leading them to select options that address throughput or availability rather than latency requirements.

Why the other options are wrong

Max I/O performance mode is designed for high throughput and can handle high I/O, but it does not optimize for latency tolerance; it actually has higher latency variability compared to General Purpose mode, making it unsuitable for a workload requiring low-latency access.

One Zone storage class is a storage class, not a performance mode; it does not affect metadata speed. Metadata performance is determined by the performance mode (General Purpose or Max I/O), not the storage class.

Provisioned Throughput mode is not a performance mode; it is a throughput setting available within General Purpose or Max I/O performance modes. The question asks for a performance mode, and Provisioned Throughput is not one of the two performance modes (General Purpose and Max I/O).

When would these options actually be correct?

A question describing a workload with high throughput requirements, such as big data processing or media transcoding, where latency is less critical and the application can tolerate higher variability, would make Max I/O the correct choice.

A question asks which EFS storage class to use for a workload that can tolerate data loss in the event of an Availability Zone failure and requires lower storage costs. In that scenario, One Zone storage class would be correct.

This option would be correct if the question asked: 'Which throughput mode should be used for a workload that requires a consistent, high throughput regardless of the amount of data stored?' In that scenario, Provisioned Throughput mode is the correct choice.

Why candidates pick the wrong answer

Candidates may mistakenly think 'Max I/O' implies better performance across all metrics, including latency, or they may confuse it with Provisioned Throughput mode, assuming it offers more control over performance.

Candidates may confuse storage classes with performance modes, or incorrectly believe that One Zone storage class improves metadata performance due to its local nature.

Candidates may confuse 'performance mode' with 'throughput mode' because both terms involve optimizing file system performance, leading them to select Provisioned Throughput as a performance mode.

Full explanation →

178

MCQmedium

Your EC2 instances run in private subnets with no NAT gateway. The instances use the AWS SDK to call STS AssumeRole to obtain temporary credentials for other services. Application logs show errors like: "EndpointConnectionError: Could not connect to https://sts.<region>.amazonaws.com". Which change most directly resolves this while keeping instances private?

A.Create an interface VPC endpoint for STS (com.amazonaws.<region>.sts) and associate it with the instance subnets and a security group that allows HTTPS.

B.Create a gateway VPC endpoint for S3 and route the STS traffic through the S3 endpoint gateway.

C.Open an inbound rule in the instances’ security group to allow outbound HTTPS to the internet CIDR block directly.

D.Attach an Internet Gateway to the private subnet route table so the STS API can be reached over public internet.

AnswerA

Interface endpoints provide private, in-VPC connectivity to AWS APIs like STS without requiring internet access or NAT.

Why this answer

The error indicates the EC2 instances cannot reach the STS public endpoint over the internet because they are in private subnets without a NAT gateway. An interface VPC endpoint for STS (com.amazonaws.<region>.sts) allows private, direct connectivity to the STS API using AWS PrivateLink, without requiring internet access. Associating the endpoint with the instance subnets and a security group that allows HTTPS (port 443) resolves the connectivity issue while keeping the instances private.

Exam trap

The trap here is that candidates often confuse gateway endpoints (which only work for S3 and DynamoDB) with interface endpoints (which work for many services like STS), or they mistakenly think security group rules alone can enable outbound internet access without a route.

How to eliminate wrong answers

Option B is wrong because a gateway VPC endpoint for S3 only provides private connectivity to S3, not to STS; STS is a different service and cannot be reached through an S3 endpoint. Option C is wrong because opening an inbound rule in the instances’ security group for outbound HTTPS to the internet CIDR block does not provide a route to the internet; the instances are in private subnets with no NAT gateway or internet gateway, so outbound traffic to the internet is blocked regardless of security group rules. Option D is wrong because attaching an Internet Gateway to the private subnet route table would make the subnet public, violating the requirement to keep instances private; it would also expose the instances to inbound internet traffic.

Full explanation →

179

Multi-Selectmedium

An order-processing worker consumes messages from Amazon SQS. Occasionally, the worker times out after successfully creating a payment record but before deleting the message, which causes duplicate charges during retries. Some messages also fail validation repeatedly because required fields are missing. Which two changes should the team make? Select two.

Select 2 answers

A.Make the payment step idempotent using a unique transaction identifier.

B.Configure an SQS dead-letter queue with a redrive policy.

C.Reduce the visibility timeout so failed messages return to the queue faster.

D.Run only one long-lived worker instance so the queue can never be processed twice.

E.Switch from a standard queue to a FIFO queue and remove all other changes.

AnswersA, B

Correct. SQS provides at-least-once delivery, so the same message can be processed more than once if the worker times out, retries, or crashes after partially completing the work. An idempotency key lets the application recognize that the payment was already created and prevents duplicate charges.

Why this answer

Making the payment step idempotent using a unique transaction identifier ensures that if the same message is processed multiple times due to a timeout, the payment is only charged once. This is a common pattern for handling at-least-once delivery semantics in Amazon SQS, where the worker must be designed to handle duplicate messages safely.

Exam trap

The trap here is that candidates often think reducing the visibility timeout will speed up recovery, but it actually increases the chance of duplicate processing, and they may also overlook that a FIFO queue alone does not fix the worker's failure to delete the message after processing.

Full explanation →

180

MCQmedium

A marketing team runs a report-generation process that must execute once per day at 02:00 UTC. It usually completes in 10315 minutes, but sometimes takes up to 45 minutes due to varying data volumes. They currently run the workload on an EC2 instance that is always on, which wastes money during off-hours. The team wants to minimize operational overhead and pay mainly for actual execution time. What is the best architecture choice?

A.Use a scheduled Amazon EC2 Auto Scaling group that keeps a minimum of one instance running at all times.

B.Use an EventBridge schedule to run the report as an Amazon ECS task on AWS Fargate and write results to S3.

C.Use AWS Lambda triggered by an EventBridge schedule at 02:00 UTC and write results to S3.

D.Use an EMR cluster provisioned daily with manual teardown to ensure the instance is always available before 02:00.

AnswerB

Fargate allows the containerized job to run only when scheduled, so the team pays for task runtime instead of keeping an EC2 instance always on.

Why this answer

Amazon ECS on AWS Fargate is the best choice because it eliminates the need to manage servers, scales automatically, and charges only for the vCPU and memory resources consumed during task execution. The EventBridge schedule triggers the Fargate task at 02:00 UTC, and the report is written to S3, which provides durable, cost-effective storage. This architecture minimizes operational overhead and cost by avoiding an always-on EC2 instance.

Exam trap

The trap here is that candidates may choose AWS Lambda without considering its 15-minute execution timeout, which cannot handle the 45-minute maximum runtime of this report-generation process.

Why the other options are wrong

This option keeps an instance running at all times, which wastes money during off-hours and does not minimize operational overhead or pay mainly for actual execution time.

AWS Lambda has a maximum execution timeout of 15 minutes, but the report-generation process can take up to 45 minutes, so Lambda cannot handle the entire workload.

Provisioning an EMR cluster daily with manual teardown introduces significant operational overhead, which contradicts the requirement to minimize operational overhead. Additionally, EMR is designed for big data processing (e.g., Spark, Hive) and is overkill for a simple report-generation task, leading to higher costs and complexity.

When would these options actually be correct?

A scheduled Auto Scaling group with a minimum of one instance is correct when the workload requires a persistent server (e.g., for real-time processing or stateful applications) and cost optimization is not the primary concern.

A question where the task completes in under 15 minutes, requires no containerization, and benefits from Lambda's serverless, pay-per-execution model with minimal operational overhead.

This option would be correct if the workload involved large-scale data processing (e.g., running Spark or Hive jobs on terabytes of data) that requires a distributed cluster, and the team already has operational processes in place to manage cluster lifecycle automatically (e.g., using AWS Step Functions or Lambda for teardown). The question would emphasize cost savings by running only when needed, but not prioritize minimizing overhead.

Why candidates pick the wrong answer

Candidates may think Auto Scaling is cost-effective, but the 'minimum one instance' requirement contradicts the goal of paying only for execution time.

Candidates see 'EventBridge schedule' and 'serverless' and assume Lambda is the simplest choice, overlooking the 15-minute timeout limit.

Candidates may think EMR is suitable for any 'report generation' task, especially if they associate it with data processing. The manual teardown might seem like a simple way to save costs, but they overlook the operational burden and the fact that simpler services (like ECS Fargate) can handle the workload more efficiently.

Full explanation →

181

MCQeasy

Your application uses ElastiCache Redis as a cache for user profiles stored in DynamoDB. You must ensure that when a profile is updated, subsequent reads see the latest value quickly. Which cache strategy is generally the best fit for this requirement?

A.Write to DynamoDB only, and never update or invalidate the Redis cache.

B.Use a cache-aside approach with TTL plus explicit invalidation after writes.

C.Cache only for reads, and do not fetch from DynamoDB when a key is missing.

D.Rely on eventual consistency of Redis replication to propagate updates to all nodes.

AnswerB

A cache-aside (lazy loading) pattern reads from cache first; if missing/expired, it fetches from the source of truth. After an update, explicitly invalidating or updating the cached entry ensures subsequent reads quickly reflect changes. TTL provides protection against missed invalidations while invalidation accelerates correctness after writes.

Why this answer

The cache-aside (lazy loading) pattern with TTL plus explicit invalidation ensures that after a write to DynamoDB, the stale Redis entry is removed, forcing the next read to fetch the updated profile from DynamoDB and repopulate the cache. This minimizes the window of inconsistency while keeping cache management simple and efficient for user profile workloads.

Exam trap

The trap here is that candidates may confuse cache-aside with write-through or write-behind patterns, or assume that Redis replication alone can solve cache consistency, when in fact explicit invalidation is required to ensure reads see the latest value after a write to the primary data store.

Why the other options are wrong

This option never updates or invalidates the cache, so after a profile update in DynamoDB, the Redis cache still serves stale data until the TTL expires, violating the requirement that subsequent reads see the latest value quickly.

This option fails because if a key is missing in the cache, the application never fetches the profile from DynamoDB, so stale or missing data persists indefinitely, violating the requirement that subsequent reads see the latest value quickly.

Redis replication is asynchronous, so relying on eventual consistency does not guarantee that subsequent reads see the latest value quickly after a write. This strategy can lead to stale reads until replication completes.

When would these options actually be correct?

If the question stated that user profiles are immutable (never updated after creation) or that the application can tolerate stale data for the entire TTL period, then writing only to DynamoDB without cache invalidation would be acceptable.

This strategy would be correct in a scenario where the data is static or changes very rarely, and the cache is pre-populated with all necessary data. For example, a read-only reference dataset (like country codes) that is loaded once and never updated, where cache misses are acceptable only during initial load.

In a scenario where the requirement is to maximize read throughput and tolerate short periods of stale data, such as a read-heavy application displaying non-critical content (e.g., news headlines) where eventual consistency is acceptable.

Why candidates pick the wrong answer

Candidates may think that a simple write-through or write-around pattern is sufficient, or they underestimate the need for explicit invalidation to ensure read-after-write consistency.

Candidates may think that caching only for reads simplifies the architecture and avoids write-through complexity, but they overlook the need to handle cache misses by fetching from the primary data store to ensure data freshness.

Candidates may assume that Redis replication provides strong consistency or that eventual consistency is sufficient for cache updates, overlooking the need for immediate consistency after profile updates.

Full explanation →

182

MCQhard

Based on the exhibit, which change will most improve the CloudFront cache hit ratio for the static assets while still serving the same files to all users?

A.Create a custom cache policy that includes only the v query string and excludes cookies.

B.Enable Origin Shield and keep the current cache behavior unchanged.

C.Move the static assets to individual presigned URLs for each viewer.

D.Increase the CloudFront default TTL to 24 hours while continuing to forward all cookies and query strings.

AnswerA

This removes unnecessary cache-key fragmentation. Since all users receive identical static files, forwarding user-specific cookies and irrelevant query strings destroys cache reuse. Keeping only the version parameter preserves correct object variation while allowing many more requests to hit the same cached object at the edge.

Why this answer

Static assets (e.g., images, CSS, JS) are typically served identically to all users, so forwarding a unique query string like 'v' for versioning still allows CloudFront to cache a single object per version. By excluding cookies and other query strings, you prevent cache fragmentation caused by irrelevant variations, directly improving the cache hit ratio. This custom cache policy ensures that requests for the same 'v' value are served from the edge cache rather than forwarded to the origin.

Exam trap

The trap here is that candidates assume increasing TTL or enabling Origin Shield will fix a low cache hit ratio, when the real issue is cache key fragmentation caused by forwarding all cookies and query strings.

Why the other options are wrong

Enabling Origin Shield reduces origin load and improves latency but does not affect the cache hit ratio when query strings and cookies are still forwarded, as they cause cache fragmentation.

Using presigned URLs for static assets would not improve cache hit ratio because each presigned URL is unique per viewer, preventing CloudFront from caching and serving the same object to multiple users.

Forwarding all cookies and query strings prevents CloudFront from caching responses effectively because each unique combination creates a separate cache entry, reducing the cache hit ratio.

When would these options actually be correct?

When the question asks for reducing origin load or improving latency for a backend with high request rates, and the current cache behavior already has a high hit ratio.

This option would be correct in a scenario where you need to restrict access to static assets to only authenticated users, such as for a paid content delivery system, and you want to ensure each viewer has a unique, time-limited URL.

If the question asked for improving cache hit ratio for dynamic content that varies by user session (e.g., personalized pages) and the static assets are served from a different origin or path, increasing TTL while forwarding all cookies/query strings could be correct for the dynamic content.

Why candidates pick the wrong answer

Candidates may think Origin Shield improves caching because it centralizes requests, but it does not address the root cause of low cache hit ratio: unnecessary query string and cookie forwarding.

Candidates may think presigned URLs can improve performance by controlling access, but they overlook that uniqueness per viewer defeats caching, which is the opposite of what is needed to improve cache hit ratio.

Candidates may think that increasing TTL always improves cache hit ratio, overlooking that forwarding all cookies and query strings negates the benefit by creating many cache variations.

Full explanation →

183

MCQmedium

A analytics dashboard uses an Application Load Balancer in one Region. Global users need lower network latency to the application without caching dynamic responses. What should be considered? The design must avoid adding custom operational scripts.

A.AWS Global Accelerator

B.S3 Cross-Region Replication

C.AWS Backup cross-Region copy

D.CloudFront only with long TTLs

AnswerA

Global Accelerator routes traffic over the AWS global network to improve performance for TCP/UDP applications without relying on caching.

Why this answer

AWS Global Accelerator uses the AWS global network to route traffic from edge locations to the optimal regional endpoint, reducing latency and jitter for global users. It does not cache content, making it ideal for dynamic responses that cannot be cached. The service requires no custom scripts, as it integrates directly with the Application Load Balancer via a static IP address or DNS name.

Exam trap

The trap here is that candidates often confuse Global Accelerator with CloudFront, assuming both are for caching, but Global Accelerator does not cache content and is specifically designed for non-cacheable, dynamic traffic requiring low latency and fast failover.

How to eliminate wrong answers

Option B (S3 Cross-Region Replication) is wrong because it replicates objects across S3 buckets in different regions, but it does not reduce network latency for dynamic application traffic; it is designed for data redundancy and disaster recovery, not for real-time request routing. Option C (AWS Backup cross-Region copy) is wrong because it copies backup data across regions for compliance or disaster recovery, and it has no impact on live application latency or traffic routing. Option D (CloudFront only with long TTLs) is wrong because CloudFront caches content at edge locations, which violates the requirement to avoid caching dynamic responses; long TTLs would serve stale data, and disabling caching would negate the latency benefit, while custom scripts would be needed to bypass caching for dynamic content.

Full explanation →

184

MCQmedium

A company runs a stateful analytics workload on EC2 instances that use EBS volumes. The data must be restorable in another Region after a major outage, with frequent point-in-time recovery. Which approach provides the most suitable replication mechanism for the EBS-backed data?

A.Create scheduled EBS snapshots and copy them to another Region, then restore the volumes from those snapshots during recovery.

B.Enable EBS multi-attach to spread the workload across AZs and replicate snapshots automatically between Regions.

C.Use RDS read replicas in another Region and keep the analytics dataset in an RDS instance only.

D.Rely on instance store for durability and copy only AMIs across Regions.

AnswerA

Snapshotting and cross-Region copying gives point-in-time images of EBS volumes that can be restored in the target Region.

Why this answer

Scheduled EBS snapshots provide point-in-time backups of EBS volumes, which can be copied to another Region using the cross-Region snapshot copy feature. During recovery, you restore volumes from those snapshots in the target Region, ensuring the data is restorable after a major outage. This approach meets the requirements for frequent point-in-time recovery and cross-Region durability.

Exam trap

The trap here is that candidates may confuse EBS multi-attach (which is for high availability within a single AZ) with cross-Region replication, or mistakenly think instance store provides durability for long-term data recovery.

Why the other options are wrong

EBS multi-attach allows attaching a volume to multiple EC2 instances in the same AZ, but it does not replicate snapshots across Regions or provide cross-Region disaster recovery. It is designed for clustered applications within a single AZ, not for multi-Region replication.

RDS read replicas are for relational databases, not for analytics workloads on EC2 with EBS volumes. The question specifies EBS-backed data, not RDS-managed data, so using RDS would require migrating the dataset and does not replicate EBS snapshots.

Instance store volumes are ephemeral and lose data on instance stop/termination, making them unsuitable for durable, restorable data. Copying AMIs does not replicate the analytics data itself.

When would these options actually be correct?

An exam question requiring high availability for a clustered application (e.g., a shared file system) within a single AZ, where multiple EC2 instances need concurrent read/write access to the same EBS volume, and the question asks for the feature that enables this.

A company runs a web application using Amazon RDS for MySQL and needs to offload read traffic to a secondary Region for low-latency queries. RDS read replicas in another Region would be the correct answer for read scaling and cross-Region disaster recovery.

For a stateless workload where only the AMI (OS and application) needs to be available in another Region for disaster recovery, and the data is stored externally (e.g., in S3 or a database).

Why candidates pick the wrong answer

Candidates may confuse 'multi-attach' with cross-Region replication, or think that spreading across AZs implies automatic cross-Region backup, not realizing multi-attach is limited to one AZ and does not handle snapshots.

Candidates may confuse cross-Region replication capabilities of RDS with the need to replicate EBS data, assuming RDS can handle any analytics workload, or they may overlook that the question explicitly mentions EBS volumes and EC2 instances.

Candidates may confuse instance store with EBS, or think that AMI copying provides data replication, overlooking the ephemeral nature of instance store.

Full explanation →

185

MCQhard

A DynamoDB table for a travel booking site has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change? The architecture review board prefers a managed AWS-native control.

A.Create a global secondary index with the same date key

B.Move the table to S3 Glacier Instant Retrieval

C.Reduce the table's write capacity

D.Use a higher-cardinality partition key that distributes writes across partitions

AnswerD

A low-cardinality hot partition causes throttling; a better key spreads writes more evenly.

Why this answer

Using a low-cardinality partition key like the current date causes all writes to land on a single partition, leading to throttling. By choosing a higher-cardinality partition key (e.g., combining date with a user ID or booking ID), writes are distributed evenly across multiple partitions, leveraging DynamoDB's internal partitioning to handle the throughput. This is a managed, AWS-native design change that resolves hot partition issues without additional services.

Exam trap

The trap here is that candidates often confuse a GSI as a solution for write performance, when in fact GSIs only help with read query patterns and do not alleviate write hot spots on the base table.

How to eliminate wrong answers

Option A is wrong because creating a global secondary index (GSI) with the same date key does not solve the write throttling; GSIs have their own write capacity and inherit the same hot partition problem from the base table's partition key. Option B is wrong because moving the table to S3 Glacier Instant Retrieval is not a managed AWS-native control for DynamoDB write throttling; S3 is a different storage service and cannot replace DynamoDB's real-time transactional write capabilities. Option C is wrong because reducing the table's write capacity would worsen throttling during business hours, as it lowers the maximum allowed writes per second, directly contradicting the need to handle high write demand.

Full explanation →

186

MCQmedium

A company hosts an internal HTTP API on an internal Network Load Balancer (NLB) in VPC A. A partner team in a separate AWS account needs access, but their VPC CIDR overlaps with VPC A, so VPC peering is not feasible. Security requirements state the API must remain non-public (no internet-facing ALB/NLB) and access must use AWS private networking. Which architecture best meets these requirements?

A.Use AWS PrivateLink by creating a VPC endpoint service backed by the NLB in VPC A, then create an interface VPC endpoint in the partner VPC with appropriate endpoint access controls.

B.Expose the NLB to the internet with an Elastic IP and restrict access using the NLB’s security group only.

C.Use VPC peering between VPC A and the partner VPC and update route tables to resolve the overlap.

D.Deploy a NAT gateway in VPC A and route the partner’s traffic to the NLB through the NAT gateway.

AnswerA

PrivateLink exposes the service privately via interface endpoints, avoiding peering and keeping the NLB non-public for secure partner access.

Why this answer

AWS PrivateLink allows you to expose an internal NLB in VPC A as a VPC endpoint service, and the partner team can create an interface VPC endpoint in their own VPC to connect privately. This solution avoids overlapping CIDR issues because traffic flows through PrivateLink’s network interfaces using private IPs, not through VPC peering or internet routing. It also satisfies the non-public requirement since the API remains accessible only via private networking within AWS.

Exam trap

The trap here is that candidates may assume VPC peering can handle overlapping CIDRs with route table adjustments, but AWS explicitly prohibits overlapping CIDRs in VPC peering connections, making PrivateLink the only viable private networking option.

Why the other options are wrong

The NLB cannot be made internet-facing with an Elastic IP because the requirement explicitly states the API must remain non-public and use AWS private networking. Additionally, NLB security groups are not supported; security is managed via subnet ACLs and target group health checks.

VPC peering cannot resolve overlapping CIDR blocks; overlapping IP ranges make routing impossible, and the requirement for non-public access is already met by peering, but the overlap is the blocker.

A NAT gateway is used for outbound internet access from private subnets, not for inbound traffic from another VPC. It cannot route traffic from a partner VPC to an internal NLB, and it does not resolve VPC CIDR overlap issues.

When would these options actually be correct?

This option would be correct if the question allowed a public-facing API and required high availability with static IP addresses, such as for a customer-facing application that needs to whitelist IPs in a firewall, and there was no restriction on internet exposure.

This option would be correct if the VPCs had non-overlapping CIDR blocks and the requirement was to connect two VPCs privately without using a VPN or AWS Transit Gateway, and the API was accessible via an internal NLB or ALB.

If the requirement were for a private subnet in VPC A to access the internet (e.g., download patches) while remaining non-public, a NAT gateway in a public subnet would be correct. The question would specify outbound internet access from a private subnet.

Why candidates pick the wrong answer

Candidates may think adding an Elastic IP to the NLB is a simple way to make it reachable from another account, overlooking the non-public requirement and the fact that NLB security groups are not supported.

Candidates may think VPC peering is the simplest private connectivity method and overlook the CIDR overlap constraint, or assume overlapping ranges can be handled with route table adjustments.

Candidates may confuse NAT gateway with a solution for cross-VPC connectivity, thinking it can forward inbound traffic, or they may mistakenly believe it can handle overlapping CIDRs by translating addresses.

Full explanation →

187

MCQhard

Based on the exhibit, the platform team wants developers to create application roles for Lambda and ECS, but no developer-created role may ever exceed the approved permission set. Which change best meets this requirement?

A.Remove all IAM permissions from AppProvisioner and require a central security team to create every role manually.

B.Attach a permissions boundary strategy to the delegated workflow and require every created role to include that boundary using the iam:PermissionsBoundary condition.

C.Allow developers to keep creating roles, but add a CloudTrail rule that alerts security after a privileged policy is attached.

D.Move the delegated IAM workflow into a separate VPC and restrict it with security groups and network ACLs.

AnswerB

A permissions boundary creates an upper limit on what any developer-created role can ever do, even if someone later attaches broader policies. Requiring the boundary during role creation prevents privilege escalation while still allowing delegated self-service for approved application roles. This is the standard AWS pattern when teams need to create roles but must remain inside a strict security envelope.

Why this answer

It uses an IAM permissions boundary attached to the delegated role creation workflow, combined with the `iam:PermissionsBoundary` condition key to enforce that every developer-created role must include that boundary. This ensures no role can exceed the approved permission set, as the boundary acts as a maximum limit on permissions, even if the role's policy grants more. The delegated workflow (e.g., AWS Service Catalog or IAM Role creation via Lambda) can create roles, but the boundary prevents any escalation beyond the predefined scope.

Exam trap

The trap here is that candidates confuse reactive monitoring (like CloudTrail alerts) with preventive controls, or mistakenly think network isolation (VPC/security groups) can restrict IAM permissions, when only IAM boundaries or service control policies (SCPs) can cap permissions at the identity level.

How to eliminate wrong answers

Option A is wrong because removing all IAM permissions from AppProvisioner and requiring manual role creation by a central security team eliminates the delegation entirely, which contradicts the requirement that developers create application roles for Lambda and ECS; it also introduces operational bottlenecks and does not leverage IAM boundaries. Option C is wrong because adding a CloudTrail rule to alert after a privileged policy is attached is reactive, not preventive; it does not stop a developer-created role from exceeding the approved permission set at creation time, violating the 'may never exceed' requirement. Option D is wrong because moving the delegated IAM workflow into a separate VPC with security groups and network ACLs addresses network-level access control, not IAM permission boundaries; it cannot restrict the permissions of IAM roles created by developers, as IAM policies are not governed by network constructs.

Full explanation →

188

Multi-Selecthard

A SaaS vendor has a steady 24/7 control plane on ECS and several small event-driven tasks that currently run on a separate always-on service. Management wants the billing discount that applies across both ECS and Lambda usage without committing to a specific instance family. Which two actions are best? Select two.

Select 2 answers

A.Buy a Compute Savings Plan for the predictable baseline usage.

B.Move the event-driven tasks to AWS Lambda instead of keeping a separate always-on service.

C.Buy an EC2 Instance Savings Plan tied to one instance family for all workloads.

D.Use Spot Instances for the control plane because it is the largest bill.

E.Increase the ECS desired count so Lambda can be removed.

AnswersA, B

Correct. A Compute Savings Plan discounts predictable compute spend across ECS and Lambda without binding the team to one instance family. That flexibility matches a mixed compute estate and avoids overcommitting.

Why this answer

A Compute Savings Plan offers the largest discount (up to 66%) across both ECS and Lambda usage without committing to a specific instance family, which matches the requirement to cover both services flexibly. It applies to any EC2 instance, including those used by ECS, and to AWS Lambda compute, making it ideal for a mixed workload with a predictable baseline.

Exam trap

The trap here is that candidates confuse Savings Plans with Reserved Instances or Spot Instances, assuming a specific instance family commitment is required, or they think Spot Instances can replace a billing discount mechanism for a steady workload.

Why the other options are wrong

An EC2 Instance Savings Plan is tied to a specific instance family and region, which does not cover Lambda usage. The question requires a discount that applies across both ECS and Lambda, so a Compute Savings Plan is needed instead.

The control plane runs 24/7 and is steady, so it is not suitable for Spot Instances, which can be interrupted. The question asks for a discount covering both ECS and Lambda, but Spot Instances only apply to EC2, not Lambda.

Increasing ECS desired count does not provide a billing discount across ECS and Lambda usage; it only increases ECS costs and does not eliminate the need for Lambda or provide a savings plan.

When would these options actually be correct?

This option would be correct if the question asked for the best discount for a workload running entirely on EC2 instances of a known, consistent family, with no serverless components like Lambda.

A question where a non-critical, fault-tolerant workload (e.g., batch processing, data analysis) runs on EC2 and the goal is to reduce costs by up to 90% without needing a discount plan covering Lambda. The workload must handle interruptions gracefully.

If the question asked for a way to handle variable workloads by scaling ECS tasks instead of using Lambda, and the goal was to consolidate all compute on ECS for simplicity, then increasing ECS desired count could be correct.

Why candidates pick the wrong answer

Candidates may confuse Instance Savings Plans with Compute Savings Plans, or assume that all Savings Plans cover all compute services, not realizing the family/region restriction on Instance Savings Plans.

Candidates know Spot Instances offer large discounts and may assume they apply to any EC2-based workload, overlooking the interruption risk and the requirement for a discount covering both ECS and Lambda.

Candidates may think that running more on ECS reduces the need for separate services, but they overlook that this does not achieve the desired discount across both services and may increase costs.

Full explanation →

189

MCQhard

Based on the exhibit, which storage design best supports the application servers' shared working directory requirement?

A.Mount Amazon EFS on every EC2 instance and use it as the shared workspace.

B.Attach one gp3 EBS volume to each instance and synchronize the files with cron jobs.

C.Store the artifacts in S3 and have each node read them directly from S3 as a filesystem.

D.Use instance store on each instance because it provides the fastest local file access.

AnswerA

EFS provides shared, persistent, POSIX-compliant file access across multiple EC2 instances and Availability Zones. That matches the requirement that all nodes see the same workspace immediately and that files survive instance replacement. It is the right choice when the application needs a common filesystem rather than an object store or local-only disk.

Why this answer

Amazon EFS provides a fully managed, NFS-based shared file system that can be mounted concurrently on multiple EC2 instances across multiple Availability Zones. This directly satisfies the requirement for a shared working directory where all application servers can read and write files simultaneously without additional synchronization overhead.

Exam trap

The trap here is that candidates often confuse object storage (S3) with shared file storage, assuming S3 can serve as a drop-in replacement for a POSIX filesystem, but S3 lacks file locking, atomic renames, and low-latency metadata operations required for a shared working directory.

Why the other options are wrong

Synchronizing files with cron jobs introduces latency and inconsistency, failing to provide a real-time shared working directory as required by the application servers.

Using S3 as a filesystem (e.g., via s3fs) introduces latency and consistency issues that are unsuitable for a shared working directory requiring low-latency, POSIX-compliant file operations across multiple EC2 instances.

Instance store provides temporary, block-level storage that is physically attached to the host, but data is lost if the instance is stopped or terminated. It cannot serve as a persistent shared working directory across multiple EC2 instances.

When would these options actually be correct?

This option would be correct if the requirement was for each instance to have its own independent working directory with periodic backups or synchronization for disaster recovery, not a shared real-time workspace.

When the application servers need to read static artifacts (e.g., configuration files, binaries) that are rarely updated, and the design prioritizes cost savings over low-latency file operations, S3 with direct reads (e.g., via SDK) would be a correct choice.

For a scenario requiring the highest I/O performance for temporary, non-persistent data that is unique to each instance (e.g., scratch space for large-scale data processing), where data loss on instance stop is acceptable.

Why candidates pick the wrong answer

Candidates may think that using EBS volumes with cron-based sync is a cost-effective way to achieve file sharing, underestimating the complexity and inconsistency of distributed synchronization.

Candidates may think S3 is a universal storage solution and overlook its lack of POSIX semantics and higher latency compared to EFS, especially when the question mentions 'shared working directory' which implies frequent, concurrent file operations.

Candidates may assume that the fastest local storage (instance store) is always the best choice, overlooking the requirement for persistence and sharing across instances.

Full explanation →

190

MCQeasy

A web application runs on an Amazon EC2 Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ALB is configured to use at least two Availability Zones (AZs), but the ASG currently uses subnets in only one AZ. If that AZ becomes unavailable, the application stops serving requests. Which change most directly improves resilience to an AZ outage?

A.Keep the ASG in one Availability Zone, but reduce ALB health check intervals.

B.Place the ASG across multiple Availability Zones by configuring it with subnets in at least two AZs.

C.Switch the load balancer from an ALB to an NLB to remove HTTP health check dependency.

D.Add an Amazon SQS queue to buffer requests during failures.

AnswerB

An ASG launches instances into the AZs of the subnets you specify. By placing the ASG in at least two AZs, the ALB can route traffic to healthy targets in the remaining AZ(s) if one AZ fails, enabling recovery as new instances maintain desired capacity.

Why this answer

Distributing an Auto Scaling group across multiple Availability Zones (AZs) ensures that if one AZ fails, the remaining AZs continue to serve traffic. The Application Load Balancer (ALB) is already configured for at least two AZs, but the ASG’s single-AZ subnet placement creates a single point of failure. By adding subnets in at least two AZs to the ASG, the application becomes resilient to an AZ outage without any other architectural changes.

Exam trap

The trap here is that candidates assume the ALB’s multi-AZ configuration automatically protects the application, overlooking that the ASG must also span multiple AZs to provide compute redundancy.

How to eliminate wrong answers

Option A is wrong because reducing health check intervals only detects failures faster but does not eliminate the single point of failure; if the sole AZ becomes unavailable, no healthy instances exist to serve traffic. Option C is wrong because switching from an ALB to an NLB does not address the root cause—the ASG is still in one AZ—and HTTP health checks are not the issue; the ALB can already perform health checks across AZs. Option D is wrong because adding an SQS queue buffers requests but does not provide compute capacity in another AZ; without instances in a second AZ, the queue cannot process requests during an AZ outage.

Full explanation →

191

MCQmedium

A test environment runs on x86 EC2 instances and uses open-source software with no architecture-specific licensing restriction. What should be evaluated to reduce compute cost? The design must avoid adding custom operational scripts.

A.Cross-Region data replication for all data

B.AWS Graviton-based instances after performance testing

C.io2 Block Express volumes for all instances

D.Dedicated Hosts by default

AnswerB

Graviton instances often provide better price performance for compatible workloads.

Why this answer

AWS Graviton-based instances (ARM architecture) offer up to 40% better price-performance compared to x86 instances for many workloads. Since the environment uses open-source software with no architecture-specific licensing restrictions, migrating to Graviton after performance testing can significantly reduce compute costs without requiring custom operational scripts, as AWS provides native support for ARM-based instances.

Exam trap

The trap here is that candidates may confuse cost optimization with performance improvement or licensing requirements, leading them to select Dedicated Hosts or high-performance storage options that actually increase costs.

How to eliminate wrong answers

Option A is wrong because cross-region data replication increases data transfer and storage costs, and it does not directly address compute cost reduction. Option C is wrong because io2 Block Express volumes are high-performance, high-cost EBS volumes designed for I/O-intensive workloads, not for reducing compute costs, and they would increase storage costs unnecessarily. Option D is wrong because Dedicated Hosts incur additional per-host charges and are used for licensing or compliance requirements, not for cost optimization; they would increase compute costs rather than reduce them.

Full explanation →

192

Multi-Selectmedium

A company is running a production web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The workload has predictable traffic spikes during business hours and low traffic at night. The current architecture uses On-Demand EC2 instances, leading to high costs. The company wants to reduce costs without sacrificing availability or performance. Which three of the following strategies would help achieve this goal? (Choose three.)

Select 3 answers

.Purchase Reserved Instances for the baseline capacity that runs 24/7.

.Add Spot Instances for the entire workload during peak hours.

.Use Auto Scaling with a mixed instances policy that includes On-Demand and Spot Instances.

.Migrate to AWS Lambda for all web application traffic.

.Implement a scheduled scaling action to increase capacity before business hours and decrease after.

.Consolidate all instances into a single larger instance to reduce overhead.

Why this answer

Purchasing Reserved Instances for the baseline 24/7 capacity provides a significant discount (up to 72%) compared to On-Demand pricing, directly reducing costs for the always-running portion of the workload. This strategy is correct because it matches the predictable, steady-state traffic component without sacrificing availability or performance.

Exam trap

The trap here is that candidates may think Spot Instances can be used for the entire workload during peak hours, but they overlook the interruption risk and the requirement for the workload to be fault-tolerant, which a production web application behind an ALB typically is not without careful design.

Full explanation →

193

MCQhard

A DynamoDB table for a retail API has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change?

A.Use a higher-cardinality partition key that distributes writes across partitions

B.Create a global secondary index with the same date key

C.Reduce the table's write capacity

D.Move the table to S3 Glacier Instant Retrieval

AnswerA

A low-cardinality hot partition causes throttling; a better key spreads writes more evenly.

Why this answer

Using a partition key based solely on the current date creates a 'hot partition' because all writes for that day target the same partition, leading to throttling. A higher-cardinality partition key (e.g., combining date with a unique attribute like user ID or order ID) distributes write traffic evenly across multiple partitions, allowing DynamoDB to utilize its full throughput capacity and eliminating throttling.

Exam trap

The trap here is that candidates may think a GSI can solve write throttling, but GSIs only help with read patterns and do not redistribute write load on the base table.

How to eliminate wrong answers

Option B is wrong because creating a global secondary index (GSI) with the same date key does not change the base table's partition key; writes still target the same hot partition, so throttling persists. Option C is wrong because reducing the table's write capacity would worsen throttling, not solve it, as the issue is uneven distribution, not insufficient total capacity. Option D is wrong because S3 Glacier Instant Retrieval is an object storage service for archival data, not a transactional database; it cannot support DynamoDB's low-latency read/write operations or query patterns.

Full explanation →

194

MCQmedium

A trading dashboard stores uploaded documents in S3. The business requires a copy in another AWS Region for disaster recovery. What should be configured? The design must avoid adding custom operational scripts.

A.An EBS snapshot schedule

B.S3 Cross-Region Replication with versioning enabled

C.S3 lifecycle transition to Glacier Flexible Retrieval

D.A CloudFront distribution

AnswerB

CRR asynchronously replicates objects to a bucket in another Region and requires versioning.

Why this answer

S3 Cross-Region Replication (CRR) automatically replicates objects to a destination bucket in a different AWS Region, meeting the disaster recovery requirement without custom scripts. Versioning must be enabled on both source and destination buckets for CRR to function, as it tracks object versions and ensures consistency during replication.

Exam trap

The trap here is that candidates may confuse S3 Cross-Region Replication with S3 lifecycle policies or CloudFront, thinking they provide cross-region replication, but only CRR with versioning enabled meets the DR requirement without custom scripts.

How to eliminate wrong answers

Option A is wrong because EBS snapshots are for Amazon Elastic Block Store volumes attached to EC2 instances, not for S3 objects; they cannot replicate S3 data across regions. Option C is wrong because S3 lifecycle transitions to Glacier Flexible Retrieval only change storage class within the same region for cost optimization, not replicate data to another region. Option D is wrong because CloudFront is a content delivery network (CDN) that caches content at edge locations for low-latency access, not a replication mechanism for disaster recovery across regions.

Full explanation →

195

MCQmedium

An order-quote Lambda function is invoked directly by API Gateway. Traffic is predictable during the business day, and the first request after scaling from zero causes unacceptable latency. The team wants to keep the current architecture and reduce cold-start impact. Which configuration should they use?

A.Increase the function timeout so the first invocation has more time to finish.

B.Enable provisioned concurrency for the Lambda function.

C.Set reserved concurrency to a fixed number and leave the rest unchanged.

D.Increase the memory size only to eliminate cold starts.

AnswerB

Provisioned concurrency keeps a set number of Lambda execution environments initialized and ready to serve traffic. That directly reduces or removes cold starts for predictable workloads such as business-hours APIs. It is the most appropriate choice when the team wants to preserve serverless architecture while delivering consistent response times for the first request and subsequent requests.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, so when the first request arrives after scaling from zero, it is served by a pre-warmed instance instead of incurring a cold start. This directly addresses the unacceptable latency without changing the architecture or requiring code modifications.

Exam trap

The trap here is that candidates confuse reserved concurrency (which caps concurrent executions) with provisioned concurrency (which pre-warms instances), or mistakenly believe that increasing memory or timeout can eliminate the cold-start initialization delay.

Why the other options are wrong

Increasing the function timeout does not reduce cold-start latency; it only allows the function to run longer, but the initial cold-start delay remains.

Reserved concurrency limits the maximum concurrent executions for a function but does not pre-warm instances, so it does not reduce cold-start latency for the first request after scaling from zero.

Increasing memory size can reduce cold start duration but does not eliminate cold starts; the first request after scaling from zero still incurs cold start latency.

When would these options actually be correct?

In a scenario where a Lambda function consistently times out due to long processing times (e.g., processing large files) and the team needs to ensure completion without changing architecture, increasing the timeout would be correct.

A question where a function must not exceed a certain concurrency limit to avoid throttling downstream resources (e.g., a database with limited connections) would make reserved concurrency the correct answer.

A question where the goal is to reduce execution time of a Lambda function that is consistently hitting the maximum timeout, and the function is CPU-bound, so more memory (and thus more CPU) speeds up execution.

Why candidates pick the wrong answer

Candidates may think that giving the function more time compensates for the cold-start delay, misunderstanding that cold-start is about initialization time, not execution duration.

Candidates may confuse reserved concurrency with provisioned concurrency, thinking that reserving capacity eliminates cold starts, but reserved concurrency only caps concurrency, not pre-initializes environments.

Candidates may believe that more memory eliminates cold starts entirely, or they confuse memory allocation with keeping the function warm.

Full explanation →

196

Multi-Selecthard

A serverless checkout API runs on AWS Lambda behind API Gateway. Traffic spikes are predictable every weekday at 09:00 UTC, and p95 latency jumps for the first few minutes after each deployment because execution environments are cold. The team wants to reduce this startup impact without changing the API contract. Which changes should they make? Select three.

Select 3 answers

A.Configure provisioned concurrency on the production Lambda alias during the busy windows.

B.Initialize SDK clients and other reusable objects outside the handler so they are created once per execution environment.

C.Reduce the deployment package size and remove unnecessary layers to shorten function initialization.

D.Replace provisioned concurrency with reserved concurrency because reserved concurrency keeps instances warm.

E.Increase the function timeout so the first request has more time to warm up.

AnswersA, B, C

Correct. Provisioned concurrency keeps a pool of pre-initialized execution environments ready to handle invocations, which directly reduces cold-start latency. Using an alias allows the team to manage production traffic separately from development or canary versions and to schedule capacity for the predictable weekday peak.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, so when traffic spikes at 09:00 UTC, the Lambda function is already warm and can serve requests without cold start latency. This directly addresses the p95 latency jump after deployment without altering the API contract.

Exam trap

The trap here is confusing reserved concurrency (which only limits concurrency) with provisioned concurrency (which pre-warms instances), leading candidates to incorrectly select reserved concurrency as a solution for cold starts.

Full explanation →

197

MCQmedium

A website serves mostly cacheable images, CSS, and JavaScript from an ALB. Users in Europe and Asia report slower page loads, and the ALB receives far more requests than expected. The team also wants text assets compressed automatically. Which change is the best first step?

A.Increase the ALB size and add more target instances behind it.

B.Use Route 53 latency-based routing to send users to the nearest ALB.

C.Place Amazon CloudFront in front of the ALB and enable compression and caching.

D.Replace the ALB with an NLB to reduce latency for web requests.

AnswerC

CloudFront is the right choice because it caches static content at edge locations close to users, reducing latency and lowering the number of requests that reach the ALB. It also supports compression for text-based assets such as CSS, JavaScript, and HTML. This improves both performance and origin offload without changing the application logic.

Why this answer

CloudFront is the correct first step because it acts as a CDN that caches cacheable content (images, CSS, JS) at edge locations close to users in Europe and Asia, reducing load on the ALB and improving page load times. It also supports automatic compression of text assets (e.g., via gzip or Brotli) without requiring backend changes, directly addressing the team's requirement for compressed text assets. By offloading requests from the ALB, CloudFront reduces the number of requests hitting the origin, solving the 'far more requests than expected' issue.

Exam trap

The trap here is that candidates often think scaling the ALB (Option A) or using latency-based routing (Option B) will solve performance issues, but they overlook that caching and compression at the edge (CloudFront) directly address both latency and request volume without requiring backend changes.

Why the other options are wrong

The issue is not ALB capacity or backend scaling; it's about excessive requests and latency due to lack of caching and compression. Increasing ALB size and instances doesn't reduce request volume or compress assets.

Route 53 latency-based routing directs users to the nearest ALB, but the problem is that the ALB receives far more requests than expected due to cacheable content not being cached. Latency routing alone does not reduce ALB load or compress text assets automatically.

An NLB does not support caching, compression, or HTTP-level features like image/CSS/JS optimization; it operates at Layer 4 and cannot reduce request volume or compress text assets.

When would these options actually be correct?

When the website experiences high CPU/memory utilization on the ALB and backend instances, and the primary bottleneck is compute capacity rather than request volume or latency, scaling out the ALB and targets is appropriate.

In a scenario where you have multiple ALBs deployed in different AWS regions and users experience high latency because they are being routed to a distant region, Route 53 latency-based routing would be the correct answer to direct each user to the closest ALB, reducing latency.

If the question required handling millions of UDP or TCP connections with ultra-low latency and no need for HTTP features (e.g., a real-time gaming server or IoT device traffic), replacing an ALB with an NLB would be appropriate.

Why candidates pick the wrong answer

Candidates often default to scaling solutions when they see performance issues, without diagnosing the root cause (lack of caching/compression).

Candidates may think that reducing network latency by routing users to the nearest ALB will solve the slow page loads, but they overlook that the core issue is excessive requests hitting the ALB due to lack of caching and compression, which latency routing does not address.

Candidates may think NLB reduces latency because it is faster at the transport layer, but they overlook that the bottleneck here is cacheable content and compression, which require Layer 7 features.

Full explanation →

198

Multi-Selectmedium

A containerized service on Amazon ECS connects to a database with a password that must never be stored in plaintext or hardcoded in the image. The application reads the password at startup and occasionally reconnects later, so it needs to retrieve the current secret when needed. Which three actions should the architect take? Select three.

Select 3 answers

A.Store the database password in AWS Secrets Manager.

B.Have the application retrieve the secret from Secrets Manager at runtime when it needs the password.

C.Grant the ECS task role least-privilege permission to read only that secret.

D.Store the password in a plain environment variable and update it manually during maintenance windows.

E.Use an IAM user access key inside the container so the database password can be embedded in code.

AnswersA, B, C

Secrets Manager is designed for sensitive credentials and integrates with IAM and rotation features. It is a better fit than putting passwords in code, images, or plain variables.

Why this answer

AWS Secrets Manager is the correct service for storing sensitive data like database passwords because it provides encryption at rest (using AWS KMS) and automatic rotation capabilities. By storing the password in Secrets Manager, the architect ensures it is never exposed in plaintext or hardcoded in the container image, meeting the security requirement.

Exam trap

The trap here is that candidates might think environment variables or IAM access keys are acceptable for secrets, but the exam requires using a dedicated secrets management service like Secrets Manager to avoid plaintext exposure and enable rotation.

Why the other options are wrong

Storing the password in a plain environment variable violates the requirement that the password must never be stored in plaintext. Manual updates during maintenance windows are not secure and do not provide automated rotation or retrieval at runtime.

Using an IAM user access key inside the container violates the principle of not storing secrets in the image or code, and access keys are long-lived credentials that increase security risk. The correct approach is to use IAM roles for tasks to obtain temporary credentials.

When would these options actually be correct?

In a non-production environment with no security compliance requirements, where the password is static and the application reads it from an environment variable set at container launch, and manual updates are acceptable for testing purposes.

In a scenario where an application needs to authenticate to an external API that requires long-lived access keys and the application is running on an EC2 instance without IAM roles support, embedding an IAM user access key in a secure configuration file (not in code) might be acceptable if encrypted and rotated regularly.

Why candidates pick the wrong answer

Candidates may think environment variables are a simple and acceptable way to pass secrets, overlooking the explicit requirement to avoid plaintext storage and the need for runtime retrieval without hardcoding.

Candidates may think that IAM access keys are a standard way to grant programmatic access, and they might not fully understand that ECS tasks can assume IAM roles, eliminating the need to embed keys.

Full explanation →

199

MCQhard

Based on the exhibit, an application runs on Amazon Aurora MySQL. The writer instance is frequently near 85% CPU while the reader instance is under 20% CPU. Application traces show that most of the database traffic is read-only SELECT queries, but the code currently sends all queries to the writer endpoint. What should the solutions architect recommend to improve performance with the smallest functional change?

A.Increase the writer instance size and keep all traffic on the writer endpoint.

B.Point read-only database traffic to the Aurora reader endpoint and keep writes on the writer endpoint.

C.Convert the cluster to a Multi-AZ RDS PostgreSQL deployment to get automatic failover and better read performance.

D.Enable cross-Region read replicas so SELECT queries are routed to a remote Region for improved performance.

AnswerB

This directly uses the cluster’s read scale-out capability. The reader endpoint distributes read traffic across replicas, reducing load on the writer and increasing read throughput without changing schema or database engine.

Why this answer

The Aurora reader endpoint distributes read-only traffic across all available reader instances, offloading the writer instance and reducing its CPU utilization. Since the application traces show most traffic is read-only SELECT queries, this change requires only modifying the connection string for reads while keeping writes on the writer endpoint, making it the smallest functional change.

Exam trap

The trap here is that candidates may think increasing instance size (Option A) is the simplest fix, but they overlook the fact that Aurora's architecture is designed to offload reads to reader instances, which is a more cost-effective and scalable solution with minimal code change.

How to eliminate wrong answers

Option A is wrong because increasing the writer instance size does not address the root cause—the writer is overloaded with read traffic that could be handled by readers—and it incurs higher cost without leveraging Aurora's built-in read scaling. Option C is wrong because converting to RDS PostgreSQL Multi-AZ does not provide the same read scaling as Aurora readers; Multi-AZ only provides a standby for failover, not active read offloading, and it requires a full migration. Option D is wrong because cross-Region read replicas introduce significant latency for read queries and are intended for disaster recovery or global read scaling, not for reducing CPU on the local writer instance.

Full explanation →

200

Multi-Selecthard

A product catalog system uses a relational database for orders and a simple key-value profile store for shopping carts. Traffic is unpredictable, and the company wants to avoid paying for large idle database instances. Which two choices are best? Select two.

Select 2 answers

A.Use Aurora Serverless v2 for the relational order system.

B.Use DynamoDB on-demand capacity for the shopping-cart profile store.

C.Keep both workloads on large provisioned RDS instances and add read replicas for the cart store.

D.Use DynamoDB provisioned capacity with a fixed minimum despite the unpredictable traffic.

E.Replace the relational order system with a wide-column table to reduce SQL licensing.

AnswersA, B

Correct. Aurora Serverless v2 is designed for variable relational workloads because capacity can scale without constantly paying for a large fixed instance. It preserves SQL features while reducing idle overprovisioning.

Why this answer

Aurora Serverless v2 automatically scales compute capacity up and down based on demand, so you only pay for the resources you use. This eliminates the need to provision for peak traffic and avoids paying for large idle database instances, making it cost-optimized for unpredictable workloads.

Exam trap

The trap here is that candidates may think provisioned capacity with a minimum is acceptable for unpredictable traffic, but the question explicitly requires avoiding paying for idle capacity, so on-demand or serverless options are the only correct choices.

Full explanation →

201

MCQmedium

A DynamoDB-backed event processing system experiences throttling during a promotion. All events are written and read using the same partition key value (tenantId = "ACME"). The workload is time-ordered per tenant, and the application can tolerate slight reordering across partitions. Which design change will most directly increase throughput and reduce hot-partition throttling?

A.Increase the table's provisioned capacity (read/write units) to handle the promotion peak.

B.Change the partition key to include an additional sharding attribute derived from a hash of eventId.

C.Enable DAX caching for all reads but keep the same partition key and item layout.

D.Switch the table to eventually consistent reads for queries to lower read throttling.

AnswerB

When all traffic targets one partition key value, that partition becomes the bottleneck regardless of total table capacity. Adding a shard/salt attribute to the partition key (for example, tenantId + shardId where shardId = hash(eventId) mod N) spreads writes across multiple partition key values, increasing partition-level parallelism. Because the scenario allows slight reordering across partitions, losing strict single-partition time ordering is acceptable while improving throughput and reducing throttling.

Why this answer

Adding a sharding attribute derived from a hash of eventId allows writes and reads to be distributed across multiple partition keys, breaking the single hot partition caused by using tenantId='ACME' for all operations. DynamoDB's throughput is limited per partition, so distributing the load across many partitions directly reduces throttling without changing the application's tolerance for slight reordering.

Exam trap

The trap here is that candidates often assume increasing provisioned capacity (Option A) is the universal fix for throttling, but AWS specifically tests the understanding that DynamoDB's per-partition throughput limits require a sharding strategy to distribute load across partitions.

How to eliminate wrong answers

Option A is wrong because simply increasing provisioned capacity does not resolve the hot-partition issue; the single partition key (tenantId='ACME') still caps throughput at 3000 RCU/1000 WCU per partition, so throttling persists regardless of total table capacity. Option C is wrong because DAX caching only reduces read load on the table, but writes (which are the primary source of throttling during a promotion) still hit the same hot partition, and DAX does not help with write throttling. Option D is wrong because eventually consistent reads only reduce read costs and latency, but they do not address the root cause of throttling—the single partition bottleneck—and have no effect on write throttling.

Full explanation →

202

MCQmedium

A web application runs on an Amazon EC2 Auto Scaling group behind an Application Load Balancer (ALB). After each deployment, new instances take about 2 minutes to download artifacts and become ready to accept requests on the target port. In the last deployment, the ALB started marking targets unhealthy before the app was ready, and the Auto Scaling group then replaced those instances repeatedly, causing a prolonged outage. Which change best improves resilience during instance start-up without reducing actual availability once the application is healthy?

A.Increase the Auto Scaling group’s health check grace period so it exceeds the ~2-minute initialization time.

B.Add more subnets across additional Availability Zones to distribute the same instances more widely.

C.Switch the load balancer target type from instance targets to IP targets to avoid health check failures.

D.Reduce the ALB health check interval so unhealthy targets are removed faster.

AnswerA

A health check grace period prevents the Auto Scaling group from treating early health check failures as instance health problems. This avoids terminating instances before the application finishes initializing, which stops the restart/replace loop during deployments while still allowing normal health checks to apply once the app is ready.

Why this answer

The Auto Scaling group's health check grace period allows instances to initialize without being marked unhealthy by the ELB health checks. By setting this grace period to exceed the ~2-minute artifact download time, the ASG will not replace instances that are still starting up, preventing the cascade of terminations and redeployments that caused the outage. This directly addresses the root cause—premature health check failures—without changing the health check configuration or reducing availability once the app is ready.

Exam trap

The trap here is that candidates confuse the ALB health check interval or target type with the Auto Scaling group's lifecycle management, mistakenly thinking that changing how the ALB checks health (interval or target type) will fix the premature replacement, when the correct solution is to adjust the ASG's grace period to align with the application's startup time.

How to eliminate wrong answers

Option B is wrong because adding more subnets across additional Availability Zones distributes instances more widely for fault tolerance but does not prevent the ALB from marking starting instances as unhealthy, so it does not solve the premature replacement issue. Option C is wrong because switching from instance targets to IP targets changes how the ALB routes traffic but does not alter the health check logic or timing; the ALB will still mark the target as unhealthy if the health check fails during the initialization window. Option D is wrong because reducing the ALB health check interval causes unhealthy targets to be detected and removed faster, which would worsen the problem by accelerating the replacement cycle, not improving resilience during start-up.

Full explanation →

203

MCQmedium

An order processing workflow uses Amazon SQS as the decoupling layer between a producer and a consumer Lambda function. The consumer intermittently fails due to a downstream dependency. The team has observed that certain “poison” messages keep being retried repeatedly and prevent other messages from being processed efficiently. Which SQS configuration most directly addresses this issue?

A.Set the SQS queue’s retention period to 10 years and rely on application retries to eventually succeed.

B.Increase visibility timeout to a very large value and avoid dead-letter queues to keep ordering stable.

C.Configure a redrive policy with a dead-letter queue (DLQ) and set an appropriate visibility timeout greater than the maximum processing time.

D.Switch the queue to FIFO and remove retries in the Lambda event source mapping entirely.

AnswerC

A DLQ isolates poison messages after a receive count threshold, and correct visibility timeout prevents premature retries.

Why this answer

Configuring a redrive policy with a dead-letter queue (DLQ) allows messages that exceed a specified maximum receive count to be moved to the DLQ, isolating poison messages. Setting the visibility timeout greater than the maximum processing time ensures the consumer has enough time to process each message before it becomes visible again, preventing premature retries. This directly addresses the issue of poison messages blocking the queue and degrading throughput.

Exam trap

The trap here is that candidates often confuse increasing the visibility timeout or switching to FIFO as solutions for poison messages, but neither addresses the root cause of isolating messages that repeatedly fail processing.

How to eliminate wrong answers

Option A is wrong because increasing the retention period to 10 years does not prevent poison messages from being retried; it only keeps them in the queue longer, worsening the problem. Option B is wrong because increasing visibility timeout to a very large value without a DLQ means poison messages will still be retried indefinitely, and avoiding DLQs does not help with ordering or poison message handling. Option D is wrong because switching to a FIFO queue does not address poison messages; FIFO ensures strict ordering but still requires a DLQ for poison message handling, and removing retries entirely would cause message loss if processing fails.

Full explanation →

204

Multi-Selecthard

An application stores user-uploaded binaries in S3. Access is unpredictable for the first month, then most objects become cold. The team wants the cheapest approach that avoids manually guessing access patterns. Which two actions are best? Select two.

Select 2 answers

A.Enable S3 Intelligent-Tiering on the bucket.

B.Keep all objects in S3 Standard because lifecycle transitions add too much management.

C.Add a lifecycle rule to move very old objects to S3 Glacier Deep Archive when minute-level retrieval is no longer required.

D.Copy all binaries to Amazon EFS so retrieval is faster.

E.Disable versioning because S3 Intelligent-Tiering needs it to work.

AnswersA, C

Correct. Intelligent-Tiering is designed for objects with uncertain or changing access patterns. It automatically moves data between access tiers, reducing the need for manual guessing and avoiding overpaying for standard storage.

Why this answer

A is correct because S3 Intelligent-Tiering automatically moves objects between access tiers based on changing access patterns, eliminating the need to manually guess or configure lifecycle rules. It charges a small monthly monitoring fee per object but avoids the higher cost of keeping cold data in S3 Standard, making it the cheapest hands-off approach for unpredictable access followed by cold storage.

Exam trap

The trap here is assuming that lifecycle rules require manual guessing of access patterns, when S3 Intelligent-Tiering automates this without upfront configuration, and that versioning is a prerequisite for Intelligent-Tiering, which it is not.

Full explanation →

205

MCQmedium

A mobile game backend uses Amazon Aurora. The workload has many short-lived database connections from Lambda functions, causing connection storms. What should be added?

A.An internet gateway

B.S3 Select

C.RDS Proxy

D.A larger Route 53 hosted zone

AnswerC

RDS Proxy pools and manages database connections, improving scalability for serverless and bursty workloads.

Why this answer

RDS Proxy is the correct solution because it sits between Lambda functions and the Aurora database, pooling and reusing database connections. This prevents connection storms by reducing the overhead of establishing new connections for each short-lived Lambda invocation, and it also helps manage IAM authentication for Lambda functions without storing database credentials.

Exam trap

The trap here is that candidates may think scaling the database (e.g., increasing instance size) is the answer, but the question specifically targets connection management, not compute or storage capacity, and RDS Proxy is the AWS-managed service designed exactly for this use case.

How to eliminate wrong answers

Option A is wrong because an internet gateway is used to enable VPC-to-internet communication, not to manage database connection pooling or reduce connection storms. Option B is wrong because S3 Select is a service for retrieving subsets of data from objects in S3 using SQL-like expressions, and it has no role in database connection management. Option D is wrong because a larger Route 53 hosted zone increases the number of DNS records you can host but does not affect database connection handling or reduce connection storms.

Full explanation →

206

Multi-Selecthard

A private application in two private subnets must download objects from S3 and read parameters from Systems Manager Parameter Store without routing traffic through the public internet. Which two components should the architect use? The design must avoid adding custom operational scripts.

Select 2 answers

A.Interface VPC endpoint for Systems Manager

B.Internet gateway attached to the VPC

C.NAT gateway in each Availability Zone

D.Gateway VPC endpoint for Amazon S3

AnswersA, D

Systems Manager/Parameter Store access uses interface endpoints powered by AWS PrivateLink.

Why this answer

An Interface VPC endpoint for Systems Manager (SSM) allows private subnets to communicate with AWS Systems Manager Parameter Store over the AWS network using private IP addresses, without traversing the internet. This endpoint uses AWS PrivateLink, enabling secure and private access to SSM APIs, which is required for reading parameters from Parameter Store.

Exam trap

The trap here is that candidates often confuse Gateway VPC endpoints (used for S3 and DynamoDB) with Interface VPC endpoints (used for most other AWS services like Systems Manager), and may incorrectly assume a NAT gateway or internet gateway is needed for private subnet access to AWS services.

Full explanation →

207

MCQmedium

A media company runs a 24/7 recommendation engine on EC2 in one AWS Region. The workload is interruption-intolerant, and the team expects steady usage but may change instance families and sizes during planned optimizations. Compared to the current On-Demand setup, they want the lowest cost while avoiding the rigidity of locking to a specific instance type. What should the solutions architect recommend?

A.Switch the instances to Spot Instances and use interruption handling because it is the largest discount.

B.Purchase a Compute Savings Plan for the expected steady hourly usage in that Region.

C.Purchase a Standard Reserved Instance tied to a single specific instance type for the next 3 years.

D.Keep On-Demand and rely on Auto Scaling to reduce capacity when utilization is low.

AnswerB

Compute Savings Plans discount the usage while allowing flexibility across instance families and sizes in the Region.

Why this answer

A Compute Savings Plan offers the lowest cost for steady-state usage without locking to a specific instance type, providing up to 66% discount over On-Demand while allowing flexibility to change instance families, sizes, OS, or tenancy within a Region. This matches the requirement for cost savings with instance flexibility during planned optimizations.

Exam trap

The trap here is that candidates often confuse Reserved Instances with Savings Plans, assuming a Standard Reserved Instance is the only way to get significant discounts, but the question explicitly requires flexibility to change instance families, which a Compute Savings Plan provides while a Standard Reserved Instance does not.

How to eliminate wrong answers

Option A is wrong because Spot Instances can be interrupted with a 2-minute warning, making them unsuitable for an interruption-intolerant workload that runs 24/7. Option C is wrong because a Standard Reserved Instance locks to a specific instance type in a specific AZ, which contradicts the requirement to avoid rigidity and change instance families during optimizations. Option D is wrong because keeping On-Demand provides no cost savings, and Auto Scaling reduces capacity only when utilization is low, not addressing the need for lowest cost on steady usage.

Full explanation →

208

MCQmedium

A company hosts an application on EC2 instances in private subnets. The instances must (1) read objects from Amazon S3 and (2) retrieve secrets from AWS Secrets Manager. The team currently sends all outbound traffic through a NAT gateway to reach both services. They want to reduce monthly cost while keeping traffic private (no internet egress) and without changing application logic. Which change is the most cost-effective?

A.Create a Gateway VPC endpoint for S3 and an Interface VPC endpoint for Secrets Manager, and ensure the subnet route tables / endpoint routing directs those service calls to the endpoints instead of the NAT gateway.

B.Keep the NAT gateway, but add AWS WAF rules to block non-service outbound requests to reduce NAT usage.

C.Disable IPv4 on the VPC subnets and rely on IPv6-only egress to reduce NAT gateway costs.

D.Replace the NAT gateway with a VPC firewall appliance instance to proxy outbound calls and reduce NAT fees.

AnswerA

This is the most cost-effective change because it removes the need to traverse the NAT gateway for those AWS service calls. S3 uses a Gateway VPC endpoint (route-table-based) for traffic to the S3 prefix list, so requests to S3 stay on the AWS network. Secrets Manager uses an Interface VPC endpoint (ENIs with private DNS), so requests to Secrets Manager stay private within the VPC/VPC endpoint network path. Because the application still calls the same AWS APIs, there is no logic change, and NAT data-processing charges drop to near zero for S3/Secrets Manager traffic.

Why this answer

Gateway VPC Endpoints for S3 and Interface VPC Endpoints for Secrets Manager allow private connectivity to these AWS services without traversing the internet or a NAT gateway. This eliminates NAT gateway hourly charges and data processing fees, reducing costs while keeping traffic within the AWS network. The application logic remains unchanged as the endpoints are accessed via the same DNS names, with route tables directing traffic to the endpoints instead of the NAT gateway.

Exam trap

The trap here is that candidates may assume NAT gateways are the only way to provide private subnet internet access, overlooking that VPC endpoints can provide private, cost-effective connectivity to specific AWS services without internet egress.

How to eliminate wrong answers

Option B is wrong because AWS WAF is a web application firewall for HTTP/HTTPS traffic, not a mechanism to reduce NAT gateway costs; it does not eliminate the NAT gateway's hourly and per-GB data processing fees. Option C is wrong because disabling IPv4 and relying on IPv6-only egress would require the application to use IPv6 addresses, which changes the application logic and may not be supported by all services; additionally, NAT gateways are not used for IPv6 traffic (egress-only internet gateways are used), so this does not address the cost of the NAT gateway for IPv4 traffic. Option D is wrong because replacing the NAT gateway with a VPC firewall appliance instance still incurs instance costs and management overhead, and it does not eliminate the need for internet egress to reach S3 and Secrets Manager unless endpoints are used; it is not more cost-effective than using VPC endpoints.

Full explanation →

209

Multi-Selectmedium

A company stores customer invoices in an Amazon S3 bucket. The application must keep the bucket private, ACLs should not be used, and customers should receive temporary download links for individual invoices. Which three changes should the architect make? Select three.

Select 3 answers

A.Enable S3 Block Public Access on both the bucket and the AWS account.

B.Continue using object ACLs so each customer invoice can be made public briefly.

C.Configure Bucket owner enforced object ownership to disable ACLs.

D.Generate presigned URLs for customers to download specific invoices for a limited time.

E.Move the bucket to another AWS Region to isolate it from the internet.

AnswersA, C, D

Block Public Access prevents accidental public exposure through bucket policies, ACLs, and other public settings. It is a strong baseline control when the data must remain private.

Why this answer

Enabling S3 Block Public Access at both the bucket and account level ensures that no public access can be granted to the bucket or its objects, which aligns with the requirement to keep the bucket private. This setting overrides any other permissions that might inadvertently allow public access, providing a strong security baseline.

Exam trap

The trap here is that candidates might think moving the bucket to a different region or using ACLs can solve the temporary access requirement, but they overlook that S3 Block Public Access and presigned URLs are the correct mechanisms for private, time-limited access without ACLs.

Why the other options are wrong

The requirement explicitly states 'ACLs should not be used,' so continuing to use object ACLs violates that constraint. Additionally, making objects public briefly is insecure and does not provide temporary download links.

Moving the bucket to another AWS Region does not isolate it from the internet; S3 buckets are accessible over the internet regardless of region. The requirement is to keep the bucket private and provide temporary download links, which is unrelated to region placement.

When would these options actually be correct?

In a scenario where the company needs to grant temporary public access to individual objects without requiring authentication, and the use of ACLs is permitted, making objects public via ACLs could be a simple solution, though presigned URLs are generally preferred.

If the question required compliance with data residency laws (e.g., data must remain within a specific geographic boundary) or reducing latency for users in a particular region, moving the bucket to that region would be correct.

Why candidates pick the wrong answer

Candidates may think that making objects public via ACLs is a quick way to provide access, overlooking the explicit prohibition of ACLs and the security risks of public exposure.

Candidates may mistakenly think that changing the region can restrict internet access or enhance security, confusing geographic isolation with network access control.

Full explanation →

210

MCQmedium

A mobile banking backend stores audit logs in S3. The compliance team requires that logs cannot be overwritten or deleted for seven years. What should be configured? The design must avoid adding custom operational scripts.

A.S3 server access logging

B.S3 lifecycle expiration after seven years

C.S3 versioning only

D.S3 Object Lock in compliance mode with an appropriate retention period

AnswerD

Object Lock compliance mode enforces write-once-read-many retention that even privileged users cannot bypass during the retention period.

Why this answer

S3 Object Lock in compliance mode prevents any user, including the root user, from overwriting or deleting objects for the specified retention period. This meets the compliance requirement of immutable audit logs for seven years without custom scripts. Compliance mode enforces a legal hold that cannot be removed by any user, ensuring logs are write-once-read-many (WORM) protected.

Exam trap

The trap here is that candidates often choose versioning (option C) thinking it prevents deletion, but versioning alone does not block overwrites or permanent deletion of the current version without additional safeguards like MFA delete or Object Lock.

How to eliminate wrong answers

Option A is wrong because S3 server access logging only records requests made to the bucket; it does not prevent deletion or overwriting of existing logs. Option B is wrong because S3 lifecycle expiration deletes objects after a set period, which would violate the requirement to prevent deletion for seven years. Option C is wrong because S3 versioning alone preserves previous versions but does not prevent deletion of the current version or overwrites; it requires additional controls like MFA delete or Object Lock to enforce immutability.

Full explanation →

211

MCQhard

A warehouse integration service must use shared file storage across Linux EC2 instances in multiple Availability Zones. The storage must remain available during an AZ failure. Which service should be used? The design must avoid adding custom operational scripts.

A.Amazon EFS with mount targets in multiple Availability Zones

B.S3 mounted as a POSIX file system without a file gateway

C.Instance store volumes

D.An EBS volume attached to all instances

AnswerA

EFS is regional file storage and supports mount targets across AZs.

Why this answer

Amazon EFS provides a fully managed, POSIX-compliant NFSv4.1 shared file system that can be mounted concurrently across multiple Linux EC2 instances. By deploying mount targets in multiple Availability Zones, the file system remains accessible even if one AZ fails, satisfying the high-availability requirement without any custom scripts.

Exam trap

The trap here is that candidates may confuse EBS Multi-Attach (which has strict limitations and requires cluster-aware file systems) with a true shared file system, or assume that S3 with a FUSE mount is a viable POSIX alternative without considering the operational overhead and lack of native consistency.

How to eliminate wrong answers

Option B is wrong because mounting S3 as a POSIX file system (e.g., via s3fs-fuse) requires custom operational scripts and does not provide native POSIX semantics or strong consistency, making it unsuitable for shared file storage across AZs. Option C is wrong because instance store volumes are ephemeral, tied to a single EC2 instance, and cannot be shared across instances or survive AZ failures. Option D is wrong because a single EBS volume cannot be attached to multiple EC2 instances; it can only be attached to one instance at a time, and while Multi-Attach EBS exists, it is limited to specific instance types and does not provide a shared file system without additional cluster-aware software.

Full explanation →

212

MCQeasy

A new feature stores user events in DynamoDB. Each event must be fetched by user_id and sorted by event_time. The team expects many different users and wants to avoid a single hot partition. Which partition key design is best?

A.Use a constant partition key value (for example, partition_key='events') and store user_id as an attribute.

B.Use user_id as the partition key and event_time as the sort key.

C.Use event_time as the partition key and user_id as an attribute to query later.

D.Use a randomly generated UUID as the partition key and query by user_id using a full table scan.

AnswerB

Using user_id as the partition key spreads data across many partitions based on user distribution. event_time as the sort key supports efficient range queries and retrieving events in time order per user. This design matches the stated access pattern and reduces hot partition likelihood.

Why this answer

Using `user_id` as the partition key ensures each user's events are stored in a separate partition, distributing the workload evenly and avoiding hot partitions. Adding `event_time` as the sort key allows DynamoDB to efficiently retrieve events for a given user in sorted order using a Query operation, which is both fast and cost-effective.

Exam trap

The trap here is that candidates may choose a constant partition key (Option A) thinking it simplifies queries, but they overlook that DynamoDB's scalability depends on partition key cardinality, and a single partition key creates a bottleneck that defeats the purpose of a NoSQL database.

How to eliminate wrong answers

Option A is wrong because using a constant partition key value (e.g., `'events'`) forces all data into a single partition, creating a hot partition that throttles performance and defeats the purpose of DynamoDB's distributed architecture. Option C is wrong because using `event_time` as the partition key scatters events across partitions without grouping by user, so fetching all events for a specific user would require a costly full table scan or a Scan with a filter, which is inefficient and not sorted. Option D is wrong because a randomly generated UUID partition key distributes writes well but makes it impossible to query by `user_id` without a full table scan, as DynamoDB cannot query across partitions without knowing the exact partition key values.

Full explanation →

213

MCQeasy

A company runs the same public API in two regions (Region A and Region B), each fronted by an ALB. They want Route 53 to automatically route clients to the Region B API when Region A becomes unhealthy, with minimal configuration effort. Which Route 53 approach should they use?

A.Use a single Route 53 A record that points only to Region A’s ALB and manually update it after failures.

B.Use Route 53 latency-based routing with separate records for each region.

C.Use Route 53 failover routing with health checks for each region’s endpoint.

D.Use weighted routing and set the Region B weight to 0 to ensure it is only used when needed.

AnswerC

Failover routing works with health checks to move traffic from a primary endpoint to a secondary endpoint when the primary becomes unhealthy.

Why this answer

Route 53 failover routing with health checks is the correct choice because it automatically directs traffic to a secondary endpoint (Region B) when the primary endpoint (Region A) fails a health check. This provides active-passive failover with minimal configuration, as Route 53 monitors the health of each ALB and updates DNS responses accordingly without manual intervention.

Exam trap

The trap here is that candidates often confuse latency-based routing with failover capabilities, assuming latency routing will automatically avoid unhealthy endpoints, but it only optimizes for speed and requires health checks to be manually integrated via a separate routing policy.

How to eliminate wrong answers

Option A is wrong because manually updating a single A record after failure is not automated, contradicts the requirement for minimal configuration effort, and introduces significant downtime during the manual update window. Option B is wrong because latency-based routing routes clients based on lowest latency, not health; it does not automatically fail over to Region B when Region A is unhealthy—clients would still be directed to Region A if it has lower latency, even if it is down. Option D is wrong because setting Region B's weight to 0 would never route traffic to it, even if Region A fails; weighted routing does not support automatic failover based on health checks.

Full explanation →

214

MCQmedium

A company uses IAM permission boundaries to prevent developers from escalating privileges. The security team created a permission boundary that allows only read-only actions on most AWS services, but teams can still manage their own resources. A developer can create an IAM role with broad permissions, and the boundary does not appear to be restricting it. Which corrective action best aligns with how permission boundaries work?

A.Rely on an AWS-managed policy attached to the developer’s IAM user; permission boundaries only apply to users.

B.Ensure the role creation process sets the permission boundary on the new role, using the boundary’s ARN in the CreateRole call or role template.

C.Attach the permission boundary policy as an SCP in AWS Organizations so it automatically applies to all roles.

D.Grant the developer IAM permissions to add a “deny” statement to the boundary policy so the boundary blocks escalation.

AnswerB

Permission boundaries are evaluated based on the boundary attached to the principal/role being created or used. If a developer creates roles without specifying the boundary, the boundary won’t restrict the resulting permissions. Enforcing boundary attachment via role templates or required parameters ensures every created role is constrained.

Why this answer

Permission boundaries must be explicitly applied to a role during its creation (via the `CreateRole` API call or an infrastructure-as-code template). Without setting the boundary ARN, the role inherits no restriction, allowing the developer to create a role with broad permissions that bypasses the intended boundary. Option B correctly identifies that the role creation process must include the boundary ARN to enforce the limitation.

Exam trap

The trap here is that candidates assume permission boundaries are automatically inherited or enforced by default, when in fact they must be explicitly applied to each role during creation, and SCPs are often confused as a substitute for permission boundaries.

Why the other options are wrong

Permission boundaries apply to IAM roles and users, not just users. The developer can create a role without a boundary, so attaching a policy to the user does not restrict the role's permissions.

SCPs apply to all accounts in an AWS Organization but do not replace or enforce IAM permission boundaries on individual roles; permission boundaries must be explicitly set on each role during creation.

Permission boundaries cannot be modified by the user they restrict; only the boundary's creator (e.g., security team) can update it. Granting the developer permission to add a deny statement would violate the boundary's purpose and is not a valid corrective action.

When would these options actually be correct?

If the question asked how to restrict a developer's own permissions (not roles they create), attaching an AWS-managed policy to the user would be correct.

In a question where the goal is to enforce a maximum permission baseline across all accounts in an AWS Organization, and the requirement is to prevent any IAM entity from exceeding a defined set of actions, an SCP would be the correct answer.

In a scenario where a developer needs to implement additional restrictions on a role they manage, and the security team has delegated authority to modify a custom boundary policy for specific use cases, allowing the developer to add deny statements could be correct if explicitly authorized.

Why candidates pick the wrong answer

Candidates may think permission boundaries are only for users, or that a user's attached policy limits all actions they perform, including role creation.

Candidates may confuse SCPs with permission boundaries because both can restrict permissions, but they operate at different levels (account vs. entity) and have different enforcement mechanisms.

Candidates may think that adding a deny statement to the boundary policy would block privilege escalation, misunderstanding that permission boundaries are set by an admin and cannot be altered by the user they constrain.

Full explanation →

215

MCQhard

Based on the exhibit, the security team needs to detect and alert on both successful and failed attempts to change S3 bucket policies and KMS key policies across the organization. Which solution best meets that requirement?

A.Enable an organization trail for management events in all regions and create an EventBridge rule that matches PutBucketPolicy and PutKeyPolicy, then send alerts to SNS.

B.Enable AWS Config in all accounts and use only a periodic compliance evaluation to alert when bucket or key policies drift.

C.Use IAM Access Analyzer because it continuously blocks policy changes that would expose the resources publicly.

D.Turn on S3 server access logging and KMS key rotation, because both services will capture policy modifications automatically.

AnswerA

CloudTrail management events record API activity, including failed attempts, and an organization trail provides coverage across accounts and Regions. EventBridge can react to those API calls in near real time and route notifications to SNS. This is the clean detective-control pattern for policy-change auditing.

Why this answer

AWS CloudTrail management events capture all API calls that modify S3 bucket policies (PutBucketPolicy) and KMS key policies (PutKeyPolicy). By enabling an organization trail for all regions, you centralize these events across the entire AWS Organization. An Amazon EventBridge rule can then filter for these specific API calls and send alerts via Amazon SNS, meeting the requirement to detect both successful and failed attempts.

Exam trap

The trap here is that candidates often confuse AWS Config's compliance checks or IAM Access Analyzer's policy analysis with real-time API call monitoring, failing to realize that only CloudTrail management events capture every attempt (including failures) to change policies.

How to eliminate wrong answers

Option B is wrong because AWS Config periodic compliance evaluations only check resource compliance at scheduled intervals, not in real-time, and they do not directly capture or alert on every API call attempt (including failed ones) to change policies. Option C is wrong because IAM Access Analyzer is designed to analyze resource-based policies for unintended public or cross-account access, not to block or alert on all policy change attempts; it does not continuously block changes or capture failed attempts. Option D is wrong because S3 server access logging logs object-level access requests, not management API calls like PutBucketPolicy, and KMS key rotation does not capture policy modifications; neither service logs policy change attempts.

Full explanation →

216

MCQmedium

You have an S3 bucket that stores customer-specific private files. You want to serve these files through CloudFront, where clients must use signed cookies (or signed URLs) to access the content. In addition, you need to block common web exploits and rate-limit suspicious traffic at the edge. Which design best meets these requirements?

A.Keep the S3 bucket private, configure CloudFront with Origin Access Control so only CloudFront can access the origin, require signed cookies/URLs for viewers, and associate an AWS WAF web ACL with CloudFront for blocking and rate limiting.

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

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

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

AnswerA

This ensures S3 remains non-public while CloudFront becomes the only origin access path using Origin Access Control. Signed cookies/URLs enforce authenticated authorization at the edge for each request. Attaching AWS WAF adds request inspection and protections like rate limiting and exploit blocking.

Why this answer

It combines a private S3 bucket with Origin Access Control (OAC) to ensure only CloudFront can access the origin, enforces signed cookies/URLs for viewer authentication, and uses AWS WAF at the edge to block common web exploits and rate-limit suspicious traffic. This layered approach provides both authorization (via signed requests) and security filtering (via WAF) at the CloudFront edge, meeting all requirements.

Exam trap

The trap here is that candidates often think WAF can handle authorization (like validating signed URLs) or that leaving the S3 bucket public is acceptable if CloudFront is used, but WAF cannot verify cryptographic signatures and a public bucket allows direct access bypassing CloudFront's authentication.

How to eliminate wrong answers

Option B is wrong because enabling public read access on the S3 bucket bypasses the need for signed cookies/URLs, and WAF cannot validate signatures—WAF inspects HTTP headers, URI paths, and IP addresses, but does not have the capability to verify CloudFront signed URL or signed cookie cryptographic signatures. Option C is wrong because leaving the S3 bucket publicly accessible defeats the purpose of using signed URLs; CloudFront does not filter traffic based on signed URLs at the origin level, so a public bucket would allow direct access to objects without authentication. Option D is wrong because omitting signed cookies/URLs means there is no mechanism to restrict access to authorized viewers only; WAF rate limiting and exploit blocking do not provide authentication or authorization for private content.

Full explanation →

217

MCQhard

Based on the exhibit, which design change is the best way to reduce the observed read latency for this DynamoDB-backed service?

A.Add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it.

B.Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.

C.Create a global secondary index on tenantId to distribute the load across more partitions.

D.Move the dashboard data into S3 and use Lambda functions to read it on demand.

AnswerA

DAX is designed to accelerate repeated eventually consistent reads from DynamoDB by caching hot items in memory. The exhibit shows one tenant driving most of the reads and the same dashboard items being requested repeatedly within a short window, which is an excellent fit for DAX. It reduces latency and offloads the hot key without requiring a schema redesign.

Why this answer

Adding a DynamoDB Accelerator (DAX) cluster in front of the table reduces read latency by providing an in-memory cache for repeated read traffic. DAX delivers microsecond response times for eventually consistent reads, which directly addresses the observed latency issue without requiring application-level caching or table redesign.

Exam trap

The trap here is that candidates often assume increasing capacity limits (Option B) or adding indexes (Option C) will solve latency issues, but they fail to recognize that latency is a caching problem, not a throughput or partitioning problem, and that DAX is the AWS-native solution for DynamoDB read-heavy workloads with repeated access patterns.

Why the other options are wrong

Increasing on-demand table limits does not reduce read latency; it only prevents throttling. The observed latency is likely due to repeated reads of the same hot data, which DAX caching addresses directly.

A GSI on tenantId does not reduce read latency for repeated reads of the same data; it only helps with query flexibility. The observed latency is likely due to hot partitions or throttling, which DAX's caching directly addresses.

Moving dashboard data to S3 and using Lambda to read it on demand would likely increase read latency due to cold starts and S3's higher latency for small, frequent reads compared to DAX. It also adds complexity and cost without addressing the root cause of high read latency on DynamoDB.

When would these options actually be correct?

This option would be correct if the question described a scenario where the application is experiencing ProvisionedThroughputExceededException errors due to insufficient read capacity, and the workload is unpredictable, making on-demand capacity the appropriate solution.

If the question described a scenario where read traffic is evenly distributed across many distinct tenantId values and the goal is to improve query performance by avoiding full table scans, then adding a GSI on tenantId would be correct.

This option would be correct if the question involved large, infrequently accessed dashboard data (e.g., historical reports) where cost savings from S3's lower storage cost outweigh latency concerns, and the Lambda function can be optimized with provisioned concurrency to minimize cold starts.

Why candidates pick the wrong answer

Candidates may assume that increasing capacity limits will improve performance, confusing throughput with latency, or they may not understand that DynamoDB's on-demand scaling handles capacity but not caching or hot-key issues.

Candidates may think that distributing load across partitions via a GSI will reduce latency, but they overlook that GSIs don't cache data and that the bottleneck is likely from repeated reads of the same items, not partition distribution.

Candidates may think S3 is always faster or cheaper for any data, or they might overestimate Lambda's ability to reduce latency without considering cold starts and network overhead.

Full explanation →

218

MCQhard

Based on the exhibit, a public API is behind CloudFront and is experiencing bursts of requests from the same client IP, causing upstream saturation. The team wants AWS to automatically block that IP when the request rate becomes excessive while keeping enforcement as close to the client as possible. Which control should they add?

A.Add an AWS WAF rate-based rule to the CloudFront distribution and configure it to block the source IP after the threshold is exceeded.

B.Add a network ACL rule that denies the source IP after five requests are observed.

C.Enable AWS Shield Advanced and create a custom protection group for the single IP address.

D.Place the API behind a security group rule that allows only the current client IP range.

AnswerA

AWS WAF rate-based rules are purpose-built for this use case. They evaluate the HTTP request rate from a source IP over a sliding window and can automatically block, CAPTCHA, or count when the threshold is exceeded. Attaching the Web ACL to CloudFront enforces the control at the edge, so abusive requests are stopped before they reach the origin and consume upstream capacity.

Why this answer

AWS WAF rate-based rules are designed to automatically block IP addresses that exceed a specified request rate within a 5-minute evaluation window. By attaching this rule to a CloudFront distribution, enforcement occurs at the edge location closest to the client, preventing excessive requests from reaching the upstream API and mitigating saturation.

Exam trap

The trap here is confusing stateless network ACLs or static security groups with the automatic, rate-aware blocking capability of AWS WAF, leading candidates to choose a manual or non-scalable solution.

How to eliminate wrong answers

Option B is wrong because network ACLs are stateless and require manual intervention to add or remove rules; they cannot automatically block an IP after a threshold of requests is observed. Option C is wrong because AWS Shield Advanced provides DDoS protection and custom protection groups for resource-level mitigation, not automatic per-IP rate limiting based on request count. Option D is wrong because security group rules are stateful and cannot dynamically update to block a specific client IP based on request rate; they only allow or deny traffic based on static rules.

Full explanation →

219

MCQmedium

A company stores private customer documents in an S3 bucket. They want only CloudFront to be able to read objects from the bucket (no direct S3 URL access), even if the bucket name and object key are known. Which configuration best meets this requirement?

A.Attach an AWS WAF Web ACL to CloudFront and allow public reads on the S3 bucket so WAF can block direct object access.

B.Use CloudFront Origin Access Control (OAC) and update the bucket policy to allow s3:GetObject only when the principal is cloudfront.amazonaws.com and aws:SourceArn equals the CloudFront distribution ARN.

C.Create IAM users with s3:GetObject permissions and share the IAM credentials with customers so they can fetch objects directly from S3.

D.Enable S3 static website hosting on the bucket and use the S3 website endpoint as the CloudFront origin so access controls can be enforced at CloudFront.

AnswerB

With OAC, CloudFront signs requests to S3 using an AWS-managed identity (the cloudfront.amazonaws.com service principal). A bucket policy that allows s3:GetObject only when AWS:SourceArn matches your specific CloudFront distribution ARN ensures the bucket is not readable from S3 by other principals. Direct S3 requests from users do not present the required CloudFront context, so they are denied at S3 authorization time.

Why this answer

CloudFront Origin Access Control (OAC) allows you to restrict S3 bucket access exclusively to CloudFront. By configuring the bucket policy to allow s3:GetObject only when the principal is cloudfront.amazonaws.com and the aws:SourceArn matches the CloudFront distribution ARN, you ensure that direct S3 URL requests are denied, even if the bucket name and object key are known. This prevents any unauthorized direct access to the S3 bucket.

Exam trap

The trap here is that candidates often confuse CloudFront's ability to cache content with its ability to enforce access control, mistakenly thinking that enabling static website hosting or using WAF alone can prevent direct S3 access, when in fact only Origin Access Control (or OAI) with a properly scoped bucket policy can achieve this.

How to eliminate wrong answers

Option A is wrong because AWS WAF operates at the application layer (Layer 7) and cannot block direct S3 URL access; it only filters HTTP/HTTPS requests to CloudFront, and allowing public reads on the S3 bucket would still permit direct S3 access. Option C is wrong because sharing IAM credentials with customers violates security best practices, and it does not prevent direct S3 URL access if the credentials are used outside CloudFront. Option D is wrong because enabling S3 static website hosting does not restrict access to CloudFront; the S3 website endpoint is publicly accessible and does not enforce CloudFront-only access controls.

Full explanation →

220

MCQmedium

A media platform runs a CPU-heavy thumbnail generation workload on an EC2 Auto Scaling group using t3.large instances. During peak traffic, p95 processing time increases significantly even though average CPU remains around 40–50%. CloudWatch also shows CPU credit depletion behavior. Which change will most directly improve performance predictability for this workload?

A.Increase the t3.large maximum CPU credits and keep the Auto Scaling group using the same burstable instance type.

B.Change the Auto Scaling group instance type to a compute-optimized family (for example, c7i) to provide steady CPU performance.

C.Add a placement group to the existing t3.large instances so they are packed close together for lower latency between nodes.

D.Switch the workload to run on Lambda with the same logic so invocations automatically scale without instance selection changes.

AnswerB

Compute-optimized instances are designed for consistently high CPU performance and do not rely on a burst-credit model. Switching to a steady-performance family removes the credit-depletion/throttling pattern that is driving the p95 latency spikes under sustained load.

Why this answer

The t3.large instances rely on CPU credits for burst performance, and when credits are exhausted, CPU performance is throttled to the baseline (e.g., 30% for t3.large). This causes unpredictable processing times during peak traffic, even if average CPU is moderate. Switching to a compute-optimized family like c7i provides dedicated, consistent CPU performance without credit-based throttling, directly improving predictability for CPU-heavy thumbnail generation.

Exam trap

The trap here is that candidates assume 'CPU credit depletion' can be fixed by increasing credits or scaling out, but the real issue is that burstable instances are fundamentally unsuitable for sustained CPU-heavy workloads, and only switching to a non-burstable instance type (e.g., compute-optimized) guarantees predictable performance.

How to eliminate wrong answers

Option A is wrong because increasing maximum CPU credits (which is not a configurable parameter; t3 instances have a fixed credit earning/balance limit) would only delay throttling, not eliminate it, and the workload would still face unpredictable performance once credits are depleted. Option C is wrong because placement groups optimize network latency between instances (e.g., for tightly coupled workloads like HPC), but the issue here is CPU credit exhaustion, not network latency. Option D is wrong because Lambda has a 15-minute execution timeout and limited CPU allocation per invocation (proportional to memory), making it unsuitable for long-running, CPU-heavy thumbnail generation; it also introduces cold start latency and does not inherently solve the CPU credit problem.

Full explanation →

221

Multi-Selectmedium

A DevOps team is designing a high-performance CI/CD pipeline to build and test code changes. The pipeline needs to scale to handle hundreds of concurrent builds, with fast build times and minimal idle compute cost. The builds are containerized and require consistent, reproducible environments. Which three options should be used to meet these requirements? (Choose three.)

Select 3 answers

.Use AWS CodeBuild with a large number of concurrent build projects.

.Use self-managed Jenkins on EC2 Spot Instances to reduce costs.

.Use AWS CodePipeline to orchestrate the build, test, and deploy stages.

.Use AWS CodeBuild with pre-built Docker images cached in Amazon ECR.

.Use Amazon EC2 Auto Scaling with a custom AMI for build agents.

.Use Amazon S3 as a cache store for CodeBuild to speed up dependency download.

Why this answer

AWS CodePipeline is the correct orchestration service to define and manage the CI/CD pipeline stages (build, test, deploy) in a serverless, highly available manner. Pre-built Docker images cached in Amazon ECR ensure consistent, reproducible environments and drastically reduce build times by avoiding image rebuilds. Using Amazon S3 as a cache store for CodeBuild allows storing and retrieving dependency caches (e.g., Maven .m2, npm node_modules) across builds, minimizing download times and speeding up the pipeline.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing self-managed or auto-scaling options (like Jenkins or EC2 Auto Scaling) instead of recognizing that AWS managed services (CodePipeline, CodeBuild, ECR, S3) provide the required scalability, speed, and cost efficiency with far less operational overhead.

Full explanation →

222

MCQmedium

A SOC analyst needs an immutable, centralized audit record of configuration and API changes across multiple AWS accounts. Recently, an operator changed an IAM role trust policy, and investigators must determine exactly which principal made the change and which parameters were used. Your current setup sends application logs to CloudWatch Logs, but there is no organization-level API audit logging. Which approach best satisfies the requirement?

A.Enable an AWS Organizations CloudTrail organization trail that delivers management event logs (including IAM) to a centralized S3 bucket in a dedicated audit account, for all regions.

B.Use CloudWatch Logs metric filters on application logs to infer which principals changed trust policies.

C.Rely on GuardDuty alerts to provide the full request parameters for every IAM policy change.

D.Enable AWS Config only and store periodic snapshots without CloudTrail management events.

AnswerA

Enabling an AWS Organizations CloudTrail organization trail is the authoritative method for capturing all AWS API calls, including IAM policy changes, across all accounts within an organization. This trail delivers immutable management event logs to a centralized S3 bucket in a dedicated audit account, ensuring comprehensive, tamper-proof records for forensic analysis and compliance across all AWS regions. This provides the necessary "who, what, when, where" details for every API action.

Why this answer

An AWS Organizations CloudTrail organization trail captures management events (including IAM API calls like ChangeTrustPolicy) across all accounts and regions, storing immutable logs in a centralized S3 bucket in a dedicated audit account. This provides the exact principal ARN, source IP, and request parameters needed for forensic investigation, meeting the immutable and centralized audit requirement.

Exam trap

The trap here is that candidates may confuse AWS Config's configuration tracking with CloudTrail's API-level auditing, or assume GuardDuty provides detailed request parameters, but only CloudTrail management events capture the full principal identity and API call details required for forensic analysis.

How to eliminate wrong answers

Option B is wrong because CloudWatch Logs metric filters on application logs cannot capture the full API request parameters or the exact principal identity for IAM changes; they only analyze log text patterns and lack the granularity of CloudTrail management events. Option C is wrong because GuardDuty alerts are designed for threat detection (e.g., anomalous API behavior) and do not provide the complete request parameters or a centralized, immutable audit trail of every IAM policy change. Option D is wrong because AWS Config alone records resource configuration snapshots and changes but does not capture who made the change or the API request parameters; it requires CloudTrail to provide the identity and source of changes.

Full explanation →

223

MCQmedium

A fintech startup uses AWS to run a web API and a PostgreSQL database. They must meet an RPO of 15 minutes and an RTO of 2 hours for a Region-wide disaster. Budget allows running a small, always-on set of infrastructure in a secondary Region, but not full production capacity. The team wants a DR approach that is regularly testable without large manual effort. Which disaster recovery strategy is the best fit?

A.Pilot light: replicate databases and store backups, keep only minimal infrastructure in the secondary Region, and scale up fully during failover.

B.Warm standby: keep a scaled-down application environment and database replication active in the secondary Region, using automated failover controls.

C.Backup and restore only: rely on daily automated backups and restore into the secondary Region during an incident.

D.Multi-site active-active: run both Regions at full capacity and route live traffic to both simultaneously.

AnswerB

Warm standby aligns with moderate RTO requirements by having ready-to-run resources plus continuous replication to meet the RPO target during failover.

Why this answer

Warm standby (B) is the best fit because it maintains a scaled-down but fully functional application environment in the secondary Region with active database replication, meeting the RPO of 15 minutes (via synchronous or near-synchronous replication like PostgreSQL streaming replication) and RTO of 2 hours (via automated failover controls such as Route 53 health checks and AWS Lambda automation). This approach allows regular testing without large manual effort by simply promoting the standby environment, and the budget constraint is satisfied by running only minimal compute resources (e.g., smaller EC2 instances) in the secondary Region.

Exam trap

The trap here is that candidates often confuse pilot light with warm standby, assuming minimal infrastructure is sufficient for a 2-hour RTO, but pilot light requires provisioning and configuring application servers during failover, which typically takes longer than 2 hours, whereas warm standby already has the application running and only needs scaling.

Why the other options are wrong

Pilot light keeps minimal infrastructure in the secondary Region, which does not meet the RTO of 2 hours because scaling up from minimal to full capacity takes longer than 2 hours. The question requires a scaled-down but always-on environment to achieve the RTO.

The RPO of 15 minutes cannot be met with daily backups, as data loss could be up to 24 hours. Additionally, restoring from backups would likely exceed the 2-hour RTO due to manual restore and provisioning time.

Multi-site active-active requires both Regions to run at full production capacity simultaneously, which exceeds the budget constraint of running only a small, always-on infrastructure in the secondary Region.

When would these options actually be correct?

A scenario where the RTO is longer (e.g., 4-6 hours) and the budget is extremely limited, allowing only a small database replica and no pre-provisioned application servers. The team can accept manual scaling steps during failover.

A company with an RPO of 24 hours and an RTO of 12 hours, where cost is the primary constraint and the application is not critical, would find backup and restore appropriate. For example, a development environment that can tolerate longer recovery times.

A company requires zero RPO and near-zero RTO for a critical application, has sufficient budget to run full production capacity in two Regions, and needs to handle sudden traffic spikes by distributing load across both Regions.

Why candidates pick the wrong answer

Pilot light is a well-known AWS DR pattern that balances cost and recovery time, and candidates may overestimate how quickly they can scale up from minimal infrastructure, ignoring the strict 2-hour RTO constraint.

Candidates may think backup and restore is the simplest and cheapest option, overlooking the strict RPO and RTO requirements in the question. They might assume automated backups can be restored quickly without considering the manual effort and time involved.

Candidates may think active-active provides the best availability and failover speed, overlooking the cost implications and the specific budget limitation in the question.

Full explanation →

224

MCQeasy

Based on the exhibit, which EBS volume type should the team use to meet the performance need at lower cost than overprovisioning capacity?

A.Use gp3 and provision the needed IOPS independently of volume size.

B.Use sc1 because it is optimized for infrequent access and large objects.

C.Use st1 because it provides high throughput for streaming data.

D.Use standard magnetic storage because it is compatible with all EC2 instances.

AnswerA

gp3 is the best fit because it lets you provision IOPS and throughput separately from volume size. The exhibit shows the workload needs around 10,000 IOPS and experiences queue buildup on gp2. With gp3, the team can raise performance without unnecessarily increasing storage capacity, which is usually more cost-effective for this kind of database workload.

Why this answer

The gp3 volume type allows you to provision baseline performance of 3,000 IOPS and 125 MiB/s regardless of volume size, and you can independently increase IOPS up to 16,000 and throughput up to 1,000 MiB/s without needing to add more storage capacity. This decoupling of performance from size means you can meet the required IOPS at a lower cost compared to gp2, where performance scales with volume size and often forces overprovisioning of capacity to achieve the needed IOPS.

Exam trap

The trap here is that candidates assume all EBS volume types require overprovisioning capacity to achieve higher IOPS, overlooking gp3's ability to independently scale performance from storage size, which is a key differentiator tested on the SAA-C03 exam.

How to eliminate wrong answers

Option B is wrong because sc1 (Cold HDD) is designed for infrequently accessed, large sequential workloads with a maximum throughput of 250 MiB/s and very low IOPS (tens), making it unsuitable for workloads requiring consistent IOPS performance. Option C is wrong because st1 (Throughput Optimized HDD) is optimized for high-throughput, sequential streaming data (e.g., big data, log processing) and cannot provide the low-latency, random IOPS that gp3 delivers. Option D is wrong because standard magnetic storage (previous generation) offers very low IOPS (approximately 100 IOPS per volume) and is not cost-effective for any performance-sensitive workload, nor is it compatible with all modern EC2 instance types (e.g., Nitro-based instances do not support it).

Full explanation →

225

MCQmedium

An application runs on EC2 instances in private subnets behind an Application Load Balancer (ALB). Security groups allow inbound HTTPS (443) from the ALB’s security group to the instance security group, and outbound from instances is set to allow ephemeral ports. Despite this, clients see connection timeouts. After reviewing network ACLs, you find the NACL associated with the instance subnet has an inbound allow for destination port 443, but it does not have a corresponding outbound allow for ephemeral ports. What is the most likely reason the traffic fails, and what should be updated?

A.NACLs are stateless, so you must update the NACL to allow the return (outbound) ephemeral port range; security groups alone cannot override a blocked NACL.

B.NACLs are stateful and automatically track connections; the fix is to add a new inbound rule to the security group for client source ports.

C.The issue is caused by ALB health checks; configure a new target group health check on port 80 so traffic can be routed.

D.Because instances are in private subnets, add a NAT gateway so return traffic can reach the internet over dynamic routing.

AnswerA

Stateless NACLs require both inbound and outbound rules. Missing outbound for ephemeral ports will block return traffic even if SG rules are correct.

Why this answer

Network ACLs are stateless, meaning they do not automatically allow return traffic. Even though the security group allows inbound HTTPS from the ALB, the NACL blocks the return traffic because it lacks an outbound rule for ephemeral ports (typically 1024-65535). Since NACLs are evaluated before security groups, a missing outbound allow rule causes the response packets to be dropped, resulting in connection timeouts.

Exam trap

The trap here is that candidates assume security groups' stateful nature applies to NACLs, or they confuse the direction of the missing rule (inbound vs. outbound) and overlook the need for an outbound ephemeral port rule in the NACL.

How to eliminate wrong answers

Option B is wrong because NACLs are stateless, not stateful; they require explicit rules for both inbound and outbound traffic, and the fix involves the NACL, not the security group. Option C is wrong because the issue is not related to ALB health checks; health checks would cause target registration failures, not client connection timeouts, and the described symptom matches a missing NACL outbound rule. Option D is wrong because the instances are in private subnets behind an ALB, and return traffic to the ALB does not require a NAT gateway; the ALB handles routing within the VPC, and the problem is purely a NACL misconfiguration.

Full explanation →

SAA-C03 (SAA-C03) — Questions 151–225