SAA-C03 SAA-C03 Questions 226–300 | Page 4/5

226

MCQmedium

A CI pipeline in account A uploads build artifacts to an S3 bucket (arn:aws:s3:::build-artifacts-prod) under the prefix teamA/. The pipeline must not be able to list other prefixes, and it must only upload objects under teamA/. Which IAM policy design best enforces least privilege for this requirement?

A.Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/* and allow s3:ListBucket on arn:aws:s3:::build-artifacts-prod with no condition.

B.Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:ListBucket on arn:aws:s3:::build-artifacts-prod with a condition that requires s3:prefix equals 'teamA/'.

C.Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:GetBucketLocation on arn:aws:s3:::build-artifacts-prod/teamA/.

D.Allow s3:* on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:ListAllMyBuckets for easier auditing.

AnswerB

This scopes uploads to exactly the teamA/ object path by using the object ARN arn:aws:s3:::build-artifacts-prod/teamA/*. For listing, it targets the bucket ARN (arn:aws:s3:::build-artifacts-prod) and restricts listing results to only the requested prefix using the s3:prefix condition key.

Why this answer

It grants the minimal permissions required: s3:PutObject is scoped to the specific prefix teamA/*, preventing uploads to other prefixes, and s3:ListBucket is allowed only with a condition that restricts the s3:prefix to 'teamA/', ensuring the pipeline cannot list objects under other prefixes. This enforces least privilege by combining resource-level and condition-based access control.

Exam trap

The trap here is that candidates often assume that scoping the resource ARN to a prefix (e.g., arn:aws:s3:::bucket/prefix/*) alone is sufficient to restrict listing, but without a condition on s3:ListBucket, the ListBucket action still returns all objects in the bucket, bypassing the intended restriction.

How to eliminate wrong answers

Option A is wrong because it allows s3:PutObject on the entire bucket (arn:aws:s3:::build-artifacts-prod/*) without restricting the prefix, so the pipeline could upload to any prefix, violating the requirement to only upload under teamA/. Option C is wrong because it allows s3:GetBucketLocation on the prefix path, which is not a valid ARN for that action (GetBucketLocation operates on the bucket, not a prefix) and does not grant the necessary s3:ListBucket permission to list objects, so the pipeline cannot verify uploads or list objects under teamA/. Option D is wrong because it allows s3:* on the prefix, granting excessive permissions like s3:DeleteObject or s3:GetObject, and s3:ListAllMyBuckets is irrelevant for restricting access to a specific bucket and prefix, violating least privilege.

Full explanation →

227

MCQhard

A payments API uses Amazon SQS. Poison messages are repeatedly failing and blocking useful retries. What should the architect configure? The architecture review board prefers a managed AWS-native control.

A.A FIFO queue without a redrive policy

B.A dead-letter queue with an appropriate maxReceiveCount

C.A larger message retention period only

D.Short polling instead of long polling

AnswerB

A DLQ isolates messages that fail repeatedly so they can be investigated without disrupting normal processing.

Why this answer

A dead-letter queue (DLQ) with an appropriate maxReceiveCount is the correct AWS-native solution for handling poison messages. When a message is repeatedly received from an SQS queue but fails processing, it is considered a poison message. By configuring a DLQ and setting a maxReceiveCount (e.g., 3 or 5), the message is automatically moved to the DLQ after exceeding that threshold, preventing it from blocking further retries and allowing the main queue to process valid messages.

Exam trap

The trap here is that candidates may confuse poison message handling with ordering or polling optimizations, and incorrectly choose FIFO queues or short polling, not realizing that only a DLQ with a redrive policy isolates repeatedly failing messages.

How to eliminate wrong answers

Option A is wrong because a FIFO queue without a redrive policy does not automatically handle poison messages; it only ensures strict ordering and exactly-once processing, but failed messages remain in the queue and continue to block retries. Option C is wrong because increasing the message retention period only keeps messages longer in the queue, but does nothing to isolate or remove poison messages that are repeatedly failing. Option D is wrong because short polling (returning immediately even if no messages are available) versus long polling (waiting for messages) affects latency and cost, but does not address the poison message problem; poison messages are a content/processing issue, not a polling mechanism issue.

Full explanation →

228

MCQmedium

A log archive serves infrequently accessed user documents that must be available immediately when requested. Which S3 storage class is likely the best cost fit? The design must avoid adding custom operational scripts.

A.Instance store volumes

B.S3 Standard-IA or S3 One Zone-IA depending on resilience requirements

C.S3 Standard for all objects

D.S3 Glacier Deep Archive

AnswerB

Infrequent Access classes reduce storage cost while keeping millisecond retrieval.

Why this answer

S3 Standard-IA or S3 One Zone-IA is the best cost fit because the workload involves infrequently accessed documents that require immediate retrieval. These storage classes offer lower storage costs than S3 Standard while maintaining low-latency access (milliseconds), and they avoid custom operational scripts since retrieval is automatic via standard S3 GET requests. The choice between Standard-IA and One Zone-IA depends on whether the data requires multi-AZ resilience or can tolerate a single-AZ failure.

Exam trap

AWS often tests the misconception that 'infrequently accessed' automatically means Glacier or Deep Archive, but the key differentiator is the 'immediate availability' requirement, which eliminates any cold storage class with retrieval delays.

How to eliminate wrong answers

Option A is wrong because instance store volumes are ephemeral block storage attached to EC2 instances, not a durable S3 storage class, and they lose data on instance stop/termination, making them unsuitable for long-term log archives. Option C is wrong because S3 Standard is designed for frequently accessed data with higher storage costs, making it cost-inefficient for infrequently accessed documents, even though it provides immediate availability. Option D is wrong because S3 Glacier Deep Archive has retrieval times of 12-48 hours (not immediate), which violates the requirement for documents to be available immediately when requested.

Full explanation →

229

Multi-Selecthard

A startup has three sandbox accounts and one production account. The CTO wants lower cost and operational overhead while keeping central purchasing and spend visibility. Which two actions are best? Select two.

Select 2 answers

A.Enable consolidated billing under AWS Organizations so discounts and shared purchasing apply across accounts.

B.Move each sandbox to its own payer account to isolate spend from the rest.

C.Use managed services such as Amazon RDS or Amazon S3 instead of self-managed EC2-based databases and file servers where practical.

D.Buy Dedicated Hosts for sandbox workloads to get a lower blended rate.

E.Disable AWS Budgets because consolidated billing already solves visibility.

AnswersA, C

Correct. Consolidated billing centralizes purchasing and can improve discount usage across linked accounts. It also gives the company one payer view, which simplifies governance and visibility.

Why this answer

Enabling consolidated billing under AWS Organizations aggregates usage across all accounts, allowing the startup to benefit from volume discounts, Reserved Instance sharing, and Savings Plans across the sandbox and production accounts. This reduces operational overhead by centralizing payment and provides a single view of spend, meeting the CTO's requirements for cost and visibility.

Exam trap

The trap here is that candidates might think Dedicated Hosts (Option D) reduce costs for sandbox workloads, but they actually increase costs due to per-host billing and are intended for specific licensing scenarios, not general cost optimization.

Why the other options are wrong

Moving each sandbox to its own payer account increases operational overhead and reduces cost visibility, contradicting the goal of lowering cost and overhead while maintaining central purchasing and spend visibility.

Dedicated Hosts increase cost and operational overhead, contradicting the goal of lowering cost and overhead. They are not needed for sandbox workloads and do not provide a lower blended rate compared to Reserved Instances or Savings Plans under consolidated billing.

Disabling AWS Budgets removes spend visibility, which the CTO explicitly wants to maintain. Consolidated billing does not automatically provide visibility; budgets and alerts are still needed.

When would these options actually be correct?

If the CTO required strict cost isolation between accounts (e.g., for regulatory compliance or chargeback to different departments) and did not need central purchasing or consolidated discounts, then separate payer accounts would be appropriate.

A question requiring dedicated tenancy for licensing or compliance reasons (e.g., Microsoft SQL Server with per-core licensing) where Dedicated Hosts are necessary to meet license terms, and cost is less of a concern.

If the question stated that the CTO wants to reduce operational overhead and budgets are causing excessive alert noise with no value, and the company already has a separate cost monitoring tool that provides visibility, then disabling AWS Budgets could be correct.

Why candidates pick the wrong answer

Candidates may think separate payer accounts provide clearer cost isolation, but they overlook the increased management overhead and loss of volume discounts from consolidated billing.

Candidates may think Dedicated Hosts offer cost savings through licensing benefits or assume 'dedicated' implies better pricing, not realizing they are more expensive and only beneficial for specific licensing scenarios.

Candidates may incorrectly assume consolidated billing alone provides full visibility and that budgets are redundant, overlooking that budgets are a separate tool for proactive cost monitoring and alerts.

Full explanation →

230

MCQeasy

Based on the exhibit, what change best reduces Lambda cold-start impact for a predictable user-upload workflow?

A.Set a reserved concurrency limit for the function to protect it from throttling.

B.Enable provisioned concurrency for the function.

C.Increase the function timeout to give more time for initialization.

D.Move the function to a larger memory setting only to eliminate all initialization time.

AnswerB

Provisioned concurrency keeps a pre-initialized pool of Lambda execution environments ready to respond immediately. The exhibit shows long init duration after inactivity, which is the classic symptom of cold starts affecting user experience. Because the traffic pattern is predictable during launches, provisioned concurrency is the most direct way to reduce startup latency and smooth response times.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, so when a user upload triggers the Lambda function, there is no cold-start delay. This directly addresses the predictable, user-upload workflow by ensuring warm containers are ready to handle requests immediately.

Exam trap

The trap here is confusing reserved concurrency (which limits concurrency to prevent throttling) with provisioned concurrency (which pre-warms instances to eliminate cold starts), leading candidates to choose a throttling protection mechanism instead of a cold-start mitigation solution.

Why the other options are wrong

Reserved concurrency limits protect a function from throttling by other functions, but they do not reduce cold-start latency. Cold starts occur when a new execution environment is initialized, and reserved concurrency does not pre-warm instances.

Increasing memory reduces initialization time but does not eliminate it; cold starts still occur. The question asks to 'best reduce' cold-start impact, and provisioned concurrency (option B) keeps functions initialized and ready, which is more effective than merely speeding up initialization.

When would these options actually be correct?

A question where multiple functions share an account concurrency limit and a critical function must always have capacity available, even during traffic spikes from other functions. The correct answer would be to set a reserved concurrency to guarantee that function's execution slots.

Option D would be correct if the question asked: 'Which change minimizes function initialization time for a latency-sensitive workload?' In that context, larger memory allocations (up to 10,240 MB) proportionally increase CPU and reduce startup time, making it the best choice.

Why candidates pick the wrong answer

Candidates may confuse 'reserved concurrency' with 'provisioned concurrency' due to similar names, or think that reserving capacity inherently pre-warms environments, which it does not.

Candidates know that larger memory allocations reduce initialization time, so they mistakenly believe this eliminates cold starts entirely, overlooking that provisioned concurrency pre-warms instances to avoid cold starts altogether.

Full explanation →

231

MCQeasy

An ECS service runs on EC2 capacity. During peak traffic, tasks frequently wait for available container instances. The team wants faster scale-out for the underlying EC2 capacity when tasks increase. What is the best first architectural step?

A.Tune the container health check settings so tasks stop failing and stay running.

B.Use an ECS capacity provider (or Auto Scaling integration) to scale the EC2 instances based on ECS demand.

C.Pin all tasks to a single Availability Zone to reduce placement overhead.

D.Switch the tasks to run only on Fargate so EC2 scaling is no longer relevant.

AnswerB

When ECS tasks need compute, capacity must scale at the EC2 layer so there are enough container instances to place tasks. Integrating ECS with an Auto Scaling capacity provider allows the cluster to scale out in response to pending tasks. This reduces waiting time and improves responsiveness under load.

Why this answer

An ECS capacity provider (or Auto Scaling integration) directly links ECS task-level demand to EC2 instance scaling. When tasks are pending due to insufficient container instances, the capacity provider triggers a scale-out event on the Auto Scaling group, adding EC2 instances to accommodate the workload. This is the most direct and efficient architectural step to reduce the wait time for available container instances during peak traffic.

Exam trap

The trap here is that candidates may think tuning health checks (Option A) or switching to Fargate (Option D) are simpler fixes, but the question specifically asks for the best first architectural step to scale EC2 capacity faster, which is directly addressed by the capacity provider integration.

How to eliminate wrong answers

Option A is wrong because tuning health check settings does not address the root cause of insufficient EC2 capacity; it only affects task lifecycle management, not the number of available container instances. Option C is wrong because pinning tasks to a single Availability Zone increases risk of failure and does not solve the capacity shortage; placement overhead is negligible compared to the lack of instances. Option D is wrong because switching to Fargate is a migration, not an architectural step for the existing EC2-based service, and it does not address the immediate need for faster scale-out of the underlying EC2 capacity.

Full explanation →

232

MCQmedium

A startup runs an HTTP/2 API that also supports WebSocket connections. They need path-based routing to separate microservices (for example, /api/* to Service A and /metrics/* to Service B) and want TLS terminated at the load balancer. Which AWS option best meets these requirements while maintaining high request performance?

A.Use an Amazon NLB and configure target groups with HTTP health checks and listener rules for path-based routing.

B.Use an Amazon ALB with HTTP/2 support, WebSocket upgrades enabled, and listener rules for host/path-based routing.

C.Use Amazon API Gateway with a single backend integration and rely on the client to route requests to different microservices.

D.Use Amazon CloudFront without an ALB, and route requests to microservices using only custom origin headers.

AnswerB

An ALB supports Layer 7 features needed here: it can terminate TLS on an HTTPS listener, evaluate HTTP host/path routing rules, and it supports WebSocket by allowing HTTP Upgrade behavior through the ALB to the targets. ALBs also support HTTP/2 on HTTPS listeners, which helps maintain high request performance.

Why this answer

An Application Load Balancer (ALB) natively supports HTTP/2, WebSocket upgrades, and path-based routing via listener rules. It terminates TLS at the load balancer, offloading encryption from backend services, and maintains high performance for both HTTP/2 and WebSocket traffic. This makes ALB the correct choice for the startup's requirements.

Exam trap

The trap here is that candidates may confuse NLB's Layer 4 capabilities with ALB's Layer 7 features, incorrectly assuming NLB can handle path-based routing or WebSocket upgrades, when in fact it cannot inspect application-layer data.

Why the other options are wrong

NLB does not support path-based routing or HTTP/2; it operates at Layer 4 and cannot inspect HTTP paths or handle WebSocket upgrades natively.

API Gateway does not natively support WebSocket connections with path-based routing to separate microservices; it would require custom integration logic and cannot directly route to different services based on path patterns like /api/* and /metrics/*.

CloudFront does not natively support WebSocket connections or path-based routing to separate microservices based on URL paths like /api/* and /metrics/*; it is a CDN, not a load balancer with those routing capabilities.

When would these options actually be correct?

When the requirement is for ultra-high performance with static IP addresses, and routing is based on TCP/UDP traffic (e.g., port-based) without need for HTTP features like path-based routing or WebSocket support.

When the requirement is to expose a RESTful API with features like throttling, caching, and authentication, and the backend is a single service or can be handled via a single integration, with no need for WebSocket support or path-based routing to multiple microservices.

A question requiring global content delivery with low latency, DDoS protection, and caching for static or dynamic content, where the backend is a single origin (e.g., an ALB or S3) and WebSocket support is not needed.

Why candidates pick the wrong answer

Candidates may think NLB can handle HTTP/2 and path routing because it supports HTTP health checks, but NLB lacks Layer 7 capabilities needed for path-based routing and WebSocket upgrades.

Candidates may think API Gateway is a natural choice for API management and assume it can handle WebSocket and path-based routing, but they overlook its limitations with WebSocket and direct microservice routing without custom workarounds.

Candidates may think CloudFront can handle path-based routing via behaviors and assume it supports WebSocket, but WebSocket support in CloudFront is limited and not designed for microservice path-based routing with TLS termination at the edge.

Full explanation →

233

MCQmedium

A patient portal receives bursts of orders that sometimes overwhelm a downstream fulfilment service. The architecture must absorb spikes and retry processing without losing requests. Which service should be placed between the web tier and fulfilment workers? The design must avoid adding custom operational scripts.

A.AWS WAF

B.Amazon CloudFront

C.Amazon SQS queue

D.Amazon Route 53 weighted routing

AnswerC

SQS decouples producers and consumers, buffers bursts, and supports retries through visibility timeout and dead-letter queues.

Why this answer

Amazon SQS is the correct choice because it acts as a durable, fully managed message buffer that decouples the web tier from the fulfilment workers. When bursts of orders arrive, SQS queues the messages and allows workers to poll at their own pace, absorbing spikes without data loss. The built-in retry logic (visibility timeout and dead-letter queue) ensures failed processing attempts are automatically retried, and no custom operational scripts are needed.

Exam trap

The trap here is that candidates often confuse decoupling with caching or DNS-level distribution, picking CloudFront or Route 53 because they think 'absorbing spikes' means scaling web servers, but the question specifically requires buffering and retry without custom scripts, which only a queue service like SQS provides.

How to eliminate wrong answers

Option A is wrong because AWS WAF is a web application firewall that filters HTTP/S traffic based on rules (e.g., SQL injection, XSS); it does not buffer or retry messages between tiers. Option B is wrong because Amazon CloudFront is a content delivery network (CDN) that caches and accelerates static/dynamic content at edge locations; it cannot queue or retry asynchronous order processing. Option D is wrong because Amazon Route 53 weighted routing distributes DNS traffic across multiple endpoints based on weights; it provides load balancing at the DNS level but does not absorb spikes or provide retry mechanisms for message processing.

Full explanation →

234

MCQmedium

An Auto Scaling group for a background worker runs EC2 instances continuously. Over the last 30 days, CloudWatch shows sustained CPU utilization around 6% with no memory pressure, and queue processing latency meets all SLAs. The team wants to lower monthly cost with minimal risk. What is the best next action?

A.Increase the instance size to reduce CPU throttling risk

B.Perform right sizing by downsizing to a smaller instance family/size and validate SLAs

C.Switch the group to Spot Instances to reduce cost without changing instance sizing

D.Buy Reserved Instances with a long term commitment before making any sizing changes

AnswerB

Right sizing uses actual utilization to remove overprovisioning. With low CPU and no memory pressure and SLAs already met, downsizing (while validating under load and during a controlled rollout) is the safest way to reduce waste.

Why this answer

The current instance type is over-provisioned, as sustained CPU utilization is only 6% with no memory pressure and all SLAs are met. Right-sizing to a smaller instance family or size directly reduces compute cost while maintaining performance, making it the lowest-risk, cost-optimization action. This aligns with the AWS Well-Architected Framework's cost optimization pillar, which recommends matching instance capacity to actual workload requirements.

Exam trap

The trap here is that candidates may assume Spot Instances are always the cheapest option, but they ignore the risk of interruption for a continuously running workload where SLAs must be met, making right-sizing the safer and more appropriate first step.

How to eliminate wrong answers

Option A is wrong because increasing instance size would raise costs and is unnecessary given the low CPU utilization and no performance issues. Option C is wrong because switching to Spot Instances introduces the risk of interruption, which is not minimal risk for a continuously running background worker that must meet SLAs. Option D is wrong because buying Reserved Instances before right-sizing locks in a commitment for an over-provisioned instance type, increasing cost without addressing the root cause of waste.

Full explanation →

235

Multi-Selecthard

A regional web application for a content publishing system must fail over automatically to a secondary Region if the primary endpoint becomes unhealthy. Which two services or features are required? The design must avoid adding custom operational scripts.

Select 2 answers

A.AWS Organizations service control policies

B.Route 53 failover routing with health checks

C.S3 Transfer Acceleration

D.A deployed standby application stack in the secondary Region

AnswersB, D

Route 53 can monitor endpoint health and return the standby endpoint when the primary is unhealthy.

Why this answer

Route 53 failover routing with health checks is required because it automatically directs traffic away from an unhealthy primary endpoint to a secondary endpoint, enabling cross-region failover without custom scripts. A deployed standby application stack in the secondary Region is necessary to serve traffic when the primary fails, as Route 53 can only route to healthy endpoints that are actually running.

Exam trap

The trap here is that candidates often assume Route 53 alone is sufficient, forgetting that the secondary Region must have a fully deployed and running application stack to receive traffic after failover.

Full explanation →

236

MCQeasy

An internal team runs a report-generation job once per day. It typically finishes in a few minutes, and even on its slowest days it still completes in under 15 minutes. The team wants to reduce operational overhead and pay primarily for actual runtime instead of keeping servers running 24/7. Which AWS approach best matches these goals?

A.Deploy the job on EC2 instances and keep them running continuously for the daily schedule.

B.Use AWS Lambda triggered by a schedule (for example, EventBridge) to run the report at the required time.

C.Run the job in an RDS database using stored procedures scheduled by the database engine.

D.Use an Auto Scaling group with a fixed minimum size of one instance and disable scaling.

AnswerB

Lambda runs on demand and charges for execution time, aligning spend with actual job runtime and reducing ops.

Why this answer

AWS Lambda, triggered by Amazon EventBridge (CloudWatch Events), is ideal for short-lived, infrequent jobs like this daily report. It eliminates idle server costs by running only when invoked, and the 15-minute execution timeout comfortably covers the job's maximum runtime. This serverless approach directly reduces operational overhead and aligns with a pay-per-use cost model.

Exam trap

The trap here is that candidates may assume EC2 or Auto Scaling is needed for any scheduled job, overlooking that Lambda's 15-minute timeout and serverless pricing perfectly suit short, infrequent tasks, while the 'pay primarily for actual runtime' requirement explicitly points away from always-on compute.

Why the other options are wrong

Keeping EC2 instances running 24/7 incurs costs for idle time, contradicting the goal of paying primarily for actual runtime when the job completes in under 15 minutes daily.

Running the job as stored procedures in RDS would still require a running database instance 24/7, incurring costs for idle time, and does not align with the goal of paying primarily for actual runtime.

An Auto Scaling group with a fixed minimum size of one instance keeps an EC2 instance running 24/7, which incurs costs for idle time and does not reduce operational overhead or pay-per-use runtime.

When would these options actually be correct?

If the job required a persistent, stateful environment (e.g., large local storage, specific OS configurations) or needed to run multiple times per day with unpredictable latency demands, EC2 instances running continuously would be appropriate.

If the question required processing large datasets directly within a database (e.g., complex aggregations on terabytes of data) and the team already had a running RDS instance for other purposes, using stored procedures could be efficient without additional compute overhead.

A question where a workload requires a single EC2 instance to always be available (e.g., a legacy application that cannot be containerized or serverless) and must automatically recover from failure, with the goal of high availability rather than cost optimization.

Why candidates pick the wrong answer

Candidates may default to EC2 for any compute workload without considering serverless alternatives, overlooking the cost and operational overhead of idle instances.

Candidates might think that using RDS stored procedures eliminates the need for separate compute resources, overlooking that the database instance itself must remain running continuously, incurring costs regardless of job execution.

Candidates may think Auto Scaling automatically reduces costs, but a fixed minimum of one instance means the instance never scales in, so it runs continuously, failing to meet the 'pay primarily for actual runtime' requirement.

Full explanation →

237

MCQmedium

A media company stores original uploads in an S3 bucket. They must recover from accidental overwrites/deletes and also recover quickly from a full Region outage. The required RPO is about 1 hour. Which configuration best meets these requirements?

A.Enable an S3 lifecycle policy to transition objects to Glacier after 7 days without enabling versioning.

B.Enable S3 cross-Region replication (CRR) but leave the bucket without versioning enabled.

C.Enable S3 versioning and configure cross-Region replication to a bucket in another Region.

D.Rely on frequent EBS snapshots of a temporary cache used during uploads.

AnswerC

Versioning enables recovery from accidental overwrites/deletes, and CRR provides near-current copies for Region-level disaster recovery.

Why this answer

Enabling S3 versioning protects against accidental overwrites and deletes by preserving all object versions, while cross-Region replication (CRR) asynchronously replicates objects to a bucket in another Region, enabling recovery from a full Region outage. With an RPO of about 1 hour, CRR meets this requirement as replication typically completes within minutes to a few hours, and versioning ensures point-in-time recovery of previous object states.

Exam trap

The trap here is that candidates often assume CRR alone is sufficient for data protection, overlooking that without versioning, overwrites and deletes are permanent and cannot be recovered, which directly violates the requirement to recover from accidental overwrites/deletes.

How to eliminate wrong answers

Option A is wrong because a lifecycle policy to transition objects to Glacier after 7 days does not protect against accidental overwrites or deletes (no versioning), and Glacier retrieval times (minutes to hours) are too slow for a 1-hour RPO in a Region outage scenario. Option B is wrong because CRR without versioning cannot recover from accidental overwrites or deletes, as overwrites permanently replace the object and deletes remove it entirely, leaving no previous versions to restore. Option D is wrong because EBS snapshots of a temporary cache are not designed for S3 object recovery; they capture block-level changes of an EC2 instance volume, not the S3 bucket's object state, and do not provide cross-Region durability or protection against S3-specific overwrites/deletes.

Full explanation →

238

MCQeasy

A team runs a latency-sensitive service on EC2 and needs consistent, low-latency block storage for a database. The application requires predictable performance and should be fast for random reads/writes. Which EBS volume type is the best choice?

A.EBS st1 (throughput optimized HDD)

B.EBS gp3 (general purpose SSD)

C.EBS sc1 (cold HDD)

D.EBS magnetic (legacy magnetic)

AnswerB

gp3 is designed for a broad range of general-purpose workloads with solid low-latency performance. It supports random I/O patterns and offers predictable performance for many latency-sensitive applications. It is a common best-fit choice when you need balanced performance without specialized throughput-focused characteristics.

Why this answer

B is correct because gp3 is a general-purpose SSD that provides consistent, low-latency performance for random read/write operations, making it ideal for latency-sensitive databases. It offers a baseline of 3,000 IOPS and 125 MB/s throughput, with the ability to independently scale IOPS up to 16,000 and throughput up to 1,000 MB/s, ensuring predictable performance without the burst-bucket limitations of gp2.

Exam trap

The trap here is that candidates often confuse throughput-optimized HDDs (st1) with low-latency needs, mistakenly thinking 'throughput' implies fast performance, when in fact HDDs are unsuitable for random I/O and latency-sensitive workloads.

Why the other options are wrong

EBS st1 is a throughput-optimized HDD volume designed for large, sequential workloads, not for low-latency random reads/writes required by a database.

EBS sc1 (cold HDD) is designed for infrequently accessed, cold data with low throughput requirements, not for low-latency, high-performance random reads/writes needed by a database.

When would these options actually be correct?

For a big data processing application that performs large, sequential reads/writes (e.g., log processing, data warehousing) and requires high throughput at low cost, st1 would be the best choice.

A question asking for the most cost-effective EBS volume type for storing large amounts of infrequently accessed data, such as archival logs or backup files, where throughput is not a priority.

Why candidates pick the wrong answer

Candidates may confuse 'throughput optimized' with 'low latency' or assume HDD volumes are sufficient for database workloads without considering the need for consistent, low-latency random I/O.

Candidates may confuse 'cold' with 'low latency' or think that any HDD can handle database workloads, overlooking the specific performance characteristics of sc1.

Full explanation →

239

MCQmedium

An e-commerce application uses Aurora MySQL. Writes are modest, but the product-detail page generates many read-only queries and the writer instance CPU is high. The application can tolerate a small amount of replication lag on those reads. What should the team do?

A.Add Aurora read replicas and send read-only traffic to the reader endpoint.

B.Increase the writer instance size and keep all traffic on the primary.

C.Replace Aurora with DynamoDB to eliminate replication lag.

D.Enable Multi-AZ failover only, because it increases read throughput automatically.

AnswerA

Aurora read replicas are the right way to scale read-heavy workloads and reduce pressure on the writer instance. By directing read-only traffic to the reader endpoint, the application can offload product-page queries while keeping writes on the primary instance. Because a small amount of replication lag is acceptable, this approach aligns well with the workload's consistency and performance needs.

Why this answer

Adding Aurora read replicas and directing read-only traffic to the reader endpoint offloads SELECT queries from the writer instance, reducing its CPU load. Aurora replicas share the same underlying storage volume, so replication lag is minimal (typically <100ms) and acceptable for the product-detail page. This scales read throughput without increasing writer instance size or cost.

Exam trap

The trap here is confusing Multi-AZ (which only provides failover) with read replicas (which offload reads), leading candidates to pick Option D thinking it improves read performance.

Why the other options are wrong

Increasing the writer instance size does not offload read traffic from the primary node, so CPU remains high from read queries. The question explicitly allows replication lag, making read replicas a more cost-effective and scalable solution.

DynamoDB is a NoSQL database that does not support the same relational query patterns as Aurora MySQL, and the application would require significant refactoring. Additionally, DynamoDB does not inherently eliminate replication lag; it uses eventually consistent reads by default, which can have lag.

Multi-AZ failover provides high availability but does not increase read throughput; the standby replica cannot serve reads, so it does not offload the writer instance's CPU.

When would these options actually be correct?

If the application cannot tolerate any replication lag and all queries must be strongly consistent, or if the read workload is already low and the bottleneck is write performance, then increasing the writer instance size would be correct.

A question where the application requires a fully managed NoSQL database with single-digit millisecond latency at any scale, and the data model is key-value or document-based, with no need for complex joins or transactions. For example: 'A gaming leaderboard needs to store player scores and retrieve top players with low latency; the data is simple and does not require relational queries.'

A question where the primary concern is database availability during an AZ outage, and read scaling is not required. For example: 'An application needs automatic failover to a standby instance in another AZ with zero data loss. What should be enabled?'

Why candidates pick the wrong answer

Candidates may think that a larger instance handles more throughput overall, overlooking that read replicas can distribute read load without scaling the writer.

Candidates may think DynamoDB is always faster and has no replication lag, overlooking the fact that it uses eventually consistent reads and requires application changes to adapt to a different data model.

Candidates may confuse Multi-AZ with read replicas, thinking the standby can handle read traffic, or assume that failover automatically improves performance.

Full explanation →

240

MCQmedium

A company hosts a B2B file exchange site on EC2. Administrators must connect without opening SSH or RDP ports to the internet. What should the architect use? The design must avoid adding custom operational scripts.

A.A bastion host with SSH open to 0.0.0.0/0

B.AWS Systems Manager Session Manager with the required instance role

C.A public Elastic IP address on each instance

D.An internet gateway attached to the private subnet

AnswerB

Session Manager provides audited shell access without inbound SSH/RDP exposure.

Why this answer

AWS Systems Manager Session Manager allows administrators to establish secure shell access to EC2 instances without opening inbound SSH or RDP ports, using the Systems Manager agent and an IAM instance role. This meets the requirement for no internet-exposed ports and avoids custom operational scripts because Session Manager is a fully managed AWS service.

Exam trap

The trap here is that candidates often assume a bastion host is the only secure way to access private instances, but AWS Systems Manager Session Manager provides a fully managed, agent-based alternative that avoids opening any inbound ports and requires no custom scripts.

How to eliminate wrong answers

Option A is wrong because a bastion host with SSH open to 0.0.0.0/0 exposes a management port to the entire internet, violating the requirement to avoid opening SSH or RDP ports to the internet. Option C is wrong because assigning a public Elastic IP address to each instance directly exposes them to the internet, requiring open SSH or RDP ports for administrative access. Option D is wrong because an internet gateway attached to a private subnet does not provide administrative access; it only enables outbound internet connectivity for instances in that subnet, and administrators still need a way to connect without open ports.

Full explanation →

241

MCQmedium

A order processing API 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

S3 Object Lock in compliance mode provides robust Write Once, Read Many (WORM) protection, making objects immutable for a specified retention period. Once an object is locked in compliance mode, it cannot be overwritten or deleted by any user, including the root account, until the retention period expires. This ensures the highest level of data integrity and immutability, which is essential for audit logs subject to stringent regulatory compliance requirements.

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 a seven-year immutable audit log without custom scripts. Compliance mode enforces a legal hold that cannot be removed by any user, ensuring logs remain intact.

Exam trap

The trap here is that candidates often confuse versioning with immutability, thinking versioning alone prevents deletion, but it only preserves overwritten versions while still allowing the current version to be deleted unless combined with Object Lock or MFA Delete.

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 automatically deletes objects after a period, which directly violates the requirement that logs cannot be deleted for seven years. Option C is wrong because S3 versioning alone preserves previous versions of objects but does not prevent deletion of the current version or overwriting; it requires additional controls like MFA Delete or Object Lock to enforce immutability.

Full explanation →

242

MCQhard

A dev sandbox currently uses two NAT gateways in each of three Availability Zones, but only one private subnet per AZ needs outbound internet access. What should the architect review first? The design must avoid adding custom operational scripts.

A.Disabling route tables

B.Replacing every NAT gateway with an internet gateway attached to private subnets

C.Moving all workloads to public subnets

D.Whether one NAT gateway per AZ is sufficient for the required private subnets

AnswerD

NAT gateways are normally deployed per AZ for resilience; duplicate NAT gateways in the same AZ may be unnecessary.

Why this answer

The question asks what the architect should review first to optimize costs while maintaining functionality. Using two NAT gateways per AZ when only one private subnet per AZ needs outbound internet access is redundant; a single NAT gateway per AZ can handle the traffic for all private subnets in that AZ. The design must avoid custom operational scripts, so the simplest review is to check if one NAT gateway per AZ is sufficient, which would reduce costs without breaking connectivity.

Exam trap

The trap here is that candidates may assume more NAT gateways are always better for high availability, but the question asks for a cost-optimization review first, and the current setup is over-provisioned for the stated requirement.

How to eliminate wrong answers

Option A is wrong because disabling route tables would break all routing, not just optimize NAT gateway usage, and it would require custom scripts to restore functionality, violating the design constraint. Option B is wrong because internet gateways cannot be attached to private subnets; they are used for public subnets and would expose instances directly to the internet, breaking the private subnet isolation requirement. Option C is wrong because moving all workloads to public subnets would expose them to the internet, which is not suitable for a dev sandbox that likely requires private subnets for security, and it does not address the NAT gateway cost issue.

Full explanation →

243

Multi-Selectmedium

A startup runs two EC2-based workloads in the same AWS Region. Its customer-facing API is always on, and its nightly video transcoding fleet can restart jobs from checkpoints if an instance is interrupted. The finance team wants the lowest monthly compute cost without changing the application design. Which two actions should the team take? Select two.

Select 2 answers

A.Purchase an All Upfront Reserved Instance for the transcoding fleet only.

B.Buy a Compute Savings Plan to cover the always-on API baseline usage.

C.Run the transcoding fleet on Spot Instances because interrupted jobs can resume from checkpoints.

D.Increase the API instance size so CPU utilization stays below 30 percent.

E.Move the API tier to Dedicated Hosts to improve isolation and lower spend.

AnswersB, C

Savings Plans reduce cost for consistent compute usage and are well suited to the always-on API.

Why this answer

A Compute Savings Plan offers the lowest cost for steady-state workloads like the always-on API, providing up to 66% savings over On-Demand in exchange for a 1- or 3-year commitment. It applies to any EC2 instance family within a Region, making it flexible and cost-effective for the baseline usage. Option C is correct because Spot Instances can be up to 90% cheaper than On-Demand and are ideal for fault-tolerant workloads like the transcoding fleet, which can resume from checkpoints if interrupted.

Exam trap

The trap here is that candidates often assume Reserved Instances are always the cheapest option, but for interruptible workloads like transcoding, Spot Instances provide far greater savings, and a Savings Plan better covers the steady-state API usage without locking into a specific instance family.

Why the other options are wrong

The transcoding fleet can handle interruptions, so Spot Instances are cheaper than Reserved Instances. Purchasing All Upfront Reserved Instances for the transcoding fleet would lock in higher costs unnecessarily.

Increasing instance size to keep CPU below 30% wastes compute capacity and increases cost, contradicting the goal of lowest monthly compute cost. The question explicitly states not to change application design, and this action changes the instance type.

Dedicated Hosts increase cost due to per-host billing and do not lower spend; they are used for licensing or compliance, not cost savings. The question asks for lowest compute cost, so this option is counterproductive.

When would these options actually be correct?

If the question specified that both workloads must run continuously without interruption and the transcoding fleet cannot tolerate any interruptions, then purchasing All Upfront Reserved Instances for the transcoding fleet would provide the lowest cost for steady-state usage.

In a scenario where the application is latency-sensitive and requires consistent low CPU utilization to handle sudden spikes, and cost is not the primary concern, increasing instance size could be correct to ensure performance.

A question where the company has a per-socket or per-core software license (e.g., Windows Server, SQL Server) that requires dedicated physical servers to remain compliant. In that case, Dedicated Hosts can reduce licensing costs despite higher infrastructure spend.

Why candidates pick the wrong answer

Candidates may think Reserved Instances always provide the lowest cost, overlooking that Spot Instances are even cheaper for fault-tolerant workloads.

Candidates may think that larger instances are more cost-effective per unit of compute, or that keeping CPU low improves reliability, but this overlooks that the startup's goal is to minimize total cost, not optimize utilization.

Candidates may think 'dedicated' implies better performance or security at lower cost, but Dedicated Hosts are actually more expensive and are chosen for licensing or regulatory reasons, not cost optimization.

Full explanation →

244

MCQmedium

A read-heavy document portal repeatedly queries the same product catalogue data from DynamoDB with millisecond latency requirements. Which service can reduce read latency and table load? The team wants the control to be enforceable during normal operations.

A.Amazon Kinesis Data Firehose

B.S3 Transfer Acceleration

C.DynamoDB Accelerator (DAX)

D.AWS Glue Data Catalog

AnswerC

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 specifically designed for DynamoDB that can reduce read latency from single-digit milliseconds to microseconds, while offloading read traffic from the underlying table. This directly addresses the read-heavy workload and millisecond latency requirements, and the team can enforce its use during normal operations by configuring the application to route reads through the DAX cluster endpoint.

Exam trap

The trap here is that candidates may confuse DAX with ElastiCache (which is a general-purpose cache but not DynamoDB-native) or assume that S3 Transfer Acceleration can improve DynamoDB read performance, when in fact DAX is the only AWS service purpose-built to cache DynamoDB reads with sub-millisecond latency.

How to eliminate wrong answers

Option A is wrong because Amazon Kinesis Data Firehose is a streaming data ingestion service for loading data into data lakes and analytics tools, not a caching layer for DynamoDB reads. Option B is wrong because S3 Transfer Acceleration speeds up uploads to S3 over long distances using AWS edge locations, but it does not cache DynamoDB query results or reduce table load. Option D is wrong because AWS Glue Data Catalog is a metadata repository for ETL jobs and data lake schemas, not a read cache for DynamoDB.

Full explanation →

245

MCQeasy

An EC2 workload runs in one region on a single instance type. For the last month, CloudWatch metrics show average CPU utilization of 12% and no sustained memory pressure. The team wants to reduce cost while maintaining the current performance level. What is the best first step?

A.Use AWS Compute Optimizer to get recommendations for instance type and size changes.

B.Increase the instance size to reduce the risk of performance regression.

C.Switch to Spot Instances immediately to reduce cost regardless of utilization.

D.Disable detailed monitoring to lower CloudWatch charges.

AnswerA

AWS Compute Optimizer analyzes historical metrics (such as CPU and memory utilization) and recommends instance type and size changes to improve cost-effectiveness while targeting performance. Given sustained low CPU and no sustained memory pressure, this is the most direct first step to identify a smaller/fewer-overprovisioned instance configuration that can maintain performance.

Why this answer

AWS Compute Optimizer analyzes historical utilization metrics (CPU, memory, I/O) and provides actionable recommendations for right-sizing instances. Given the average CPU utilization of only 12% and no memory pressure, Compute Optimizer will likely recommend a smaller instance type or family that matches the workload's actual resource needs, reducing cost without affecting performance.

Exam trap

The trap here is that candidates may think increasing instance size (Option B) is a safe 'performance buffer' move, but the question explicitly asks to reduce cost while maintaining current performance, making right-sizing via Compute Optimizer the logical first step.

How to eliminate wrong answers

Option B is wrong because increasing instance size would raise costs unnecessarily when utilization is already low, and it does not address the goal of cost reduction. Option C is wrong because switching to Spot Instances without first analyzing workload suitability risks interruption and potential performance degradation; Spot Instances are not a guaranteed cost-reduction strategy for all workloads. Option D is wrong because disabling detailed monitoring (1-minute metrics) saves only a trivial amount and does not address the primary cost driver—compute instance charges—while losing granular visibility needed for right-sizing decisions.

Full explanation →

246

MCQeasy

A media company runs a batch job that processes image thumbnails. The job can be restarted from checkpoints and does not have user-facing SLAs. The batch capacity can tolerate interruptions. Which EC2 purchasing option is the best cost optimization choice?

A.Use On-Demand Instances because interruptions are not allowed for production workloads.

B.Use EC2 Spot Instances, accepting the possibility of interruptions and using checkpoints to resume.

C.Purchase Reserved Instances because they provide a discount regardless of the workload timing.

D.Buy Savings Plans because they guarantee capacity and remove the risk of interruptions entirely.

AnswerB

Spot Instances are typically the cheapest option for workloads that can tolerate interruptions with recovery.

Why this answer

Spot Instances offer significant cost savings (up to 90% compared to On-Demand) and are ideal for fault-tolerant, stateless, or checkpointable workloads like batch image thumbnail processing. Since the job can resume from checkpoints and tolerates interruptions, Spot Instances provide the best cost optimization without compromising functionality.

Exam trap

The trap here is that candidates may assume production workloads require On-Demand or Reserved Instances, but the question explicitly states the job has no user-facing SLAs and tolerates interruptions, making Spot Instances the correct cost-optimized choice despite the 'production' label.

How to eliminate wrong answers

Option A is wrong because On-Demand Instances are not cost-optimized for workloads that can tolerate interruptions; they are priced higher and provide no interruption risk, which is unnecessary here. Option C is wrong because Reserved Instances require a 1- or 3-year commitment and are designed for steady-state, predictable workloads, not for batch jobs that can be interrupted and resumed. Option D is wrong because Savings Plans offer discounted rates in exchange for a commitment to a consistent amount of compute usage (measured in $/hour), but they do not guarantee capacity or remove interruption risk; Spot Instances can still be interrupted under Savings Plans, and the question asks for the best cost optimization choice, not a capacity guarantee.

Full explanation →

247

Multi-Selectmedium

A workload runs in private subnets and must reach Amazon S3 and AWS Secrets Manager without using the internet or a NAT gateway. The team wants to keep the traffic on AWS private networking and avoid public IPs. Which two changes should the architect make? Select two.

Select 2 answers

A.Create an S3 gateway VPC endpoint and update the route tables for the private subnets.

B.Place a NAT gateway in the public subnet so the private instances can reach AWS services.

C.Create an interface VPC endpoint for AWS Secrets Manager and allow the workload security group to reach it.

D.Assign public IPv4 addresses to the instances and restrict them with security groups.

E.Use VPC peering to the AWS service endpoints instead of VPC endpoints.

AnswersA, C

An S3 gateway endpoint provides private access to S3 without sending traffic over the internet. It is the correct endpoint type for S3 and integrates through route tables.

Why this answer

An S3 gateway VPC endpoint enables private subnet instances to access S3 over the AWS network without requiring internet gateways or NAT gateways. Gateway endpoints use route table entries to direct S3 traffic through the AWS backbone, avoiding public IPs entirely.

Exam trap

The trap here is that candidates often confuse gateway endpoints (for S3 and DynamoDB) with interface endpoints (for most other services) and may incorrectly assume a NAT gateway is needed for all AWS service access, ignoring that gateway endpoints provide a free, internet-free alternative for S3.

Full explanation →

248

MCQmedium

Based on the exhibit, the application should continue serving requests if one Availability Zone fails. Which change best improves resilience with the least operational complexity?

A.Increase the desired capacity in AZ-a so more instances can absorb the failure of that same Availability Zone.

B.Add at least one subnet from a second Availability Zone to both the ALB and the Auto Scaling group.

C.Disable health checks so the ALB stops removing targets during brief infrastructure issues.

D.Move the application to a single larger instance type so the fleet has fewer moving parts.

AnswerB

A resilient design needs the load balancer and the Auto Scaling group to span multiple Availability Zones. If one AZ fails, the ALB can still route to healthy targets in the remaining AZs and the Auto Scaling group can replenish capacity there. This is the simplest and most common way to achieve AZ-level fault tolerance.

Why this answer

Adding subnets from a second Availability Zone to both the ALB and the Auto Scaling group distributes the application across multiple AZs. This ensures that if one AZ fails, the ALB can route traffic to healthy targets in the remaining AZ, and the Auto Scaling group can maintain capacity by launching instances in the surviving AZ. This approach directly addresses the requirement to continue serving requests during an AZ failure with minimal operational complexity.

Exam trap

The trap here is that candidates often think increasing capacity in a single AZ (Option A) provides resilience, but it actually concentrates risk in that AZ, while the correct answer requires distributing resources across multiple AZs to achieve true fault tolerance.

How to eliminate wrong answers

Option A is wrong because increasing the desired capacity in a single AZ does not provide resilience against the failure of that same AZ; all instances would be lost if the AZ fails. Option C is wrong because disabling health checks would prevent the ALB from detecting and removing unhealthy targets, causing traffic to be routed to failed instances and degrading application availability. Option D is wrong because moving to a single larger instance type creates a single point of failure; if that instance fails, the entire application becomes unavailable, and it does not address AZ-level failures.

Full explanation →

249

MCQeasy

A team runs an Amazon NLB in a VPC with targets registered in multiple Availability Zones (AZs). Their bill shows high inter-AZ data transfer charges. They want to reduce unnecessary cross-AZ traffic costs while still maintaining healthy targets per AZ. What change is most likely to reduce inter-AZ charges?

A.Disable cross-zone load balancing on the NLB so each client is routed to targets in the same AZ when possible.

B.Enable cross-zone load balancing so all targets receive traffic from every AZ.

C.Move the NLB to a different Region so traffic is always kept local.

D.Replace the NLB with a NAT gateway to reduce data charges between AZs.

AnswerA

Disabling cross-zone load balancing helps keep traffic within the same AZ, reducing inter-AZ data transfer charges.

Why this answer

Disabling cross-zone load balancing on an NLB ensures that each client is routed only to targets within the same Availability Zone as the NLB node that receives the traffic. This eliminates inter-AZ data transfer charges because traffic never leaves the AZ boundary. The NLB still maintains healthy targets per AZ by distributing traffic only among healthy targets within that AZ.

Exam trap

The trap here is that candidates often assume enabling cross-zone load balancing always reduces costs or improves performance, but for NLB it actually increases inter-AZ data transfer charges, and the question specifically asks for cost reduction, not high availability.

Why the other options are wrong

Enabling cross-zone load balancing would increase inter-AZ traffic because the NLB would distribute requests across all AZs, incurring higher data transfer charges, which is the opposite of the goal to reduce costs.

Moving the NLB to a different Region does not reduce inter-AZ data transfer charges; it would increase costs due to cross-Region traffic and latency, and does not address the issue of cross-AZ traffic within the original VPC.

A NAT Gateway is used for outbound internet traffic from private subnets, not for load balancing traffic between AZs. Replacing an NLB with a NAT Gateway would not reduce inter-AZ data charges and would break the load balancing functionality.

When would these options actually be correct?

In a scenario where you need to ensure even traffic distribution across all targets regardless of AZ, and cost is not a primary concern, enabling cross-zone load balancing would be correct. For example, if you have uneven target capacity across AZs and need to prevent overloading a single AZ.

In a scenario where the question asks how to reduce data transfer costs between two different AWS Regions, and the application can tolerate higher latency, moving the NLB to the same Region as the clients would eliminate cross-Region data transfer charges.

In a scenario where a team needs to provide outbound internet access to instances in private subnets and wants to reduce data transfer costs by ensuring traffic stays within a single AZ (e.g., by deploying a NAT Gateway per AZ), this option would be correct.

Why candidates pick the wrong answer

Candidates may confuse cross-zone load balancing with a feature that reduces costs, or they might think that distributing traffic more evenly always optimizes performance, overlooking the inter-AZ data transfer charges.

Candidates may think that moving to a different Region could localize traffic and reduce costs, misunderstanding that inter-AZ charges are within a Region, not between Regions.

Candidates may mistakenly think that a NAT Gateway can replace an NLB for internal traffic or that it inherently reduces cross-AZ costs, confusing its purpose of providing internet access with load balancing.

Full explanation →

250

MCQmedium

A test environment stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost? The design must avoid adding custom operational scripts.

A.Keep all logs in S3 Standard indefinitely

B.Move all logs immediately to S3 Glacier Deep Archive

C.S3 lifecycle policy that transitions objects to lower-cost storage classes over time

D.Use EBS snapshots for the logs

AnswerC

Lifecycle rules automate transitions based on age, matching storage cost to access patterns.

Why this answer

S3 lifecycle policies automate the transition of objects between storage classes based on age, allowing logs to move from S3 Standard (for frequent querying) to S3 Standard-IA or S3 One Zone-IA (for rare access), and eventually to S3 Glacier Deep Archive (for long-term compliance retention). This reduces storage cost without custom scripts, aligning with the requirement to avoid operational overhead.

Exam trap

The trap here is that candidates may choose Option B (immediate move to Glacier Deep Archive) thinking it minimizes cost, but they overlook the 30-day query requirement, which makes S3 Standard necessary for fast retrieval, and fail to recognize that lifecycle policies provide a graduated, automated approach.

How to eliminate wrong answers

Option A is wrong because keeping all logs in S3 Standard indefinitely incurs the highest storage cost, ignoring the cost savings from transitioning to lower-cost classes for rarely accessed and compliance-retained data. Option B is wrong because moving all logs immediately to S3 Glacier Deep Archive prevents the 30-day querying requirement, as retrieval times are hours and costs are high for frequent access, violating the design need for queryability. Option D is wrong because EBS snapshots are block-level backups for EC2 instances, not designed for log storage in S3, and would introduce unnecessary complexity and cost without addressing the tiered access pattern.

Full explanation →

251

MCQmedium

A web API runs on an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). During traffic spikes, users experience request timeouts even though CPU stays below 40%. After investigation, you find the ASG often has too few healthy targets to handle the current request rate. Which change will best improve responsiveness during spikes?

A.Keep the ASG scaling policy based on CPU utilization, but increase the ASG min capacity by 50%.

B.Create a target tracking scaling policy using an ALB metric such as RequestCountPerTarget or TargetResponseTime.

C.Enable EC2 detailed monitoring for one-minute granularity and keep CPU scaling.

D.Switch to scaling based on the ASG network out bytes metric only, ignoring ALB response metrics.

AnswerB

Target tracking with an ALB performance metric scales based on the same layer where the problem is observed (requests/latency through the ALB). As traffic spikes, RequestCountPerTarget and/or TargetResponseTime increase; the scaling policy then increases the ASG desired capacity so the ALB has more healthy targets to distribute requests to. That reduces queuing/latency and helps prevent timeouts without waiting for CPU to rise.

Why this answer

The issue is that the ASG has too few healthy targets to handle the request rate, even though CPU is low. A target tracking scaling policy based on RequestCountPerTarget or TargetResponseTime directly aligns scaling with the ALB's view of demand, ensuring the ASG adds instances when request rates spike, regardless of CPU utilization. This addresses the root cause—insufficient capacity to serve incoming requests—rather than relying on a metric (CPU) that does not reflect the bottleneck.

Exam trap

The trap here is that candidates assume CPU utilization is always the best scaling metric, but AWS explicitly tests that ALB-level metrics (RequestCountPerTarget, TargetResponseTime) are more appropriate when the bottleneck is request throughput rather than compute load.

How to eliminate wrong answers

Option A is wrong because increasing the ASG min capacity only raises the baseline number of instances, but does not make the scaling policy responsive to traffic spikes; the ASG will still scale based on CPU, which remains low, so it will not add instances during spikes. Option C is wrong because enabling detailed monitoring (1-minute granularity) improves the frequency of metric data but does not change the fact that CPU utilization is not the correct metric to trigger scaling for this request-rate bottleneck. Option D is wrong because switching to scaling based solely on ASG network out bytes ignores the ALB's request-level metrics, which are more directly correlated with the user-observed timeouts and healthy-target deficit.

Full explanation →

252

MCQmedium

A media company uploads raw video thumbnails to an S3 bucket every hour. The application needs these thumbnails for active browsing for the first 7 days. After day 7, access becomes rare. Requirements: - Objects must remain available in S3 for at least 180 days total. - After day 7, the team can tolerate retrieval latency in the range of minutes to hours. - They want to minimize storage cost while keeping the ability to read objects (no application changes required). Which storage strategy is the most cost-optimized fit?

A.Use a bucket-level lifecycle rule to transition objects to S3 Standard-IA on day 7 and then expire them after day 180.

B.Use a lifecycle rule to transition objects to S3 Glacier Flexible Retrieval after day 7 and expire them after day 180.

C.Keep all objects in S3 Standard for 180 days, and enable S3 Intelligent-Tiering only if the bucket’s access frequency is above a threshold.

D.Use a lifecycle rule to transition objects to S3 Glacier Instant Retrieval after day 7 and expire them after day 180.

AnswerB

Glacier Flexible Retrieval is designed for infrequent access and supports restore times compatible with minutes to hours. Transitioning after day 7 reduces storage cost for the long period where access is rare, while expiring at day 180 satisfies the 180-day retention requirement. The application can still use S3 GetObject; retrieval simply takes longer due to the archival tier.

Why this answer

S3 Glacier Flexible Retrieval provides retrieval times from minutes to hours, which matches the tolerance for rare access after day 7, and offers the lowest storage cost among the options for data that is rarely accessed. A lifecycle rule transitions objects from S3 Standard (used for the first 7 days of active browsing) to Glacier Flexible Retrieval on day 7, then expires them after day 180, meeting the 180-day retention requirement without application changes.

Exam trap

The trap here is that candidates often choose S3 Glacier Instant Retrieval (Option D) because of the word 'Instant,' overlooking that the requirement explicitly tolerates minutes-to-hours latency, making the cheaper Glacier Flexible Retrieval the better cost-optimized choice.

How to eliminate wrong answers

Option A is wrong because S3 Standard-IA is designed for infrequent access but still incurs higher storage costs than Glacier Flexible Retrieval for data that is accessed rarely (minutes-to-hours latency is acceptable), and it does not provide the lowest cost for this use case. Option C is wrong because keeping all objects in S3 Standard for 180 days is significantly more expensive than transitioning to a colder storage class, and S3 Intelligent-Tiering is not cost-optimized for a predictable access pattern (active for 7 days, then rarely accessed) as it adds monitoring costs and may not move objects to the cheapest tier quickly enough. Option D is wrong because S3 Glacier Instant Retrieval is designed for millisecond retrieval, which is unnecessary and more expensive than Glacier Flexible Retrieval when minutes-to-hours latency is acceptable, thus not the most cost-optimized choice.

Full explanation →

253

Multi-Selecthard

Multiple teams share one AWS Organization. Finance wants chargeback by project, alerts before overspend, and monthly views by account without manually opening each account. Which three actions best fit? Select three.

Select 3 answers

A.Enforce cost allocation tags on resources and activate them for billing reports.

B.Use AWS Budgets to create alerts and budget actions for each project.

C.Use Cost Explorer or Cost and Usage Reports to analyze spend by account, tag, and service.

D.Put every team in a separate AWS account and ignore tagging.

E.Use CloudTrail trails to estimate spend by resource because it records API calls.

AnswersA, B, C

Correct. Cost allocation tags are the foundation for project-level chargeback. Once activated for billing, they let finance group spend by business unit, application, or environment.

Why this answer

Cost allocation tags, when activated for billing reports, allow you to tag resources with project-specific metadata (e.g., 'Project:Alpha'). AWS then includes these tags in the Cost and Usage Reports (CUR) and Cost Explorer, enabling Finance to filter and allocate costs by project without manual account inspection. This directly supports chargeback by project and monthly views by account and tag.

Exam trap

The trap here is that candidates may confuse CloudTrail (which records API calls) with AWS Cost Explorer or CUR (which provide actual cost data), leading them to incorrectly select option E for cost estimation.

Why the other options are wrong

Putting teams in separate accounts without tagging prevents chargeback by project and requires manual account access for monthly views, failing to meet the requirements for cost allocation and automated reporting.

CloudTrail records API calls for auditing, not cost allocation. It does not provide cost or usage data by resource, tag, or project, so it cannot support chargeback, alerts, or monthly views by account.

When would these options actually be correct?

If the question asked for the best way to ensure security isolation and prevent resource sharing between teams, with cost tracking done via consolidated billing reports per account, then separate accounts without tagging would be correct.

If a question asked for a service to track API activity for security auditing or to identify which user created a resource, CloudTrail would be the correct answer. For example: 'Which service records API calls for operational and risk auditing?'

Why candidates pick the wrong answer

Candidates may think separate accounts inherently solve cost tracking, overlooking that chargeback by project still requires tags or other mechanisms to break down costs within an account.

Candidates may think CloudTrail can estimate costs because it logs resource creation events, but it lacks pricing data and cannot aggregate spend by tag or account.

Full explanation →

254

MCQmedium

A SaaS vendor needs temporary access to an S3 bucket in your AWS account to read customer exports. The vendor will assume an IAM role you created. During integration testing, the vendor reports that their AssumeRole requests succeed, but your security team is concerned about the possibility of confused-deputy attacks. Which trust policy approach most directly mitigates this risk?

A.Add an sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor.

B.Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.

C.Remove the role’s permissions policy and rely only on the S3 bucket policy to validate the caller.

D.Allow sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role.

AnswerA

The sts:ExternalId condition is a common protection against confused-deputy scenarios in cross-account role assumption. It ensures that only principals who know the unique external ID can successfully assume the role. This mitigates a third party tricking the vendor’s identity into assuming your role, even if they can call AssumeRole.

Why this answer

Adding an `sts:ExternalId` condition to the role trust policy forces the vendor to include a unique external ID in their `AssumeRole` API call. This prevents a confused-deputy attack by ensuring that the role can only be assumed when the caller presents the specific external ID you control, even if the vendor's account is compromised or used by a different AWS service.

Exam trap

The trap here is that candidates may think MFA (Option B) or bucket policies (Option C) are sufficient for cross-account access security, but they fail to address the specific confused-deputy vector that `sts:ExternalId` is designed to block.

How to eliminate wrong answers

Option B is wrong because requiring the vendor to use the same MFA device serial number as your internal administrators is impractical and insecure—it would require sharing a physical or virtual MFA device, which violates the principle of least privilege and does not prevent confused-deputy attacks. Option C is wrong because removing the role’s permissions policy and relying solely on the S3 bucket policy does not mitigate the confused-deputy risk; the trust policy still governs who can assume the role, and without an external ID condition, any principal in the vendor account could assume it. Option D is wrong because allowing `sts:AssumeRole` from the vendor account root principal without restricting to the vendor’s specific IAM role actually increases the attack surface—it permits any user or service in the vendor account to assume the role, making confused-deputy attacks easier, not harder.

Full explanation →

255

Multi-Selecthard

A retailer runs a reporting-heavy relational app on Amazon RDS MySQL. Peak dashboard traffic lasts only three hours each day, but the database is sized for the peak all day. The business wants lower cost without rewriting the application. Which three actions are best? Select three.

Select 3 answers

A.Right-size the writer based on actual utilization instead of peak guesses.

B.Add read replicas and direct dashboard traffic away from the writer.

C.Evaluate Aurora MySQL if the current replica-heavy design would be cheaper there.

D.Migrate to DynamoDB immediately because every relational workload is more expensive.

E.Increase provisioned IOPS permanently so the monthly bill drops.

AnswersA, B, C

Correct. Right-sizing removes waste from the always-on primary instance. If the writer is sized for real load rather than a worst-case assumption, the company pays for less unused compute.

Why this answer

Right-sizing the RDS instance based on actual utilization metrics (e.g., CPU, memory, connections) rather than peak guesses directly reduces compute and memory costs. Since the peak dashboard traffic lasts only three hours, the database can be scaled down for the remaining 21 hours, avoiding over-provisioning. This is a fundamental cost-optimization strategy for RDS without requiring application changes.

Exam trap

The trap here is that candidates assume DynamoDB is always cheaper for any workload, ignoring the need for application rewrites and the relational reporting requirements, while also overlooking that increasing IOPS always raises costs rather than lowering them.

Full explanation →

256

MCQhard

A Lambda-based travel booking site has unpredictable traffic spikes and users see latency caused by cold starts. The function must respond consistently during expected campaign windows. What should be configured?

A.Provisioned concurrency during campaign windows

B.A larger deployment package

C.CloudTrail data events

D.Reserved concurrency only

AnswerA

Provisioned concurrency keeps execution environments initialized and reduces cold-start latency.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, eliminating cold starts for those instances. During campaign windows, this ensures consistent sub‑millisecond latency because the function is always warm and ready to handle requests immediately.

Exam trap

The trap here is that candidates confuse reserved concurrency (a limit) with provisioned concurrency (a pre‑warming mechanism), assuming any concurrency setting solves cold starts, when only provisioned concurrency actively eliminates them.

How to eliminate wrong answers

Option B is wrong because a larger deployment package increases the time needed to download and initialize the code, making cold starts worse, not better. Option C is wrong because CloudTrail data events record API activity for auditing and do not affect Lambda execution latency or concurrency. Option D is wrong because reserved concurrency only caps the maximum number of concurrent executions for a function to prevent it from consuming all available concurrency in an account; it does not pre-warm instances or reduce cold starts.

Full explanation →

257

Matchingmedium

A team wants a web application to keep serving traffic if one Availability Zone fails. Match each architecture element to the resilience behavior it provides.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Stop sending requests to unhealthy targets and keep only healthy instances in rotation.

Launch replacement instances in healthy AZs when capacity is lost.

Maintain a synchronous standby in another AZ and fail over automatically.

Allow instances to be replaced without losing user sessions that are stored elsewhere.

Why these pairings

These pairs match architecture elements with their resilience behaviors for surviving an Availability Zone failure, focusing on AWS services that provide high availability and fault tolerance.

Full explanation →

258

MCQmedium

A site serves static assets (JS/CSS) through CloudFront from an S3 origin. After a recent frontend change, CloudFront shows a cache hit ratio below 20%. In CloudFront access logs, requests to the same asset URL path differ by a query parameter named rnd (a random value appended by the app on every request). The origin content is identical regardless of rnd. What is the best CloudFront configuration change to restore effective caching?

A.Increase the origin response Cache-Control max-age header on S3 so CloudFront caches longer even with different rnd values.

B.Create a custom CloudFront Cache Policy that does not include the rnd query parameter in the cache key (whitelist only required parameters, or forward no query strings).

C.Disable compression on CloudFront so the response body is identical byte-for-byte and cache hits improve.

D.Switch the origin from S3 to an ALB so CloudFront can cache based on ALB target health checks instead of the query string.

AnswerB

CloudFront caching effectiveness depends on the cache key. Since rnd does not change the content returned by the S3 origin, excluding rnd from the cache key allows many requests for the “same” asset to map to the same cached object. This removes cache fragmentation and restores a higher hit ratio without changing application content correctness.

Why this answer

The rnd query parameter makes each request appear unique to CloudFront, causing a cache miss for every request even though the underlying content is identical. By creating a custom cache policy that either forwards no query strings or whitelists only required parameters, CloudFront will ignore the rnd parameter when computing the cache key, allowing it to serve cached responses and dramatically improve the cache hit ratio.

Exam trap

The trap here is that candidates often think increasing cache duration (Option A) or disabling compression (Option C) will fix cache misses, when the real issue is that the query parameter is being included in the cache key, making every request unique.

How to eliminate wrong answers

Option A is wrong because increasing Cache-Control max-age only tells the browser and edge how long to cache the response, but it does not change the cache key; CloudFront still treats URLs with different rnd values as distinct objects, so each request will be a cache miss. Option C is wrong because disabling compression does not affect the cache key; CloudFront already caches compressed and uncompressed versions separately based on the Accept-Encoding header, and the issue here is the query string, not compression. Option D is wrong because switching to an ALB does not solve the query-string-based cache key problem; CloudFront would still see different rnd values as different cache keys, and ALBs are not designed to improve CloudFront caching behavior.

Full explanation →

259

Multi-Selectmedium

A line-of-business application runs on EC2 instances 24/7 with predictable usage for the next year. The application will stay in the same Region, and the team does not want to manage capacity interruptions. Which two purchase options can reduce cost compared with pure On-Demand pricing? Select two.

Select 2 answers

A.Buy Compute Savings Plans for the expected steady usage.

B.Purchase Standard Reserved Instances for the EC2 fleet.

C.Move the fleet to Spot Instances.

D.Use Dedicated Hosts to reserve physical servers for the application.

E.Stay entirely on On-Demand Instances because they are already the cheapest option.

AnswersA, B

Compute Savings Plans reduce the hourly cost of predictable usage while preserving flexibility across supported compute services. They are a strong fit when the workload is steady and the team wants savings without interruption risk.

Why this answer

Compute Savings Plans (A) offer a flexible discount (up to 66%) in exchange for a 1- or 3-year commitment to a consistent amount of compute usage (measured in $/hour), automatically applying to any EC2 instance family, region, or even AWS Fargate/Lambda. This reduces cost compared to On-Demand while avoiding capacity interruptions, as the commitment covers the predictable steady-state usage. Standard Reserved Instances (B) provide a similar discount (up to 72%) for a specific instance family in a specific region, also with a 1- or 3-year term, and guarantee capacity for the specified AZ if you choose a zonal reservation, ensuring no interruptions.

Exam trap

The trap here is that candidates may think Spot Instances are always cheaper and safe for steady workloads, but they forget the interruption risk, or they may confuse Dedicated Hosts with Reserved Instances as a cost-saving measure, when Dedicated Hosts actually increase cost for physical isolation.

Why the other options are wrong

Spot Instances can be interrupted with a 2-minute notice, which violates the requirement to 'not manage capacity interruptions' for a 24/7 predictable workload.

Dedicated Hosts provide physical servers dedicated for your use, but they are significantly more expensive than On-Demand instances and do not offer cost savings over Reserved Instances or Savings Plans for predictable workloads.

On-Demand Instances are the most expensive option; the question explicitly asks for purchase options that reduce cost compared to pure On-Demand pricing, so staying entirely on On-Demand does not reduce cost.

When would these options actually be correct?

A question where the application is fault-tolerant, stateless, or can handle interruptions gracefully (e.g., batch processing, big data, or containerized workloads) and cost reduction is the primary goal without strict uptime requirements.

A question requiring a license that is tied to a specific physical server (e.g., Windows Server with per-socket licensing, or Oracle Database with per-core licensing) and where you must ensure compliance by not sharing the server with other customers. In that scenario, Dedicated Hosts would be the correct choice despite higher cost.

If the question asked 'Which option provides the most flexibility with no upfront commitment and no capacity interruptions?' then staying on On-Demand would be correct because it offers maximum flexibility and no interruption risk.

Why candidates pick the wrong answer

Candidates know Spot Instances offer significant cost savings (up to 90% off On-Demand) and may overlook the interruption risk, especially if they focus only on cost reduction without reading the 'no capacity interruptions' constraint.

Candidates may think that reserving physical servers (Dedicated Hosts) is similar to Reserved Instances and would reduce costs, but Dedicated Hosts are actually a premium offering for licensing compliance, not a cost-saving measure.

Candidates may think On-Demand is already cost-effective or that other options introduce complexity, but they overlook that Reserved Instances or Savings Plans offer significant discounts for steady-state workloads.

Full explanation →

260

MCQmedium

A microservice runs in private subnets with no NAT gateway. It must retrieve a secret from AWS Secrets Manager. Security requires that traffic to Secrets Manager stays within AWS’s private network (no public internet egress). The IAM role already grants secretsmanager:GetSecretValue for the needed secret. What is the best network setup to meet the requirement?

A.Create an Interface VPC Endpoint for Secrets Manager (com.amazonaws.<region>.secretsmanager) and allow it via the endpoint security group; optionally enable private DNS.

B.Create an S3 Gateway VPC endpoint and use it for Secrets Manager requests because both services use HTTPS.

C.Assign a public IP address to the tasks so they can call Secrets Manager over the internet without NAT.

D.Change the route table to send all 0.0.0.0/0 traffic directly to an Internet Gateway.

AnswerA

Interface VPC Endpoints provide private IP connectivity from the VPC to the Secrets Manager service without routing through a NAT gateway or an Internet Gateway. The calls remain within AWS networking and still use standard TLS to the service endpoint.

Why this answer

An Interface VPC Endpoint (AWS PrivateLink) for Secrets Manager allows the microservice to access the secret privately without traversing the public internet. Since the subnet has no NAT Gateway and no public IP, this is the only way to keep traffic within the AWS network. Enabling private DNS ensures the standard Secrets Manager endpoint resolves to the private IP of the endpoint, eliminating the need for route table changes.

Exam trap

The trap here is that candidates often confuse Gateway Endpoints (which only work for S3 and DynamoDB) with Interface Endpoints (which are needed for Secrets Manager and most other AWS services), leading them to incorrectly select option B.

How to eliminate wrong answers

Option B is wrong because S3 Gateway VPC endpoints are specific to Amazon S3 and cannot be used for Secrets Manager requests; Secrets Manager requires an Interface endpoint (powered by PrivateLink), not a Gateway endpoint. Option C is wrong because assigning a public IP address would route traffic over the public internet, violating the requirement that traffic stays within AWS’s private network. Option D is wrong because sending all 0.0.0.0/0 traffic to an Internet Gateway would force traffic out to the public internet, which is not allowed, and the subnet has no NAT Gateway to enable return traffic.

Full explanation →

261

Multi-Selectmedium

A company is designing a high-performance web application that serves static and dynamic content to a global user base. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The static assets are stored in an S3 bucket. Which three architecture decisions will improve performance and reduce latency for users? (Choose three.)

Select 3 answers

.Place the EC2 instances in a single Availability Zone to reduce network latency.

.Use Amazon CloudFront to cache both static and dynamic content at edge locations.

.Integrate the ALB with AWS Global Accelerator to route traffic over the AWS global network.

.Use a larger EC2 instance type with higher network bandwidth, such as the c5n or m5n family.

.Enable S3 Transfer Acceleration on the bucket for faster downloads.

.Use an Amazon RDS Multi-AZ database for read replicas to offload read traffic.

Why this answer

Amazon CloudFront caches both static and dynamic content at edge locations, reducing latency by serving content from locations closer to users. AWS Global Accelerator improves performance by routing traffic over the AWS global network instead of the public internet, reducing jitter and latency. Larger EC2 instance types like c5n or m5n provide higher network bandwidth, which reduces network bottlenecks for high-traffic applications.

Exam trap

The trap here is that candidates may confuse S3 Transfer Acceleration as a solution for faster downloads, when it only accelerates uploads, or think Multi-AZ RDS provides read scaling, when it is for failover only.

Full explanation →

262

MCQmedium

A production log archive runs continuously on EC2 with predictable usage for the next three years. The team wants a discount while retaining some instance-family flexibility. What should they buy?

A.S3 Intelligent-Tiering

B.Dedicated Instances

C.Compute Savings Plan

D.Spot Instances only

AnswerC

Compute Savings Plans provide discounts for a committed spend while allowing flexibility across instance families, sizes, Regions, and compute services.

Why this answer

The Compute Savings Plan (C) is correct because it offers a discount (up to 66%) in exchange for a commitment to a consistent amount of compute usage (measured in $/hour) for a 1- or 3-year term, while allowing flexibility to change instance families, sizes, OS, tenancy, and even regions within EC2, Fargate, and Lambda. This matches the requirement of predictable usage for three years with instance-family flexibility, unlike Reserved Instances which lock to a specific instance family.

Exam trap

The trap here is that candidates often confuse Compute Savings Plans with Reserved Instances, assuming that any long-term discount requires locking into a specific instance family, but Compute Savings Plans provide both the discount and the flexibility to change instance families, which is the key differentiator tested in this question.

How to eliminate wrong answers

Option A is wrong because S3 Intelligent-Tiering is a storage class for objects in Amazon S3 that optimizes costs by moving data between access tiers based on changing access patterns; it has nothing to do with EC2 compute discounts or instance-family flexibility. Option B is wrong because Dedicated Instances are EC2 instances that run on hardware dedicated to a single customer, providing physical isolation but no discount or flexibility benefit; they are a billing/tenancy option, not a discount program. Option D is wrong because Spot Instances only offer significant discounts but are interruptible with a 2-minute termination notice, making them unsuitable for a production log archive that must run continuously for three years without interruption.

Full explanation →

263

MCQmedium

A media company runs a fleet of EC2 instances using Auto Scaling across multiple instance families (for example, m-series and c-series) in a single region. The business wants to commit to steady usage for one year to reduce cost, but the application team must retain flexibility to switch instance families and scale up/down as demand changes. They need the cost-reduction approach that best matches this flexibility. Which option is the best fit?

A.Purchase Standard Reserved Instances tied to a specific instance family and region, so the application can only run on the selected family.

B.Purchase Compute Savings Plans so the commitment applies regardless of instance family changes within the selected scope.

C.Purchase Spot Instances for all capacity and disable On-Demand fallback to guarantee the lowest cost.

D.Rely only on On-Demand and reduce cost by using a CloudFront-only approach for all dynamic content.

AnswerB

Compute Savings Plans provide discounted pricing in exchange for a 1-year or 3-year commitment, while allowing flexibility across instance families/attributes within the scope (for example, region/account and covered usage). This aligns with Auto Scaling that may shift between instance families while maintaining steady overall compute usage.

Why this answer

Compute Savings Plans provide the most flexibility because they apply to any EC2 instance family (including m-series and c-series) within a region, automatically adjusting to instance family changes and scaling. This matches the requirement to commit to steady usage for one year while retaining the ability to switch families and scale up/down, offering up to 66% savings over On-Demand without locking the application to a specific instance type.

Exam trap

The trap here is that candidates often confuse Reserved Instances (which lock to a specific family) with Savings Plans (which offer family flexibility), leading them to choose Option A despite the requirement for instance family switching.

How to eliminate wrong answers

Option A is wrong because Standard Reserved Instances are tied to a specific instance family (e.g., m5.large) and region, which would prevent the application from switching to a different instance family (e.g., c-series) without incurring additional On-Demand costs or modification fees. Option C is wrong because Spot Instances can be interrupted with a 2-minute warning, making them unsuitable as the sole capacity source for a production workload that requires reliability; disabling On-Demand fallback would risk application downtime during Spot reclaimations. Option D is wrong because CloudFront is a content delivery network that caches static and dynamic content at edge locations, but it does not reduce the cost of running EC2 instances for compute workloads; relying solely on On-Demand without a commitment discount would not achieve the desired cost reduction.

Full explanation →

264

Multi-Selectmedium

A company is designing a disaster recovery plan for a critical application hosted on AWS. The application runs on EC2 instances with data stored in Amazon EBS volumes and Amazon S3. The recovery time objective (RTO) is 15 minutes, and the recovery point objective (RPO) is 1 hour. Which three strategies would help meet these objectives? (Choose three.)

Select 3 answers

.Use AWS Backup to create hourly snapshots of EBS volumes and copy them to a different AWS Region.

.Pre-provision EC2 instances in the disaster recovery region and keep them running 24/7.

.Replicate critical data to S3 in the disaster recovery region using S3 Cross-Region Replication (CRR).

.Store Amazon Machine Images (AMIs) in the source region and use AWS Lambda to copy them after a disaster.

.Configure Amazon Route 53 with a failover routing policy and health checks to redirect traffic to the DR region.

.Set up an AWS Direct Connect link between the primary and DR regions for faster data transfer.

Why this answer

AWS Backup can create hourly snapshots of EBS volumes and copy them to a different AWS Region, meeting the 1-hour RPO by ensuring backups are taken every hour. S3 Cross-Region Replication (CRR) asynchronously replicates objects to a bucket in another region, keeping data synchronized within minutes and supporting the RPO. Amazon Route 53 with a failover routing policy and health checks can automatically redirect traffic to the DR region within seconds to minutes, enabling the 15-minute RTO by quickly failing over to pre-prepared infrastructure.

Exam trap

The trap here is that candidates may confuse operational readiness (like pre-provisioning instances) with a specific strategy that directly contributes to meeting RTO/RPO, or they may think Direct Connect is a disaster recovery strategy when it is merely a connectivity option that does not automate failover or data replication.

Full explanation →

265

MCQmedium

A Multi-AZ Amazon RDS database experiences incorrect writes at 10:15 UTC due to a buggy release. The team detects the problem at 10:25 UTC. They want to restore the data to a known-good point around 10:15 UTC, and validate the recovered data, without taking the current production instance offline during the recovery process. What is the most appropriate AWS action?

A.Immediately reboot the RDS instance and rely on the reboot to roll back the bad writes.

B.Perform a point-in-time restore (PITR) to a new DB instance using a restore time around 10:15 UTC, then test the restored instance before cutting over.

C.Create a new Read Replica from the current primary and use it as the recovered database after applying reverse migrations.

D.Temporarily disable Multi-AZ to speed up storage rollback, then re-enable Multi-AZ.

AnswerB

PITR restores to a specific timestamp using backups and transaction logs. Importantly, it creates a recovered copy (typically a new DB instance), which allows validation and cutover decisions without stopping or directly impacting the existing production instance.

Why this answer

Amazon RDS point-in-time recovery (PITR) allows you to restore a DB instance to any second within the backup retention period, creating a new, independent DB instance. This lets you validate the recovered data without affecting the current production instance, which remains online and serving traffic. The team can then cut over to the restored instance after confirming it is clean.

Exam trap

The trap here is that candidates may assume a reboot or Read Replica can undo bad writes, but neither provides a rollback mechanism; only PITR or a manual restore from a snapshot can recover to a specific point in time without affecting the live instance.

How to eliminate wrong answers

Option A is wrong because rebooting an RDS instance does not roll back writes; it only restarts the database engine and applies any pending maintenance or parameter changes, leaving the bad data intact. Option C is wrong because a Read Replica is an asynchronous copy of the primary that replicates all writes, including the buggy ones, so it cannot serve as a point-in-time recovery target without manual, error-prone reverse migrations. Option D is wrong because disabling Multi-AZ does not provide a storage rollback mechanism; it only removes the standby replica, and the primary's storage still contains the incorrect writes.

Full explanation →

266

Multi-Selecthard

An application uses Amazon Aurora MySQL. CloudWatch shows the writer instance near 85% CPU while the only reader instance averages 15% CPU. Trace logs show that all SELECT statements still target the writer endpoint. The workload is read-heavy, and the application already tolerates eventual consistency for reads. Which two changes will best increase total read throughput without a schema redesign? Select two.

Select 2 answers

A.Point read-only queries to the Aurora reader endpoint instead of the writer endpoint.

B.Add one or more additional Aurora Replicas and distribute read traffic across them.

C.Convert the cluster to a single-AZ RDS MySQL instance to reduce replication overhead.

D.Replace the writer endpoint with the instance endpoint of the primary node to speed up SELECT queries.

E.Add Amazon ElastiCache and move all database writes into the cache layer.

AnswersA, B

The reader endpoint is intended for read-only traffic and automatically distributes connections across Aurora Replicas. Redirecting SELECT statements away from the writer immediately reduces CPU pressure on the writer and uses the unused read capacity already available in the cluster. This is the fastest, lowest-risk way to improve read throughput without changing the schema or the application data model.

Why this answer

The Aurora reader endpoint is designed to distribute read-only connections across all available Aurora Replicas, offloading SELECT queries from the writer instance. Currently, all SELECT statements target the writer endpoint, causing the writer's CPU to be at 85% while the reader instance is underutilized at 15%. By redirecting read traffic to the reader endpoint, the writer's CPU load decreases, and the existing reader instance can handle more read throughput without any schema changes.

Exam trap

The trap here is that candidates may think adding more reader instances alone solves the problem, but they must first redirect read traffic away from the writer endpoint—otherwise, the new replicas remain idle and the writer remains overloaded.

Full explanation →

267

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? The design must avoid adding custom operational scripts.

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 choice because it pools and shares database connections, reducing the overhead of establishing new connections for each Lambda invocation. This prevents connection storms by maintaining a persistent pool of connections to Aurora, which is ideal for short-lived, high-frequency connections from serverless functions like Lambda.

Exam trap

The trap here is that candidates might think adding more network resources (like an internet gateway or larger DNS zone) solves connection storms, when the real issue is connection management at the database layer, not network capacity.

How to eliminate wrong answers

Option A is wrong because an internet gateway provides internet access to a VPC and does not manage database connections or connection pooling. Option B is wrong because S3 Select is used to retrieve subsets of data from objects in S3 using SQL expressions, not for managing database connections. 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 management or pooling.

Full explanation →

268

MCQmedium

A security analyst needs to let an external vendor (AWS account 555566667777) read data from a set of internal resources in your AWS account. You created an IAM role called VendorReadRole with a policy that allows the required API calls. However, when the vendor tries to access, CloudTrail shows the call fails at AssumeRole with: "Not authorized to perform: sts:AssumeRole". What is the most appropriate fix?

A.Add an allow statement for the vendor in the role’s trust policy to permit sts:AssumeRole from the vendor account (and include any required ExternalId condition).

B.Attach the same allow policy to the vendor account’s existing IAM user so the user can call sts:AssumeRole directly into your role.

C.Replace the AssumeRole call with GetCallerIdentity so the vendor can infer permissions without assuming the role.

D.Enable MFA on the vendor’s IAM user and require MFA for your role using condition keys in the permissions policy.

AnswerA

AssumeRole is blocked unless the role trust policy allows the vendor principal. The role’s permissions policy alone cannot permit assumption.

Why this answer

The error 'Not authorized to perform: sts:AssumeRole' indicates that the role's trust policy does not grant the external AWS account (555566667777) permission to assume the role. The trust policy must include an Allow statement with the sts:AssumeRole action, specifying the external account as the principal, and optionally an ExternalId condition to prevent the confused deputy problem. This is the required configuration for cross-account IAM role access.

Exam trap

The trap here is that candidates often confuse the role's permissions policy (which defines what the role can do after being assumed) with the trust policy (which defines who can assume the role), and mistakenly think attaching permissions to the external user or modifying the permissions policy will fix the AssumeRole authorization failure.

How to eliminate wrong answers

Option B is wrong because attaching the allow policy to the vendor account's IAM user does not grant the user permission to assume the role; the trust policy on the role must explicitly allow the external account (or its users/roles) to call sts:AssumeRole. Option C is wrong because GetCallerIdentity returns information about the caller's identity and does not grant or infer permissions to access resources in another account; it cannot replace the need for role assumption. Option D is wrong because enabling MFA on the vendor's IAM user and requiring MFA in the role's permissions policy does not address the missing trust policy authorization; the trust policy must first allow the sts:AssumeRole call, and MFA conditions are optional enhancements, not a fix for a missing trust relationship.

Full explanation →

269

MCQmedium

A marketing team uses CloudFront with an S3 origin to serve a single-page web app. After a release, CloudFront cache hit ratio dropped sharply. The app requests the same static JS and CSS assets, but each request includes a unique tracking query parameter (for example, ?utm_source=campaign123, campaign456, etc.). You want CloudFront to cache those assets efficiently even when the tracking query parameter changes. What should you do?

A.Create a cache policy that forwards the query string to the origin and varies the cache key by all query parameters.

B.Update the CloudFront cache policy so the cache key ignores the tracking query parameter, while still using the path and other essential headers.

C.Enable S3 origin access control and keep the existing default cache policy, because origin access changes caching behavior automatically.

D.Set the CloudFront Time-to-Live (TTL) to 0 seconds to ensure the origin always serves the latest asset content.

AnswerB

CloudFront caching depends on the cache key (for example, path, selected headers, and selected query strings). If you configure a cache policy to exclude the tracking query parameter (or ignore specific query string parameters), CloudFront treats requests for the same asset as the same cached object. This prevents cache fragmentation caused by unique tracking values. Origin load decreases and cache hit ratio increases, while correctness is maintained because the excluded parameter does not affect the content of the static JS/CSS objects.

Why this answer

CloudFront's cache key determines whether a request is served from the cache or forwarded to the origin. By configuring a cache policy that ignores the tracking query parameter (e.g., utm_source), CloudFront treats all requests for the same asset path as identical, regardless of the unique tracking parameter. This allows the same JS and CSS files to be cached once and served for all campaign variations, restoring the cache hit ratio.

Exam trap

The trap here is that candidates may think forwarding all query parameters (Option A) is necessary for dynamic content, but for static assets with irrelevant tracking parameters, ignoring them is the correct approach to maximize cache hits.

How to eliminate wrong answers

Option A is wrong because forwarding the query string and varying the cache key by all query parameters would create a separate cache entry for each unique utm_source value, which is exactly the problem causing the cache hit ratio to drop. Option C is wrong because enabling S3 origin access control (OAC) only secures the origin and does not affect CloudFront's caching behavior or cache key configuration. Option D is wrong because setting TTL to 0 seconds forces CloudFront to revalidate every request with the origin, eliminating caching entirely and worsening performance, not improving cache efficiency.

Full explanation →

270

MCQmedium

A team wants to remove a bastion host used for administrative access to EC2 instances in private subnets. The instances should be reachable only for occasional troubleshooting by engineers who authenticate with AWS SSO. What is the best secure alternative within AWS, assuming the instances already have an instance profile attached?

A.Use AWS Systems Manager Session Manager, enabling the required SSM permissions in the instance profile and restricting access to engineers via IAM.

B.Keep the bastion host but move it into a private subnet; engineers can connect by using a corporate VPN into the VPC.

C.Attach a public IP to each private instance so engineers can SSH directly and use security groups to restrict access.

D.Create a security group rule that allows engineers’ source IP addresses to reach instances over RDP on port 3389.

AnswerA

Session Manager avoids inbound SSH from the internet by initiating interactive sessions through Systems Manager. The instance profile must allow SSM actions like StartSession, and engineers’ IAM permissions restrict who can connect. This is a commonly recommended bastion-free alternative that improves security and reduces exposed network paths.

Why this answer

AWS Systems Manager Session Manager provides secure, auditable, agent-based access to EC2 instances without requiring a bastion host, open inbound ports, or SSH keys. By enabling the required SSM permissions (e.g., AmazonSSMManagedInstanceCore) in the instance profile and using IAM policies to restrict access to authenticated engineers via AWS SSO, you achieve a fully managed, secure, and compliant solution. This eliminates the need for a bastion host while maintaining the ability to troubleshoot instances in private subnets.

Exam trap

The trap here is that candidates often think a bastion host is required for private subnet access, or they mistakenly believe that opening inbound ports (even with IP restrictions) is an acceptable alternative, failing to recognize that AWS Systems Manager Session Manager provides a fully managed, agent-based, port-free solution that aligns with the principle of least privilege and removes the bastion host entirely.

Why the other options are wrong

Keeping a bastion host in a private subnet with VPN access still requires managing a bastion host, which the team wants to remove, and does not leverage AWS SSO for authentication as required.

Attaching a public IP to private instances exposes them directly to the internet, violating security best practices. The question requires secure, occasional troubleshooting with AWS SSO, not direct public access.

This option suggests using RDP on port 3389, but the question specifies SSH access for Linux EC2 instances, not RDP. Additionally, relying on source IP restrictions is less secure than using AWS SSO and Systems Manager Session Manager, as IP addresses can be spoofed or changed.

When would these options actually be correct?

In a scenario where the team cannot use Systems Manager (e.g., instances are in a hybrid environment without internet access or SSM Agent) and must maintain a bastion host for administrative access, placing it in a private subnet with VPN access provides secure connectivity without public exposure.

In a scenario where instances must be directly accessible from the internet for a specific application (e.g., a public web server) and security groups are used to restrict access to known IPs, and there is no requirement for SSO or session management.

This option would be correct in a scenario where engineers need to access Windows EC2 instances via RDP, the instances are in a public subnet, and the company has a static, known set of source IP addresses that can be tightly controlled via security groups, with no requirement for AWS SSO integration.

Why candidates pick the wrong answer

Candidates may think that moving the bastion to a private subnet with VPN is a secure improvement that eliminates public exposure, but they overlook the requirement to remove the bastion host entirely and use AWS SSO authentication.

Candidates may think that using security groups to restrict access by IP is sufficient, overlooking the broader security risk of exposing instances to the public internet and the need for centralized access control via SSO.

Candidates may think that restricting by source IP in a security group is sufficient for security, and they might overlook that the question specifies SSH (not RDP) and requires integration with AWS SSO for authentication.

Full explanation →

271

MCQmedium

Based on the exhibit, which Route 53 configuration should be used so traffic automatically returns to the secondary Region only when the primary Region becomes unhealthy?

A.Use latency-based routing with both ALB records enabled.

B.Use failover routing with a primary alias record, a secondary alias record, and a Route 53 health check on the primary target.

C.Use geolocation routing so users are always sent to the closest Region.

D.Use a CNAME record that points to both ALBs so DNS can round-robin between Regions.

AnswerB

Failover routing is designed for this pattern: Route 53 returns the primary alias while the primary endpoint is healthy, and switches to the secondary alias when the primary health check fails. Alias records integrate cleanly with ALB targets, and the health check provides the signal that drives the failover decision.

Why this answer

Failover routing in Amazon Route 53 is designed for active-passive configurations. By creating a primary alias record pointing to the ALB in the primary Region and a secondary alias record pointing to the ALB in the secondary Region, and attaching a Route 53 health check to the primary target, traffic automatically fails over to the secondary Region only when the health check detects the primary as unhealthy. This meets the requirement of returning traffic to the secondary Region only upon primary failure.

Exam trap

The trap here is that candidates often confuse failover routing with latency-based or geolocation routing, assuming that 'closest' or 'fastest' automatically implies health awareness, but Route 53 health checks must be explicitly associated with failover records to trigger automatic traffic redirection.

How to eliminate wrong answers

Option A is wrong because latency-based routing directs users based on lowest latency, not health status, so it would not automatically fail over only when the primary is unhealthy; traffic could still be sent to an unhealthy primary if latency is low. Option C is wrong because geolocation routing sends users based on their geographic location, not the health of the endpoint, so it cannot automatically redirect traffic to the secondary Region when the primary becomes unhealthy. Option D is wrong because a CNAME record cannot point to multiple ALBs for round-robin; CNAME records can only point to a single DNS name, and DNS round-robin does not consider health checks, so traffic would still be sent to an unhealthy primary.

Full explanation →

272

MCQeasy

A travel booking site uses EC2 instances behind an ALB. CPU is consistently high during peak traffic, and request latency rises. What should be configured?

A.A VPC endpoint for CloudWatch only

B.Auto Scaling policy based on an appropriate CloudWatch metric

C.S3 Object Lock

D.Disable health checks

AnswerB

Auto Scaling adds capacity when load increases and removes it when load falls.

Why this answer

An Auto Scaling policy based on a CloudWatch metric like CPUUtilization or request latency directly addresses the root cause: rising CPU and latency under peak traffic. By automatically adding EC2 instances when the metric breaches a threshold, the ALB can distribute load across more resources, reducing CPU per instance and improving response times. This is the standard AWS solution for dynamic scaling to maintain performance.

Exam trap

The trap here is that candidates may confuse monitoring (VPC endpoints) or data protection (S3 Object Lock) with scaling solutions, or think disabling health checks reduces overhead, when the correct approach is to scale horizontally based on load metrics.

How to eliminate wrong answers

Option A is wrong because a VPC endpoint for CloudWatch only enables private connectivity to CloudWatch without internet gateway, but does not add compute capacity or reduce CPU load or latency. Option C is wrong because S3 Object Lock prevents object deletion or overwrite for compliance, which is irrelevant to EC2 CPU and latency issues. Option D is wrong because disabling health checks would cause the ALB to route traffic to unhealthy instances, increasing failures and latency, not solving the performance problem.

Full explanation →

273

Multi-Selectmedium

A company is designing a multi-Region disaster recovery (DR) strategy for a stateless web application running on Amazon EC2 instances behind an Application Load Balancer (ALB). The application uses an Amazon RDS for MySQL database as its data store. The architecture must provide rapid failover with the lowest possible Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Which of the following design choices will help achieve these objectives? (Choose four.)

Select 4 answers

.Configure an active-passive failover strategy by deploying the application stack in two AWS Regions and using Amazon Route 53 health checks with a failover routing policy.

.Set up Amazon RDS Multi-AZ deployment to enable automatic failover to a standby replica in a different Availability Zone within the primary Region.

.Use Amazon RDS cross-Region read replicas with automatic failover to promote a read replica to a primary instance in the secondary Region.

.Deploy the application and ALB in an active-active configuration across two AWS Regions using Amazon Route 53 latency-based routing.

.Store static assets and application state in Amazon S3 with cross-Region replication enabled, and serve them via Amazon CloudFront.

.Use an Amazon RDS for MySQL single-AZ deployment in the primary Region and take daily snapshots copied to the secondary Region.

Why this answer

An active-passive failover strategy with Route 53 failover routing policy is correct because it provides rapid failover by directing traffic to the secondary Region only when health checks fail in the primary, minimizing RTO. Cross-Region read replicas with automatic failover are correct because they allow promoting a read replica to a primary in the secondary Region with low RPO (typically seconds) and automated failover, reducing RTO. Active-active configuration with latency-based routing is correct because it distributes traffic across both Regions, enabling immediate failover without DNS propagation delays, achieving very low RTO.

Storing static assets and application state in S3 with cross-Region replication and CloudFront is correct because it ensures data durability and low-latency access, supporting rapid recovery with minimal RPO.

Exam trap

The trap here is that candidates often confuse Multi-AZ (single-Region high availability) with cross-Region DR, or they assume daily snapshots provide adequate RPO for a DR strategy requiring the lowest possible RPO and RTO.

Full explanation →

274

MCQhard

Based on the exhibit, a single EC2 instance hosts a latency-sensitive cache that performs sustained random reads and writes to persistent block storage. The current EBS volume is a general-purpose SSD, but BurstBalance is repeatedly depleted and p95 I/O latency has risen above 20 ms. The workload needs more than 16,000 sustained IOPS. Which change is the best fix?

A.Move the data to Amazon S3 so the instance can read and write objects directly.

B.Replace the volume with an io2 EBS volume and provision the required IOPS.

C.Keep gp2 and increase the instance size to a compute-optimized family.

D.Enable Amazon EFS with bursting throughput mode for the cache data.

AnswerB

io2 is designed for mission-critical workloads that need sustained, predictable, low-latency random I/O. Unlike gp2, it does not depend on burst credits for performance. Provisioning the required IOPS directly addresses the exhausted BurstBalance and the sustained throughput requirement above 16,000 IOPS.

Why this answer

The workload requires more than 16,000 sustained IOPS with low latency, and the gp2 volume's burst credits are exhausted, causing high latency. An io2 Block Express or io2 volume can be provisioned with the exact IOPS needed (up to 256,000 IOPS) and provides consistent single-digit millisecond latency, making it the best fix for this latency-sensitive, sustained I/O workload.

Exam trap

The trap here is that candidates often assume increasing instance size (Option C) will improve EBS performance, but EBS IOPS and throughput are tied to the volume type and size, not the instance type (except for EBS-optimized bandwidth), so the gp2 burst credit exhaustion remains the root cause.

How to eliminate wrong answers

Option A is wrong because Amazon S3 is object storage accessed via HTTPS, not block storage, and introduces network latency and throughput limitations that are unsuitable for a latency-sensitive cache requiring sustained random reads/writes. Option C is wrong because increasing the instance size to a compute-optimized family does not change the gp2 volume's burst credit model; the volume will still deplete its burst balance and throttle to baseline IOPS (e.g., 160 IOPS per GB), failing to meet the >16,000 sustained IOPS requirement. Option D is wrong because Amazon EFS is a shared file system with NFS protocol overhead and its bursting throughput mode relies on burst credits that can be exhausted, leading to throttled throughput and higher latency, not suitable for sustained high IOPS block-level cache workloads.

Full explanation →

275

Multi-Selecthard

Multiple EC2 instances in different Availability Zones need concurrent read/write access to the same shared files. The files are actively modified by several application servers, and low-latency metadata operations matter more than extremely high aggregate throughput. Which two changes should the team make? Select two.

Select 2 answers

A.Use Amazon EFS instead of EBS or S3 for the shared file system.

B.Create EFS mount targets in every Availability Zone that hosts application instances.

C.Use a single EBS Multi-Attach volume mounted read/write by all instances across AZs.

D.Store the files in S3 and mount them directly through the console as a shared network filesystem.

E.Place the files on instance store volumes so each server has faster local access.

AnswersA, B

Amazon EFS is the managed AWS file service built for shared POSIX-style file access from multiple instances. It supports concurrent read/write access from many EC2 hosts and is a better fit than EBS, which is attached to a single instance, or S3, which provides object storage rather than a native shared filesystem. For an application that expects standard filesystem semantics, EFS is the correct storage layer.

Why this answer

Amazon EFS provides a fully managed, POSIX-compliant, shared file system that can be mounted concurrently by multiple EC2 instances across different Availability Zones (AZs). It supports concurrent read/write access with strong consistency, and its metadata operations are optimized for low latency, making it ideal for workloads where many application servers actively modify the same files. EBS cannot be shared across AZs, and S3 lacks POSIX semantics and low-latency metadata operations.

Exam trap

The trap here is that candidates often confuse EBS Multi-Attach with a cross-AZ shared storage solution, but Multi-Attach is strictly limited to a single AZ and a small number of instances, while EFS is the only AWS shared file system that natively spans AZs with concurrent read/write access.

Full explanation →

276

MCQhard

Based on the exhibit, a workload in private subnets must reach only Amazon S3 and AWS Secrets Manager. The team wants to eliminate internet exposure for those calls and reduce NAT gateway charges. What change should be made?

A.Move the instances into a public subnet and restrict inbound access with security groups.

B.Add a NAT instance and disable the managed NAT gateway to lower cost.

C.Create an S3 gateway endpoint and a Secrets Manager interface endpoint with private DNS, then remove NAT dependency for those service calls.

D.Use VPC peering to a shared services VPC and route all AWS service traffic through that VPC.

AnswerC

S3 is best reached through a gateway VPC endpoint, while Secrets Manager requires an interface endpoint. With private DNS enabled, the application can resolve and reach those services without leaving AWS private networking. This removes the need for NAT traffic for those calls, cuts cost, and keeps service access off the public internet.

Why this answer

VPC Gateway Endpoints for S3 and VPC Interface Endpoints for Secrets Manager allow private subnet instances to access these services over the AWS network without traversing the internet or a NAT gateway. Enabling private DNS on the interface endpoint ensures that standard DNS names resolve to private IPs, eliminating the need for NAT and reducing costs.

Exam trap

The trap here is that candidates may think NAT gateways are required for all AWS service access from private subnets, not realizing that VPC endpoints provide direct, private connectivity without internet exposure.

How to eliminate wrong answers

Option A is wrong because moving instances to a public subnet would expose them to the internet, violating the requirement to eliminate internet exposure. Option B is wrong because a NAT instance still requires internet access and incurs management overhead, failing to eliminate internet exposure and not reducing costs effectively compared to endpoints. Option D is wrong because VPC peering to a shared services VPC does not inherently provide private access to S3 or Secrets Manager without additional endpoints or NAT, and it adds complexity and potential routing issues.

Full explanation →

277

MCQeasy

A company serves mostly static images and JavaScript files from an origin in one AWS Region. They want to reduce origin load and improve global performance. Which change most directly increases cache-hit ratio for static assets while avoiding stale content?

A.Set Cache-Control headers on the origin to always be no-cache so clients revalidate frequently.

B.Use versioned file names (e.g., app.abc123.js) and configure a long TTL with appropriate revalidation behavior.

C.Disable query string forwarding so all URLs without query strings share one cached object even when content differs.

D.Forward all headers, including cookies, to maximize personalization in edge cached responses.

AnswerB

Versioned assets allow long caching with confidence, while new filenames trigger updates when code changes.

Why this answer

Using versioned file names (e.g., app.abc123.js) allows you to set a long Cache-Control max-age TTL (e.g., one year) without risking stale content. When the file changes, the new version gets a new URL, so clients and edge caches immediately fetch the fresh object, maximizing cache hits for unchanged assets while avoiding stale content.

Exam trap

The trap here is that candidates often confuse 'no-cache' with 'no-store' or think that disabling query strings universally improves caching, but they fail to recognize that versioned filenames with long TTLs are the standard pattern for maximizing cache hits while ensuring content freshness.

Why the other options are wrong

Setting Cache-Control: no-cache forces clients to revalidate with the origin on every request, which increases origin load and defeats caching, directly contradicting the goal of reducing origin load and improving performance.

Disabling query string forwarding causes all URLs without query strings to be treated as identical, even if the underlying content differs (e.g., different versions of a file). This can serve stale or incorrect content, reducing cache-hit ratio for static assets that rely on query parameters for versioning.

Forwarding all headers, including cookies, reduces cache-hit ratio because each unique set of headers creates a separate cached object, defeating the purpose of caching static assets that don't vary by user.

When would these options actually be correct?

In a scenario where content changes frequently and users must always see the latest version (e.g., real-time stock prices or live scores), and origin load is not a concern, using no-cache ensures freshness while still allowing conditional revalidation.

In a scenario where query strings are used for tracking or analytics (e.g., ?utm_source=facebook) and do not affect the actual content served, disabling query string forwarding would increase cache-hit ratio by treating all variations as the same object, improving cache efficiency without serving incorrect content.

In a scenario where content must be personalized per user (e.g., a dashboard with user-specific data), forwarding all headers ensures each user receives their tailored response from the edge, and the question asks for maximizing personalization rather than cache-hit ratio.

Why candidates pick the wrong answer

Candidates may think no-cache still allows caching with revalidation, but they overlook that it requires a round-trip to the origin for every request, increasing load and latency.

Candidates may think that ignoring query strings always improves cache-hit ratio by consolidating requests, without realizing that query strings are often used for versioning or content differentiation, and ignoring them can cause stale or wrong content to be served.

Candidates may think that forwarding all headers ensures the edge delivers the most accurate content, not realizing that for static assets, this dramatically reduces cache efficiency.

Full explanation →

278

MCQmedium

A company stores application logs in an S3 bucket. They retain logs for 180 days. Compliance requires that the logs be immutable once written, but the business only reviews logs about once per month. Currently, the team stores everything in S3 Standard, and their monthly S3 bill is too high. They want to reduce storage cost without changing the requirement to keep logs for 180 days. Which lifecycle approach best meets the goal?

A.Use a lifecycle policy to transition objects older than 30 days to S3 Standard-IA, and keep them there until day 180.

B.Use a lifecycle policy to transition objects older than 30 days to S3 Glacier Deep Archive and delete after 30 days.

C.Use a lifecycle policy to transition objects older than 30 days to S3 Intelligent-Tiering with no minimum storage duration.

D.Disable lifecycle management and instead lower costs by deleting objects immediately after they are written.

AnswerA

Logs accessed about monthly match Standard-IA economics and still provide fast retrieval.

Why this answer

It transitions logs older than 30 days to S3 Standard-IA, which offers lower storage costs than S3 Standard while still providing low-latency access for monthly reviews. The lifecycle policy keeps the objects in S3 Standard-IA until day 180, meeting the 180-day retention requirement without incurring the higher cost of S3 Standard for the entire period. S3 Standard-IA has a minimum storage duration of 30 days, which is satisfied by the 30-day transition threshold, and the objects remain immutable as S3 Object Lock is not affected by lifecycle transitions.

Exam trap

The trap here is that candidates may choose S3 Intelligent-Tiering (Option C) thinking it automatically optimizes cost for all access patterns, but for logs accessed only once per month, S3 Standard-IA is more cost-effective because Intelligent-Tiering incurs monitoring and automation overhead and may not move objects to the cheapest tier quickly enough for this specific use case.

Why the other options are wrong

Option B deletes objects after 30 days, failing the requirement to retain logs for 180 days. Additionally, Glacier Deep Archive is not suitable for logs reviewed monthly due to retrieval times of 12-48 hours.

S3 Intelligent-Tiering has a minimum storage duration charge of 30 days for objects moved to the infrequent access tiers, and it does not guarantee immutability; it is designed for unpredictable access patterns, not for reducing costs on logs that are rarely accessed after 30 days but must be retained for 180 days.

Deleting objects immediately violates the compliance requirement that logs be immutable once written and retained for 180 days.

When would these options actually be correct?

This option would be correct if the requirement was to retain logs for only 30 days and compliance allowed deletion after that period, with no need for frequent access.

A company stores data with unknown or changing access patterns (e.g., user-generated content) and wants to automatically optimize costs without manual lifecycle rules. They need no minimum storage duration and can tolerate potential retrieval costs if data is accessed frequently.

If the compliance requirement was removed and the business only needed logs for a very short period (e.g., 24 hours) for immediate troubleshooting, deleting objects immediately after writing would minimize storage costs.

Why candidates pick the wrong answer

Candidates may think Glacier Deep Archive is the cheapest storage and overlook the 180-day retention requirement, focusing only on cost reduction.

Candidates may think Intelligent-Tiering automatically saves costs without needing to specify transitions, but they overlook the minimum storage duration charge and that it is not optimal for data with a predictable, low-access pattern after a known period.

Candidates may think immediate deletion is the simplest way to reduce costs, overlooking the immutable retention and 180-day retention requirements.

Full explanation →

279

MCQmedium

A inventory service uses Lambda functions that call an unreliable third-party API. Failed events must be retained for later investigation after retries are exhausted. What should be configured? The design must avoid adding custom operational scripts.

A.Lambda reserved concurrency set to zero

B.A Lambda dead-letter queue or failure destination

C.A larger deployment package

D.CloudFront error pages

AnswerB

A DLQ or asynchronous failure destination captures failed events after retry attempts.

Why this answer

A Lambda dead-letter queue (DLQ) or failure destination allows you to capture events that have exhausted all retry attempts from an asynchronous invocation. When the Lambda function fails after the maximum retries (default 3), the event is sent to the configured SQS queue or SNS topic for later investigation, without requiring custom scripts or manual polling.

Exam trap

The trap here is that candidates may confuse Lambda's DLQ/failure destination with other error-handling mechanisms like SQS redrive policies or CloudFront custom error pages, which serve different purposes and operate at different layers of the architecture.

How to eliminate wrong answers

Option A is wrong because setting reserved concurrency to zero would completely disable the Lambda function, preventing any invocations and thus failing to process or retain any events. Option C is wrong because a larger deployment package does not affect error handling or event retention; it only increases cold start latency and deployment size. Option D is wrong because CloudFront error pages are for HTTP-level errors from a web distribution, not for capturing asynchronous Lambda invocation failures or dead-letter events.

Full explanation →

280

MCQeasy

An order system receives events and uses a Lambda function to write each order into a database. During traffic spikes, the database sometimes throttles, and Lambda retries lead to occasional message loss in the event flow. The team wants buffering, automatic retries, and a way to isolate messages that repeatedly fail so they can be inspected later. What design change best meets this need?

A.Send events directly from EventBridge to Lambda without any queue to simplify the flow.

B.Use Amazon SQS as a buffer between the event source and Lambda, with an SQS dead-letter queue (DLQ).

C.Use SNS fan-out to multiple Lambda functions, but keep no retry logic and no DLQ.

D.Store events in an S3 bucket and trigger Lambda immediately after each upload, without using DLQs.

AnswerB

SQS buffers bursts, supports retries via visibility timeouts, and DLQs capture messages that fail repeatedly for later review.

Why this answer

B is correct because Amazon SQS acts as a durable buffer between the event source and Lambda, absorbing traffic spikes and providing automatic retries via its visibility timeout mechanism. By attaching a dead-letter queue (DLQ) to the SQS queue, messages that repeatedly fail processing can be isolated for later inspection, preventing data loss and enabling debugging.

Exam trap

The trap here is that candidates may think EventBridge or S3 triggers provide sufficient retry and isolation, but they lack the built-in DLQ and configurable retry mechanics that SQS offers for decoupling and resilience.

How to eliminate wrong answers

Option A is wrong because sending events directly from EventBridge to Lambda without a queue provides no buffering or retry isolation; Lambda’s synchronous invocation retries are limited and can still lead to message loss under throttling. Option C is wrong because SNS fan-out to multiple Lambda functions without retry logic and no DLQ means failed messages are dropped immediately, with no mechanism for buffering or isolating problematic messages. Option D is wrong because storing events in S3 and triggering Lambda immediately after upload does not provide built-in retry logic for processing failures, and S3 does not offer a DLQ concept; failed events would be lost unless custom retry logic is implemented.

Full explanation →

281

MCQmedium

A web application runs in private subnets with no NAT gateway. It needs to retrieve credentials from AWS Secrets Manager at runtime. After a recent network hardening change, the application logs timeout errors when calling Secrets Manager. Which change will most directly enable private connectivity to Secrets Manager while keeping the subnets NAT-free?

A.Create an interface VPC endpoint (AWS PrivateLink) for the Secrets Manager service and update the security group rules to allow HTTPS from the application subnets.

B.Add a public DNS entry in the instance /etc/hosts pointing Secrets Manager to the instance’s private IP so requests do not leave the VPC.

C.Attach an internet gateway to the private route table so that Secrets Manager traffic can reach public endpoints without NAT.

D.Enable S3 VPC endpoint and store the secrets in an S3 bucket instead of Secrets Manager, then retrieve them using S3 gateway endpoints.

AnswerA

An interface VPC endpoint provides private, route-table-scoped connectivity to Secrets Manager without internet access or NAT. Security group rules on the endpoint enforce which subnets/instances can reach it.

Why this answer

An interface VPC endpoint (AWS PrivateLink) for Secrets Manager creates a private, direct connection to the service within the VPC, using Elastic Network Interfaces (ENIs) in the subnets. This allows the application to reach Secrets Manager over HTTPS without traversing the internet, a NAT gateway, or an internet gateway, directly resolving the timeout errors caused by the network hardening change that removed public internet access.

Exam trap

The trap here is that candidates might think a NAT gateway or internet gateway is required for any AWS service access, overlooking that AWS PrivateLink interface endpoints can provide private, direct connectivity to services like Secrets Manager without any public internet exposure.

Why the other options are wrong

Modifying /etc/hosts on an instance does not create a private network path; traffic still routes through the internet unless a private connection exists. Without a NAT gateway or VPC endpoint, the instance cannot reach the public Secrets Manager endpoint, so the change does not resolve the timeout.

Attaching an internet gateway to a private route table would expose the private subnets to the internet, violating the requirement to keep subnets NAT-free and private, and it does not provide private connectivity to Secrets Manager.

This option suggests using S3 instead of Secrets Manager, but the question explicitly requires retrieving credentials from AWS Secrets Manager. Changing the service is not a direct solution to enable private connectivity to Secrets Manager.

When would these options actually be correct?

If the question described a scenario where the application needs to resolve a custom domain name to a private IP within the VPC (e.g., for a database or internal service) and the VPC already has a private network path (like a VPN or Direct Connect) to that IP, then adding a hosts entry would be a quick fix to avoid DNS resolution issues.

In a scenario where a public subnet's route table needs to allow direct outbound internet access for instances with public IPs, attaching an internet gateway to that route table is correct. For example, a web server in a public subnet that must reach public endpoints without NAT.

In a scenario where an application needs to retrieve configuration data or secrets stored in S3, and the subnets have no NAT gateway, an S3 VPC endpoint (gateway endpoint) would provide private connectivity to S3 without requiring a NAT or internet gateway.

Why candidates pick the wrong answer

Candidates may think that overriding DNS resolution with a private IP keeps traffic within the VPC, but they overlook that the underlying network path still requires a route to the destination, which is missing without a VPC endpoint or NAT.

Candidates may think that an internet gateway provides direct internet access without NAT, but they overlook that it must be attached to public subnets, not private ones, and that it does not create a private connection to AWS services.

Candidates may think that using S3 with a VPC endpoint is a valid workaround to avoid NAT, but they overlook the requirement to use Secrets Manager specifically, not S3.

Full explanation →

282

MCQmedium

A company runs a customer portal on an Amazon Aurora PostgreSQL cluster. The application currently connects directly to the writer instance endpoint and keeps long-lived connections open. During a maintenance failover, writes fail until clients are restarted. The team wants the application to reconnect to the correct Aurora endpoint automatically and reduce user-visible write interruptions. Which change is most likely to achieve this?

A.Use the Aurora cluster endpoint for write traffic, use the reader endpoint for read-only traffic, and implement connection retry or reconnect logic on failover.

B.Keep using the original writer instance endpoint so the database host name never changes during failover.

C.Convert the Aurora cluster to Single-AZ so there is only one database node to connect to.

D.Place Route 53 in front of the database and manually update DNS records whenever failover occurs.

AnswerA

The cluster endpoint always targets the current writer, and failover-aware reconnect logic helps the application recover from dropped connections after promotion.

Why this answer

The Aurora cluster endpoint automatically points to the current writer instance, so using it for write traffic ensures that after a failover, new writes are directed to the new writer without needing to change the connection string. Implementing connection retry or reconnect logic in the application is essential because the existing long-lived connections will be broken during failover; the application must detect the failure and re-establish connections to the cluster endpoint to resume writes seamlessly.

Exam trap

The trap here is that candidates assume the writer instance endpoint remains constant during failover (Option B), but in Aurora, the writer instance endpoint changes because it is tied to the specific DB instance, not the cluster.

Why the other options are wrong

The writer instance endpoint points to a specific Aurora node, which changes during failover. Keeping it does not automatically redirect traffic to the new writer, so writes still fail until clients are restarted.

Converting to Single-AZ removes the standby replica, eliminating high availability. During a failover, there is no standby to promote, causing longer downtime and potential data loss, which contradicts the goal of reducing write interruptions.

Manually updating Route 53 DNS records during failover is not automated and would still cause write interruptions until the manual update is completed, failing to meet the requirement of automatic reconnection and reduced downtime.

When would these options actually be correct?

In a scenario where the database is a standalone RDS instance (not Aurora) and the application uses a CNAME pointing to the instance endpoint, the endpoint remains the same after failover if Multi-AZ is enabled, so no reconnect logic is needed.

An exam scenario where cost reduction is the primary goal and the application can tolerate downtime (e.g., a development or test environment) would make Single-AZ correct. The question would explicitly state that high availability is not required.

In a scenario where a company needs to redirect traffic to a standby database in a different region after a disaster, and they have a script or automation to update Route 53 records, this could be a valid approach for manual failover control.

Why candidates pick the wrong answer

Candidates may assume the writer endpoint is static and failover is transparent, not realizing Aurora's writer endpoint changes to a different physical node after failover.

Candidates may think that fewer nodes means simpler failover, overlooking that Aurora's Multi-AZ failover is automatic and faster. They might assume Single-AZ avoids failover issues entirely, not realizing it removes redundancy.

Candidates may think DNS-based routing provides a simple way to change endpoints without modifying application code, overlooking the need for automation and the fact that Aurora already provides cluster endpoints for this purpose.

Full explanation →

283

MCQmedium

A media processing pipeline runs batch jobs on EC2. The jobs can tolerate interruptions because they checkpoint progress to durable storage and can restart. The total workload is variable week-to-week, and there is no need to guarantee capacity at specific times. To reduce compute cost while maintaining correctness, what EC2 purchase option and approach is the best fit?

A.Use EC2 Spot Instances with interruption handling and restart from checkpoints.

B.Use All Upfront Reserved Instances sized for the average weekly workload to minimize cost.

C.Use On-Demand Instances and scale only during business hours to reduce idle time.

D.Use Savings Plans with a fixed hourly commitment to ensure capacity for the entire year.

AnswerA

Spot capacity is typically the lowest-cost EC2 option and can be reclaimed by AWS with interruption notices. Because the workload is explicitly restartable and checkpoints to durable storage, interruptions do not break correctness. Since there is no requirement to reserve capacity, the variable workload aligns well with Spot’s spare-capacity model.

Why this answer

Spot Instances offer up to 90% cost savings compared to On-Demand and are ideal for fault-tolerant, stateless workloads that can checkpoint progress to durable storage. Since the batch jobs can tolerate interruptions and restart from checkpoints, Spot Instances provide the lowest compute cost while maintaining correctness. No other purchase option achieves the same level of cost reduction for this variable, interruption-tolerant workload.

Exam trap

The trap here is that candidates often choose Reserved Instances or Savings Plans thinking they always provide the best cost savings, but they fail to recognize that Spot Instances are significantly cheaper and perfectly suited for fault-tolerant, checkpointed batch workloads that do not require guaranteed capacity.

How to eliminate wrong answers

Option B is wrong because All Upfront Reserved Instances require a 1- or 3-year commitment and are sized for a fixed capacity, which does not match the variable week-to-week workload and would lead to over-provisioning or under-utilization, increasing cost. Option C is wrong because On-Demand Instances are the most expensive per-hour option and scaling only during business hours ignores the fact that the workload can run at any time; this approach does not minimize cost compared to Spot. Option D is wrong because Savings Plans with a fixed hourly commitment lock in a baseline spend and do not provide the deep discounts of Spot Instances; they also guarantee capacity only up to the committed amount, which is unnecessary for a workload that does not need guaranteed capacity.

Full explanation →

284

MCQmedium

A marketing site stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost? The design must avoid adding custom operational scripts.

A.S3 lifecycle policy that transitions objects to lower-cost storage classes over time

B.Keep all logs in S3 Standard indefinitely

C.Use EBS snapshots for the logs

D.Move all logs immediately to S3 Glacier Deep Archive

AnswerA

Lifecycle rules automate transitions based on age, matching storage cost to access patterns.

Why this answer

S3 Lifecycle policies allow you to automatically transition objects from S3 Standard to lower-cost storage classes like S3 Standard-IA (Infrequent Access) after 30 days, then to S3 Glacier Deep Archive after one year, without custom scripts. This matches the access pattern: frequent queries for 30 days, rare access for a year, then long-term retention for compliance. The policy automates cost reduction by moving data to progressively cheaper storage as access frequency decreases.

Exam trap

The trap here is that candidates might choose Option D, thinking immediate archiving is cheapest, but they overlook the 30-day query requirement and the fact that S3 Glacier Deep Archive has retrieval times of 12+ hours, making it unsuitable for frequent access.

How to eliminate wrong answers

Option B is wrong because keeping all logs in S3 Standard indefinitely incurs the highest storage cost, ignoring the infrequent access and long-term retention requirements. Option C is wrong because EBS snapshots are designed for block-level backups of EC2 volumes, not for storing S3 log data, and would require custom scripts to move logs from S3 to EBS, violating the 'no custom operational scripts' constraint. Option D is wrong because moving all logs immediately to S3 Glacier Deep Archive would make them inaccessible for the first 30 days of frequent queries (retrieval takes 12 hours or more), and the cost of early deletion fees or retrieval requests would outweigh savings.

Full explanation →

285

MCQmedium

A DynamoDB table uses this schema: partition key = customerId, sort key = timestamp. During a marketing campaign, one customer generates extremely high read traffic and the application sees ProvisionedThroughputExceeded errors even though the table’s total capacity is sufficient. What change most directly improves read distribution across partitions?

A.Increase the table’s provisioned read capacity units while keeping partition key = customerId.

B.Add a salt component to the partition key by changing it to customerId#salt, where salt is derived from a hash of requestId so a single customer’s requests are spread across many partitions; keep the sort key as timestamp.

C.Remove the sort key and use timestamp as the partition key to increase cardinality.

D.Switch to on-demand capacity and rely on DynamoDB to automatically distribute reads across partitions.

AnswerB

Hot partition throttling usually occurs when too many requests target a single partition key value. Salting transforms the partition key so that one high-traffic customerId maps to multiple distinct partition keys (e.g., customerId#0, customerId#1, etc.), which increases the number of partitions that can serve that customer’s workload concurrently and reduces the probability that a single partition becomes overloaded.

Why this answer

Adding a salt to the partition key (e.g., customerId#hash(requestId)) distributes the read-heavy customer's data across multiple physical partitions. This prevents a single hot partition from throttling requests, even when the table's total provisioned capacity is sufficient. DynamoDB's partition key determines the internal hash used for data placement, so increasing partition key cardinality directly improves read distribution.

Exam trap

The trap here is that candidates confuse total table capacity with per-partition capacity, assuming that increasing RCUs or switching to on-demand will fix throttling caused by a hot key, when in reality the bottleneck is the single partition's throughput limit.

Why the other options are wrong

Increasing read capacity units does not address the root cause: a single hot partition. The total capacity may be sufficient, but all reads for the hot customer hit the same partition, causing throttling at that partition level.

Changing the partition key to timestamp would cause all reads for a given time range to hit a single partition, creating a hot key and worsening the distribution issue, not solving it.

On-demand capacity handles throughput spikes but does not address the root cause: a single hot partition. The ProvisionedThroughputExceeded errors occur because one customer's data is concentrated on one partition, and on-demand capacity does not redistribute data across partitions.

When would these options actually be correct?

This option would be correct if the question described a scenario where overall table throughput is insufficient due to uniformly high traffic across all partitions, and the goal is simply to increase total capacity without a hot key issue.

If the question described a scenario where the access pattern is time-series with uniform read traffic across all timestamps (e.g., reading all records from the last hour for analytics), and the issue was low cardinality of the original partition key, then using timestamp as partition key could improve distribution.

This option would be correct in a scenario where the application experiences unpredictable, sudden traffic spikes across all partitions (e.g., viral social media campaign), and the issue is overall throughput capacity rather than a single hot key. On-demand capacity automatically scales to handle such spikes without manual provisioning.

Why candidates pick the wrong answer

Candidates often assume that insufficient capacity is the problem and that increasing RCUs will solve throttling, overlooking that DynamoDB throttles at the partition level, not the table level.

Candidates may think that increasing partition key cardinality always improves distribution, overlooking that timestamp as a partition key can create hot partitions for recent data.

Candidates may think on-demand capacity solves all throughput issues because it eliminates the need to manage capacity, overlooking that hot partitions are a data distribution problem that capacity alone cannot fix.

Full explanation →

286

MCQmedium

A security requirement states: all uploads to an S3 bucket must (1) use TLS in transit and (2) use server-side encryption with AWS KMS (SSE-KMS) using the CMK key id 'abcd-1234'; otherwise the upload should be rejected. A developer reports that uploads are succeeding even though clients are sometimes using non-encrypted requests. Which bucket policy approach most directly enforces both controls?

A.Add an Allow statement granting s3:PutObject to the developer role; rely on IAM conditions in the developer role to enforce TLS and SSE-KMS.

B.Use Deny statements that reject PutObject when aws:SecureTransport is false and reject PutObject when s3:x-amz-server-side-encryption is not 'aws:kms' or when s3:x-amz-server-side-encryption-aws-kms-key-id does not equal 'abcd-1234'.

C.Enable S3 default encryption to SSE-KMS and remove any bucket policy enforcement, since default encryption automatically rejects all noncompliant uploads.

D.Attach a WAF rule to the S3 website endpoint to block non-TLS requests, because bucket policies cannot evaluate aws:SecureTransport.

AnswerB

These Deny conditions directly block noncompliant requests regardless of the caller’s IAM permissions because explicit Deny in a resource policy overrides any Allow. aws:SecureTransport identifies whether the request used TLS. The SSE-KMS headers (s3:x-amz-server-side-encryption and s3:x-amz-server-side-encryption-aws-kms-key-id) identify whether SSE-KMS was requested and which CMK key id was used.

Why this answer

Bucket policies can use the `aws:SecureTransport` condition key to enforce TLS and the `s3:x-amz-server-side-encryption` and `s3:x-amz-server-side-encryption-aws-kms-key-id` condition keys to enforce SSE-KMS with the specific CMK key ID. By using Deny statements, any request that does not meet both conditions is explicitly rejected, regardless of any Allow statements that might otherwise grant access. This directly enforces the security requirement at the bucket level.

Exam trap

The trap here is that candidates often confuse S3 default encryption with enforcement—default encryption only applies encryption to objects that lack it, but does not reject non-compliant uploads, so it cannot replace a bucket policy Deny statement for rejecting requests that violate encryption or TLS requirements.

How to eliminate wrong answers

Option A is wrong because relying on IAM conditions in the developer role does not enforce the controls for all clients; any client that can assume the role or use different credentials could bypass the conditions, and IAM conditions are not evaluated for anonymous or cross-account requests. Option C is wrong because S3 default encryption only applies server-side encryption to objects that are uploaded without an encryption header; it does not reject non-compliant uploads—it silently encrypts them, so requests without TLS or with a different KMS key ID would still succeed. Option D is wrong because AWS WAF cannot be attached directly to an S3 bucket endpoint; S3 does not support WAF integration, and bucket policies can indeed evaluate `aws:SecureTransport` to enforce TLS.

Full explanation →

287

Multi-Selecthard

A fleet of test servers is rebuilt every week from AMIs. EBS volumes are often left behind after termination, and the team creates daily snapshots of every volume even when nothing changes. Which three actions most reduce storage cost while preserving recovery options? Select three.

Select 3 answers

A.Use gp3 for new EBS volumes instead of gp2 when similar performance is enough.

B.Automate snapshot creation and deletion with Amazon Data Lifecycle Manager.

C.Move old snapshots to the EBS Snapshot Archive tier once they are rarely restored.

D.Keep unattached volumes around for troubleshooting after instance termination.

E.Raise provisioned IOPS on every volume so snapshot restore time feels faster.

AnswersA, B, C

Correct. gp3 decouples baseline performance from volume size, which commonly lowers cost for workloads that do not need gp2's hidden throughput coupling. It is a practical right-sizing move for many general-purpose volumes.

Why this answer

Gp3 volumes offer a baseline performance that is often sufficient for test server workloads, and they are typically more cost-effective than gp2 volumes when similar performance is adequate. By using gp3, you avoid paying for provisioned IOPS that you do not need, directly reducing storage costs without sacrificing recovery options.

Exam trap

The trap here is that candidates may think keeping unattached volumes is a valid recovery option, but it is more cost-effective to snapshot and delete them, and they may overlook that raising IOPS does not accelerate snapshot restore times.

Full explanation →

288

MCQmedium

A document portal requires consistent high IOPS for a transactional database on EC2. Which EBS volume type is most suitable?

A.sc1 Cold HDD

B.Instance store only

C.Provisioned IOPS SSD such as io2

D.st1 Throughput Optimized HDD

AnswerC

io2 is designed for business-critical workloads requiring consistent high IOPS and durability.

Why this answer

Provisioned IOPS SSD (io2) is the correct choice because it delivers consistent, high IOPS performance required for transactional databases running on EC2. io2 volumes offer a 99.999% durability and can sustain up to 256,000 IOPS per volume, making them ideal for latency-sensitive workloads like OLTP databases.

Exam trap

The trap here is that candidates often confuse 'high IOPS' with 'high throughput' and select st1 or sc1, not realizing that transactional databases require low-latency random I/O, which only SSD-based volumes like io2 can consistently deliver.

How to eliminate wrong answers

Option A is wrong because sc1 Cold HDD is designed for infrequently accessed, throughput-oriented workloads with low cost, and cannot provide consistent high IOPS due to its burst-bucket model and high latency. Option B is wrong because instance store volumes are ephemeral and data is lost on instance stop/termination, making them unsuitable for persistent transactional databases that require durability and consistent IOPS. Option D is wrong because st1 Throughput Optimized HDD is optimized for large, sequential workloads like big data and log processing, not for random I/O patterns typical of transactional databases, and its performance is limited to a maximum of 500 IOPS per volume.

Full explanation →

289

MCQeasy

A.Deploy the job on EC2 instances and keep them running continuously for the daily schedule.

B.Use AWS Lambda triggered by a schedule (for example, EventBridge) to run the report at the required time.

C.Run the job in an RDS database using stored procedures scheduled by the database engine.

D.Use an Auto Scaling group with a fixed minimum size of one instance and disable scaling.

AnswerB

Lambda runs on demand and charges for execution time, aligning spend with actual job runtime and reducing ops.

Why this answer

AWS Lambda is the ideal choice because it is a serverless compute service that runs code only when triggered, aligning with the requirement to pay primarily for actual runtime. By using Amazon EventBridge (CloudWatch Events) to invoke the Lambda function on a daily schedule, the team eliminates the need to provision or manage servers, and the job's typical runtime of a few minutes (under 15 minutes, Lambda's maximum execution timeout) fits perfectly within Lambda's constraints.

Exam trap

The trap here is that candidates may overlook Lambda's 15-minute timeout limit and assume any short-duration job is suitable, or they may mistakenly think that RDS stored procedures (Option C) are a cost-effective compute alternative, when in fact they are not designed for general-purpose application logic and still require a running database instance.

How to eliminate wrong answers

Option A is wrong because keeping EC2 instances running continuously incurs costs for idle time, which directly contradicts the goal of paying primarily for actual runtime and reducing operational overhead. Option C is wrong because RDS stored procedures are designed for database-level logic and are not a general-purpose compute solution for running report-generation jobs; they also incur costs for the RDS instance running 24/7 and lack the flexibility of a dedicated compute service. Option D is wrong because an Auto Scaling group with a fixed minimum size of one instance still keeps a server running 24/7, resulting in the same cost and operational overhead as Option A, and does not achieve the goal of paying only for runtime.

Full explanation →

290

MCQmedium

A global video platform serves mostly static images and JavaScript files from an S3 origin. Users in distant countries report slow load times. What should improve performance most?

A.A larger S3 bucket

B.Amazon CloudFront distribution with the S3 bucket as origin

C.RDS read replicas

D.An EC2 Auto Scaling group in one Region

AnswerB

CloudFront caches content at edge locations close to users, reducing latency.

Why this answer

Amazon CloudFront is a content delivery network (CDN) that caches static content (images, JavaScript) at edge locations worldwide. By distributing content closer to users, it reduces latency and improves load times significantly compared to serving directly from a single S3 origin. This is the most effective solution for a global user base accessing static assets.

Exam trap

The trap here is that candidates might confuse 'scaling' (Auto Scaling, larger buckets) with 'latency reduction' (CDN), or mistakenly think database read replicas can serve static web assets, when in fact they are only for relational database read offloading.

How to eliminate wrong answers

Option A is wrong because S3 bucket size has no impact on performance; S3 scales automatically to handle any amount of data, and a larger bucket does not reduce latency for distant users. Option C is wrong because RDS read replicas are designed to offload read traffic from a relational database, not to serve static files like images or JavaScript; they address database query performance, not content delivery. Option D is wrong because an EC2 Auto Scaling group in one Region only scales compute capacity within that single geographic area, failing to reduce latency for users in distant countries who still must traverse long network paths.

Full explanation →

291

Multi-Selectmedium

A startup runs an API on Amazon EC2. The instance must read items from one DynamoDB table and upload logs to one S3 bucket. Platform engineers also need a way to create new application roles, but those roles must never exceed a predefined set of permissions. Which three actions should the architect take? Select three.

Select 3 answers

A.Attach an IAM role to the EC2 instance profile and remove long-lived access keys from the server.

B.Give the EC2 instance an IAM user with administrator access for simplicity.

C.Scope the application policy to the exact DynamoDB table ARN and S3 bucket prefix.

D.Store the access keys in the application configuration file and rotate them later.

E.Use a permissions boundary for any IAM roles the platform team is allowed to create.

AnswersA, C, E

This gives the workload temporary credentials through the instance metadata service and avoids storing secrets on the host. It is the standard least-privilege pattern for EC2-based applications.

Why this answer

Attaching an IAM role to the EC2 instance profile allows the instance to obtain temporary credentials via the instance metadata service (IMDS), eliminating the need to store long-lived access keys on the server. This follows the AWS security best practice of using roles for EC2 to securely access DynamoDB and S3 without managing static credentials.

Exam trap

The trap here is that candidates may think storing access keys in a config file with rotation is acceptable, but AWS explicitly recommends using IAM roles for EC2 to avoid the security risks of long-lived static credentials.

Full explanation →

292

MCQmedium

A healthcare document service stores audit logs in S3. The compliance team requires that logs cannot be overwritten or deleted for seven years. What should be configured?

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

B.S3 server access logging

C.S3 lifecycle expiration after seven years

D.S3 versioning only

AnswerA

S3 Object Lock in compliance mode ensures that objects, once written, cannot be overwritten or deleted by any user, including the root account, until the specified retention period expires. This "write-once-read-many" (WORM) model is crucial for audit logs, providing an immutable record that meets stringent regulatory compliance requirements for data integrity and non-repudiation. It directly prevents any accidental or malicious alteration of the log data, making it tamper-proof.

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, as compliance mode enforces a strict write-once-read-many (WORM) model that cannot be bypassed.

Exam trap

The trap here is that candidates often confuse S3 versioning with immutability, assuming versioning alone prevents deletion, but versioning only protects against accidental overwrites by creating new versions—it does not prevent explicit deletion of the current version or the entire object.

How to eliminate wrong answers

Option B 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 C is wrong because S3 lifecycle expiration automatically deletes objects after seven years, which violates the requirement that logs cannot be deleted. Option D is wrong because S3 versioning alone preserves previous versions but does not prevent deletion of the current version or overwriting of objects; it must be combined with Object Lock to enforce immutability.

Full explanation →

293

MCQhard

A media processing workflow in private subnets downloads large amounts of data from S3 through a NAT gateway. NAT data processing charges are high. What should the architect use to reduce cost? The architecture review board prefers a managed AWS-native control.

A.S3 Object Lambda

B.AWS Shield Advanced

C.Gateway VPC endpoint for Amazon S3

D.A larger NAT gateway

AnswerC

A gateway endpoint routes S3 traffic privately without NAT gateway data processing charges.

Why this answer

A Gateway VPC endpoint for Amazon S3 allows instances in private subnets to access S3 directly over the AWS network without traversing a NAT gateway, eliminating NAT data processing charges. This is a managed AWS-native control that meets the architecture review board's preference, as it uses AWS PrivateLink and does not require any changes to the S3 bucket or client configuration beyond route table updates.

Exam trap

The trap here is that candidates may confuse Gateway VPC endpoints with Interface VPC endpoints, assuming both incur hourly charges, when in fact Gateway endpoints are free and only incur standard S3 data transfer costs, making them the optimal choice for reducing NAT-related expenses.

How to eliminate wrong answers

Option A is wrong because S3 Object Lambda is used to transform data on the fly during S3 GET requests, not to reduce data transfer costs from S3 to a VPC; it adds processing overhead and does not address NAT gateway charges. Option B is wrong because AWS Shield Advanced is a DDoS protection service that does not reduce data transfer costs or replace the need for a NAT gateway; it is unrelated to S3 access cost optimization. Option D is wrong because a larger NAT gateway would increase, not decrease, costs, as it still incurs per-GB data processing charges for all traffic through it, and does not eliminate the need for NAT traversal.

Full explanation →

294

MCQmedium

Your ecommerce app runs behind an Application Load Balancer (ALB) and uses an RDS database for orders. During an AZ impairment in us-east-1, customers report that checkout takes several minutes to recover. The current design places EC2 instances only in private subnets of AZ-a, while the ALB spans multiple subnets. The RDS DB instance is Multi-AZ. Management wants automatic recovery within the same Region. Which change best addresses the issue with minimal operational overhead?

A.Move the EC2 instances into Auto Scaling Groups that span private subnets in at least two AZs, keeping the ALB spanning those subnets.

B.Switch from RDS Single-AZ to RDS Multi-AZ, keeping the EC2 instances in only AZ-a because failover will still reach them.

C.Terminate the ALB and use a Network Load Balancer (NLB) in front of the existing single-AZ EC2 instances.

D.Add more EC2 instances in AZ-a and increase the ALB health check thresholds to avoid unnecessary replacements during impairments.

AnswerA

An Auto Scaling Group across multiple AZs ensures healthy capacity exists when an AZ becomes impaired, and the ALB can route to instances in any available AZ.

Why this answer

The current design has a single point of failure: all EC2 instances are in one Availability Zone (AZ-a). During an AZ impairment, those instances become unreachable, causing the checkout process to fail until the impairment ends or manual intervention occurs. By placing EC2 instances in an Auto Scaling Group spanning at least two AZs, the application can automatically recover by launching new instances in a healthy AZ, while the ALB distributes traffic across the surviving AZs.

This minimizes operational overhead as Auto Scaling handles instance replacement automatically.

Exam trap

The trap here is that candidates may focus on the database layer (Multi-AZ) or load balancer type (NLB vs ALB) and overlook the critical single-AZ EC2 instance placement, which is the actual bottleneck causing the prolonged recovery during an AZ impairment.

How to eliminate wrong answers

Option B is wrong because the RDS DB instance is already Multi-AZ (as stated in the question), so switching from Single-AZ to Multi-AZ is not a change; moreover, keeping EC2 instances in only AZ-a still leaves them vulnerable to an AZ impairment, as the ALB cannot route traffic to a healthy AZ if no instances exist there. Option C is wrong because replacing the ALB with an NLB does not address the root cause—EC2 instances are still confined to a single AZ; additionally, an NLB operates at Layer 4 and lacks the HTTP/HTTPS health checks and content-based routing that an ALB provides, which could break the ecommerce application's functionality. Option D is wrong because adding more EC2 instances in AZ-a only increases capacity within the same failing AZ, and increasing health check thresholds delays the detection of unhealthy instances, prolonging recovery time rather than improving it.

Full explanation →

295

MCQmedium

Your CI system assumes an IAM role RoleForDeploy using STS AssumeRole and includes a session tag called Project=blue. The role’s permissions policy uses an ABAC condition like aws:PrincipalTag/Project to allow access only to resources tagged with the same project. AssumeRole succeeds, but deployments fail with AccessDenied. CloudTrail shows the role was assumed, yet the effective session does not contain the Project tag. Which change most directly fixes this issue?

A.Add permissions for sts:TagSession to the IAM role so the CI pipeline is allowed to pass the Project session tag during AssumeRole.

B.Remove the ABAC condition using aws:PrincipalTag/Project so the policy ignores session tags.

C.Move the aws:PrincipalTag/Project condition into the trust policy so it applies during the AssumeRole call.

D.Add kms:Decrypt permission to the CI role because missing tags are typically caused by KMS authorization failures.

AnswerA

Session tags are not automatically granted; the role needs sts:TagSession permission to allow passing tags into the session.

Why this answer

When an IAM role is assumed with STS AssumeRole and session tags are included, the calling principal must have explicit permission to pass those tags via the `sts:TagSession` action. Without this permission, the session tags are silently dropped, even though the AssumeRole call succeeds. Adding `sts:TagSession` to the role's permissions allows the CI pipeline to pass the `Project=blue` tag, making the ABAC condition on `aws:PrincipalTag/Project` evaluate correctly and granting access to tagged resources.

Exam trap

The trap here is that candidates assume session tags are automatically applied when passed in the AssumeRole call, but AWS requires explicit `sts:TagSession` permission for the tags to take effect, which is a subtle but critical detail tested in ABAC scenarios.

How to eliminate wrong answers

Option B is wrong because removing the ABAC condition would bypass the intended security control, but the root cause is that the session tag is not being applied, not that the condition is misconfigured. Option C is wrong because moving the condition to the trust policy would not fix the missing tag; the trust policy controls who can assume the role, not how session tags are passed, and the condition on `aws:PrincipalTag/Project` is correctly placed in the permissions policy to enforce ABAC. Option D is wrong because KMS authorization failures are unrelated to missing session tags; the issue is purely about STS tag propagation, not encryption key permissions.

Full explanation →

296

MCQmedium

A Lambda function for a mobile banking backend needs to read a database password. The password must rotate automatically every 30 days and should not be stored in environment variables. Which service should be used? The design must avoid adding custom operational scripts.

A.An encrypted object in Amazon S3

B.AWS Secrets Manager with rotation enabled

C.AWS Systems Manager Parameter Store SecureString without automation

D.A KMS-encrypted Lambda environment variable

AnswerB

Secrets Manager stores secrets securely and supports automatic rotation using a rotation Lambda function.

Why this answer

AWS Secrets Manager is the correct choice because it natively supports automatic rotation of secrets on a configurable schedule (e.g., every 30 days) without requiring custom scripts. It also provides fine-grained access control and integrates directly with Lambda via the AWS SDK, keeping the password out of environment variables and code.

Exam trap

The trap here is that candidates often confuse AWS Systems Manager Parameter Store SecureString (which can store secrets but lacks automatic rotation) with Secrets Manager, or they assume that encrypting environment variables with KMS is sufficient for rotation, ignoring the need for automated lifecycle management.

How to eliminate wrong answers

Option A is wrong because storing an encrypted object in Amazon S3 requires custom code to retrieve, decrypt, and rotate the password, violating the 'no custom operational scripts' constraint. Option C is wrong because AWS Systems Manager Parameter Store SecureString without automation does not support automatic rotation; you would need to manually update the parameter or add a custom rotation solution. Option D is wrong because a KMS-encrypted Lambda environment variable is static and cannot be rotated automatically; you would need to redeploy the function to change the password, which adds operational overhead.

Full explanation →

297

MCQhard

Based on the exhibit, what change should the team make to achieve the lowest possible network latency for the distributed workload?

A.Place the instances in a spread placement group across multiple Availability Zones.

B.Move the workload into a cluster placement group in one Availability Zone.

C.Add an Application Load Balancer in front of the workers to reduce inter-node latency.

D.Increase the EC2 instance size while keeping the current multi-AZ layout.

AnswerB

Cluster placement groups place instances physically close together inside one Availability Zone, which is the best AWS option for workloads that need low-latency, high-bandwidth communication between many nodes. The exhibit explicitly says the workload can run in a single AZ if performance improves. That makes cluster placement groups the right fit.

Why this answer

A cluster placement group provides the lowest possible network latency and highest throughput by placing all instances in a single Availability Zone with low-latency, non-blocking 10 Gbps or 25 Gbps network connectivity between them. This is ideal for tightly coupled, distributed workloads that require frequent inter-node communication, such as HPC or data analytics jobs.

Exam trap

The trap here is that candidates often assume multi-AZ is always better for high availability, but for latency-sensitive distributed workloads, a single-AZ cluster placement group is the correct choice to minimize inter-node latency, even though it sacrifices fault tolerance.

Why the other options are wrong

Spread placement groups maximize availability and fault isolation by placing instances on distinct hardware across multiple AZs, which increases network latency due to physical separation. The goal is lowest possible latency, which requires a cluster placement group in a single AZ.

An Application Load Balancer distributes incoming traffic across targets, but it does not reduce inter-node latency between workers; in fact, it adds a hop and increases latency for node-to-node communication.

Increasing EC2 instance size does not reduce network latency between instances; it improves compute capacity. The question specifically asks for lowest network latency, which requires physical proximity, not larger instances.

When would these options actually be correct?

A question asks for the highest availability and fault tolerance for a critical application that must survive an entire AZ failure, and latency is not the primary concern. Spread placement groups across AZs would be correct.

This option would be correct in a question asking how to distribute incoming client requests across multiple EC2 instances in different Availability Zones for high availability and fault tolerance, while also providing health checks and SSL termination.

This option would be correct in a scenario where the workload is compute-bound and requires more CPU or memory per instance, and the goal is to improve throughput or reduce processing time, not network latency.

Why candidates pick the wrong answer

Candidates may think that distributing instances across AZs always improves performance, confusing high availability with low latency, or they may overvalue fault tolerance when the question prioritizes latency.

Candidates may think that load balancers always improve performance, confusing load distribution for user-facing traffic with reducing latency for internal distributed workloads.

Candidates may assume larger instances have better network performance or that more resources inherently reduce latency, confusing compute capacity with network characteristics.

Full explanation →

298

MCQmedium

Your media processing pipeline writes original uploads to an S3 bucket and later generates derivative files. An operator accidentally deletes a subset of original uploads in production. You need to (1) restore the deleted objects with minimal data loss and (2) protect against both regional disasters and future operator mistakes. The company requires recovery even if objects are deleted and later overwritten. What is the most effective change to meet these requirements?

A.Enable S3 versioning on the bucket and configure cross-Region replication so previous versions are available after regional loss and accidental deletion.

B.Move all objects to S3 Glacier Instant Retrieval and apply a lifecycle policy to keep only the latest object copy.

C.Use S3 server-side encryption with KMS keys and rely on access logs to manually recover the deleted objects.

D.Enable S3 bucket policies that deny DeleteObject, but do not enable versioning or replication.

AnswerA

Versioning retains prior object versions, and cross-Region replication provides redundancy across Regions for recovery after deletion or disaster.

Why this answer

Enabling S3 Versioning preserves all object versions, including deleted markers and overwritten objects, allowing recovery from accidental deletions. Cross-Region Replication (CRR) replicates both current and previous versions to a secondary region, providing protection against regional disasters. This combination ensures that even if objects are deleted and later overwritten, the original versions remain recoverable in both the source and destination buckets.

Exam trap

The trap here is that candidates often assume S3 bucket policies or encryption alone can protect against deletion, but only versioning preserves object history, and only replication provides regional disaster recovery.

How to eliminate wrong answers

Option B is wrong because moving objects to S3 Glacier Instant Retrieval does not provide versioning or replication, so deleted objects cannot be restored and there is no protection against regional disasters. Option C is wrong because S3 server-side encryption with KMS keys does not preserve deleted or overwritten objects; access logs only record events, not the data itself, making manual recovery impossible. Option D is wrong because a bucket policy denying DeleteObject can be bypassed by authorized users or misconfigurations, and without versioning or replication, deleted objects are permanently lost and there is no regional disaster recovery.

Full explanation →

299

MCQmedium

Your mobile app writes events to a single DynamoDB table with partition key = customerId and sort key = eventTime. During a promotional campaign, one tenant ("ACME") generates far more traffic than others. CloudWatch shows sustained throttling (ProvisionedThroughputExceeded) and elevated p99 latency only for that tenant. The workload pattern cannot be changed to a completely different schema, but you can change how items are partitioned. Which design change is most likely to reduce the hot-partition throttling while keeping efficient reads for ACME?

A.Use the same partition key (customerId), but increase the table’s provisioned capacity for that tenant.

B.Change the partition key to a salted key such as customerId + shard number, and include the eventTime ordering using the sort key.

C.Switch to on-demand capacity mode and keep the partition key unchanged.

D.Enable Global Tables so that reads are served from a nearby replica for ACME.

AnswerB

Hot-partition throttling happens when a single logical partition (one partition key value) receives more requests than it can serve. By salting the partition key (for example, customerId#shardId), ACME’s writes are spread across multiple physical partitions, reducing request rate per partition and lowering throttling. Efficient reads for ACME can be preserved by querying only the shard partitions that belong to ACME (for example, using a small, deterministic set of shardIds and issuing parallel queries per shard, then merging results). This avoids scanning the whole table and keeps access patterns predictable while improving tail latency.

Why this answer

Salting the partition key by appending a shard number (e.g., customerId + random digit) distributes ACME's writes across multiple partitions, eliminating the hot partition. The sort key still preserves eventTime ordering, so queries for a specific customer can be parallelized across shards and merged client-side or via a composite sort key pattern, maintaining efficient reads.

Exam trap

The trap here is that candidates assume increasing capacity or switching to on-demand alone solves hot partitions, but they overlook DynamoDB's fixed per-partition throughput limits that require key design changes to distribute load.

How to eliminate wrong answers

Option A is wrong because increasing provisioned capacity for a single tenant does not solve the hot-partition issue; DynamoDB distributes capacity across partitions, and a single partition's throughput is capped at 3,000 RCU or 1,000 WCU regardless of table-level settings. Option C is wrong because switching to on-demand capacity mode only handles traffic spikes at the table level, but a single hot partition still hits the same per-partition throughput limits (3,000 RCU/1,000 WCU), causing throttling. Option D is wrong because Global Tables replicate data across regions for low-latency reads and disaster recovery, but they do not redistribute write load within a single table; ACME's writes still target the same partition key in the source region, so throttling persists.

Full explanation →

300

MCQmedium

An Aurora PostgreSQL cluster is experiencing high read latency because 85% of traffic consists of read-only queries. The write workload must stay on the writer instance, and the team wants to offload reads without changing the application’s core query patterns. What is the best architectural option?

A.Increase the writer instance size so it can handle more reads and writes simultaneously.

B.Add Aurora reader instances (read replicas) and route read queries to the reader endpoint while keeping writes on the writer endpoint.

C.Enable Multi-AZ failover only and rely on the standby to serve reads in normal operation.

D.Move the read workload to ElastiCache Redis while keeping DynamoDB as the SQL data source.

AnswerB

Aurora reader instances are designed for exactly this pattern: they provide dedicated compute capacity for read-only workloads. By sending read queries to the reader endpoint and keeping writes on the writer endpoint, the cluster can scale read performance without forcing reads to contend with write processing on the writer.

Why this answer

Adding Aurora reader instances (read replicas) and routing read queries to the reader endpoint offloads read traffic from the writer instance without altering application query patterns. Aurora reader endpoints automatically distribute read-only connections across all replicas, reducing latency on the writer while keeping writes on the writer instance. This directly addresses the 85% read-heavy workload without requiring application changes.

Exam trap

The trap here is that candidates often confuse Multi-AZ standby instances (which are passive and cannot serve reads) with Aurora reader replicas (which are active and can serve reads), leading them to incorrectly select Option C.

Why the other options are wrong

Increasing the writer instance size does not offload reads; it only scales the single writer instance, which still handles all read traffic and does not reduce read latency from high read concurrency.

In Aurora, a Multi-AZ standby (writer failover target) does not serve read traffic; it is only used for failover. To offload reads, you need dedicated reader instances with a separate reader endpoint.

Option D is wrong because it suggests using ElastiCache Redis with DynamoDB as the SQL data source, but the question specifies an Aurora PostgreSQL cluster. DynamoDB is a NoSQL database, not a SQL data source, and this approach would require significant application changes to query patterns, violating the constraint of not changing core query patterns.

When would these options actually be correct?

This option would be correct if the question stated that the cluster is CPU-bound on the writer due to a mix of reads and writes, and the application cannot tolerate any read replica lag or connection routing changes, requiring a vertical scaling approach.

For a non-Aurora RDS database (e.g., RDS for MySQL or PostgreSQL) where you need high availability and want to offload read traffic to a standby, enabling Multi-AZ with the 'standby can serve reads' option (if supported) would be correct. The question would specify a single-instance RDS DB with Multi-AZ and the need to use the standby for reads.

This option would be correct in a scenario where the application uses a NoSQL database like DynamoDB as its primary data store, experiences high read traffic, and can tolerate eventual consistency. The team wants to offload reads without altering query patterns, and using ElastiCache Redis as a caching layer in front of DynamoDB would reduce read latency.

Why candidates pick the wrong answer

Candidates may think that a larger instance can handle more total throughput, overlooking that read replicas are specifically designed to offload read traffic and reduce latency for read-heavy workloads.

Candidates may confuse Aurora's Multi-AZ with RDS Multi-AZ, or incorrectly assume that a standby can handle read requests in normal operation, similar to read replicas.

Candidates may choose this option because they recognize that caching (ElastiCache) is a common solution for read-heavy workloads, and they might overlook the specific database type (Aurora PostgreSQL vs. DynamoDB) or assume that any caching layer can be seamlessly integrated without considering the underlying data store compatibility.

Full explanation →

SAA-C03 (SAA-C03) — Questions 226–300