Sample questions
SAA-C03 practice questions
A content publishing system 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 team wants the control to be enforceable during normal operations.
Trap 1: Lambda reserved concurrency set to zero
Reserved concurrency of zero stops processing and does not preserve failed events as an error-handling strategy.
Trap 2: A larger deployment package
Package size does not affect failed-event capture.
Trap 3: CloudFront error pages
CloudFront does not manage Lambda asynchronous retry failures.
- A
Lambda reserved concurrency set to zero
Why wrong: Reserved concurrency of zero stops processing and does not preserve failed events as an error-handling strategy.
- B
A larger deployment package
Why wrong: Package size does not affect failed-event capture.
- C
CloudFront error pages
Why wrong: CloudFront does not manage Lambda asynchronous retry failures.
- D
A Lambda dead-letter queue or failure destination
A DLQ or asynchronous failure destination captures failed events after retry attempts.
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.
Trap 1: Purchase an All Upfront Reserved Instance for the transcoding fleet…
Reserved Instances fit steady, predictable usage, but this batch fleet is interruption-tolerant and variable.
Trap 2: Increase the API instance size so CPU utilization stays below 30…
Larger instances raise cost; right sizing should reduce waste, not add extra unused capacity.
Trap 3: Move the API tier to Dedicated Hosts to improve isolation and lower…
Dedicated Hosts usually increase cost and are used for licensing or compliance, not savings.
- A
Purchase an All Upfront Reserved Instance for the transcoding fleet only.
Why wrong: Reserved Instances fit steady, predictable usage, but this batch fleet is interruption-tolerant and variable.
- B
Buy a Compute Savings Plan to cover the always-on API baseline usage.
Savings Plans reduce cost for consistent compute usage and are well suited to the always-on API.
- C
Run the transcoding fleet on Spot Instances because interrupted jobs can resume from checkpoints.
Spot Instances are ideal for flexible batch processing when interruptions are acceptable and checkpointing exists.
- D
Increase the API instance size so CPU utilization stays below 30 percent.
Why wrong: Larger instances raise cost; right sizing should reduce waste, not add extra unused capacity.
- E
Move the API tier to Dedicated Hosts to improve isolation and lower spend.
Why wrong: Dedicated Hosts usually increase cost and are used for licensing or compliance, not savings.
A warehouse integration service must use shared file storage across Linux EC2 instances in multiple Availability Zones. The storage must remain available during an AZ failure. Which service should be used? The architecture review board prefers a managed AWS-native control.
Trap 1: S3 mounted as a POSIX file system without a file gateway
S3 is object storage and does not provide native POSIX shared file semantics.
Trap 2: Instance store volumes
Instance store is ephemeral and tied to a single instance.
Trap 3: An EBS volume attached to all instances
A standard EBS volume is zonal and cannot be attached broadly as shared file storage.
- A
Amazon EFS with mount targets in multiple Availability Zones
EFS is regional file storage and supports mount targets across AZs.
- B
S3 mounted as a POSIX file system without a file gateway
Why wrong: S3 is object storage and does not provide native POSIX shared file semantics.
- C
Instance store volumes
Why wrong: Instance store is ephemeral and tied to a single instance.
- D
An EBS volume attached to all instances
Why wrong: A standard EBS volume is zonal and cannot be attached broadly as shared file storage.
A team runs a stateless web app on Amazon EC2 behind an Application Load Balancer. During traffic spikes, new EC2 instances take several minutes to finish bootstrapping before they can receive traffic. Which Auto Scaling configuration most directly reduces the time until additional capacity is available?
Trap 1: Increase the ALB target group deregistration delay.
Deregistration delay affects how long old instances stay in service during scale-in, not how quickly new instances become available.
Trap 2: Reduce the Auto Scaling group minimum size to one instance.
Lowering minimum capacity can reduce cost, but it does not make additional instances available faster during demand spikes.
Trap 3: Replace the Application Load Balancer with a Network Load Balancer.
A Network Load Balancer does not solve instance bootstrapping time and is not the main lever for faster scale-out readiness.
- A
Increase the ALB target group deregistration delay.
Why wrong: Deregistration delay affects how long old instances stay in service during scale-in, not how quickly new instances become available.
- B
Use an Auto Scaling warm pool so pre-initialized instances are ready to enter service.
Warm pools keep instances pre-launched and initialized, which reduces the time needed to add capacity during spikes.
- C
Reduce the Auto Scaling group minimum size to one instance.
Why wrong: Lowering minimum capacity can reduce cost, but it does not make additional instances available faster during demand spikes.
- D
Replace the Application Load Balancer with a Network Load Balancer.
Why wrong: A Network Load Balancer does not solve instance bootstrapping time and is not the main lever for faster scale-out readiness.
A service in private subnets downloads product images from Amazon S3 and stores job state in DynamoDB. A NAT Gateway is currently the only route to AWS services, and the monthly bill is dominated by NAT data processing charges. Which two changes will most directly reduce that cost? Select two.
Trap 1: Add an internet gateway and move the instances into public subnets.
This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.
Trap 2: Replace the NAT Gateway with a Site-to-Site VPN connection.
A VPN is meant for connectivity to on-premises or external networks. It does not eliminate the need to reach S3 and DynamoDB privately, so it does not directly solve the NAT data-processing-cost problem.
Trap 3: Create an interface endpoint for S3 instead of a gateway endpoint.
An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.
- A
Create a gateway VPC endpoint for Amazon S3.
An S3 gateway endpoint routes S3 traffic over the AWS private network instead of through the NAT Gateway. That removes NAT data processing charges for the S3 downloads and is one of the most direct cost optimizations for private-subnet workloads.
- B
Create a gateway VPC endpoint for Amazon DynamoDB.
DynamoDB also supports a gateway endpoint, which keeps table traffic off the NAT Gateway path. Using the endpoint avoids both NAT data processing fees and the need to hairpin private AWS API calls through internet egress.
- C
Add an internet gateway and move the instances into public subnets.
Why wrong: This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.
- D
Replace the NAT Gateway with a Site-to-Site VPN connection.
Why wrong: A VPN is meant for connectivity to on-premises or external networks. It does not eliminate the need to reach S3 and DynamoDB privately, so it does not directly solve the NAT data-processing-cost problem.
- E
Create an interface endpoint for S3 instead of a gateway endpoint.
Why wrong: An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.
A static site is hosted in Amazon S3 and delivered by CloudFront. After a frontend release, the same JavaScript bundles are fetched repeatedly from the origin. Logs show that requests include unneeded query strings and cookies, which prevent cache reuse. Which two changes should the team make to reduce origin traffic and cost? Select two.
Trap 1: Increase the size of the S3 bucket.
Bucket size does not improve cache reuse or reduce request costs. The issue is cacheability, not storage capacity.
Trap 2: Place an Application Load Balancer in front of S3.
An ALB is not used as a front end for static S3 content in this pattern. It adds unnecessary infrastructure and does not address the cache key problem.
Trap 3: Disable caching so clients always get the latest files.
Disabling caching guarantees more origin traffic and higher cost. The deployment already uses versioned assets, so cache efficiency should increase rather than disappear.
- A
Configure a CloudFront cache policy that forwards only the query strings, headers, and cookies the app actually needs.
Reducing the cache key to only required values increases cache hit ratio and lowers origin fetches. CloudFront can reuse responses more effectively when unnecessary request data is not forwarded.
- B
Use versioned file names for static assets and set a long TTL for immutable objects.
Versioned filenames let you cache assets aggressively without risking stale content after deployments. Long TTLs reduce repeated origin requests and lower both transfer and request costs.
- C
Increase the size of the S3 bucket.
Why wrong: Bucket size does not improve cache reuse or reduce request costs. The issue is cacheability, not storage capacity.
- D
Place an Application Load Balancer in front of S3.
Why wrong: An ALB is not used as a front end for static S3 content in this pattern. It adds unnecessary infrastructure and does not address the cache key problem.
- E
Disable caching so clients always get the latest files.
Why wrong: Disabling caching guarantees more origin traffic and higher cost. The deployment already uses versioned assets, so cache efficiency should increase rather than disappear.
A static website uses an Amazon S3 bucket as the origin for an Amazon CloudFront distribution. The team accidentally configured the S3 bucket policy to allow s3:GetObject to Principal "*", so objects are accessible via direct S3 URLs. They want to ensure objects are retrievable only through CloudFront. What is the best corrective action?
Trap 1: Enable S3 static website hosting and disable CloudFront, because…
S3 website hosting often requires specific configuration and does not inherently provide origin-only access controls for security.
Trap 2: Add a WAF rule that rate-limits requests to the S3 bucket domain to…
WAF typically applies at CloudFront/web front ends; rate limiting does not provide guaranteed access restriction at the bucket.
Trap 3: Turn on S3 object versioning so that attackers cannot read previous…
Versioning affects recovery and deletion semantics, not whether objects are publicly readable via S3.
- A
Remove public access from the bucket and update the bucket policy to allow GetObject only from CloudFront using the distribution’s SourceArn (and use CloudFront origin access control or origin access identity).
Restricting the bucket policy to CloudFront’s principal with a SourceArn condition prevents direct S3 access while enabling CloudFront.
- B
Enable S3 static website hosting and disable CloudFront, because website hosting blocks direct object URL access.
Why wrong: S3 website hosting often requires specific configuration and does not inherently provide origin-only access controls for security.
- C
Add a WAF rule that rate-limits requests to the S3 bucket domain to make direct access impractical.
Why wrong: WAF typically applies at CloudFront/web front ends; rate limiting does not provide guaranteed access restriction at the bucket.
- D
Turn on S3 object versioning so that attackers cannot read previous objects.
Why wrong: Versioning affects recovery and deletion semantics, not whether objects are publicly readable via S3.
A service processes messages from an Amazon SQS queue. Sometimes the worker finishes the business logic but does not delete the message before the visibility timeout expires, so the message is delivered again. Which two changes improve resilience and reduce the impact of duplicate processing? Select two.
Trap 1: Switch from SQS to Amazon SNS for reliable buffering.
SNS is a pub/sub notification service, not a durable work queue for buffering and retrying tasks. It does not provide the same queue semantics as SQS for worker processing.
Trap 2: Shorten the queue retention period so messages expire quickly.
Reducing retention does not prevent duplicates. It increases the chance of message loss if workers are unavailable long enough for messages to expire before processing completes.
Trap 3: Disable retries in the consumer application.
Retries are often necessary for transient failures such as throttling or brief downstream outages. Disabling retries makes the system less resilient and can turn temporary problems into permanent data loss.
- A
Make the message handler idempotent.
SQS provides at-least-once delivery, so the same message can be seen more than once. An idempotent handler ensures a repeated delivery does not create duplicate records, duplicate payments, or other repeated side effects.
- B
Set the SQS visibility timeout long enough for normal processing to complete.
If the visibility timeout is too short, a message can become visible again before the first worker finishes and deletes it. Choosing a timeout that comfortably exceeds normal processing time lowers accidental redelivery.
- C
Switch from SQS to Amazon SNS for reliable buffering.
Why wrong: SNS is a pub/sub notification service, not a durable work queue for buffering and retrying tasks. It does not provide the same queue semantics as SQS for worker processing.
- D
Shorten the queue retention period so messages expire quickly.
Why wrong: Reducing retention does not prevent duplicates. It increases the chance of message loss if workers are unavailable long enough for messages to expire before processing completes.
- E
Disable retries in the consumer application.
Why wrong: Retries are often necessary for transient failures such as throttling or brief downstream outages. Disabling retries makes the system less resilient and can turn temporary problems into permanent data loss.
A SaaS vendor’s automation account in Account B needs to assume a role in a customer account in Account A to read a specific S3 bucket and publish a deployment status file. The customer is worried about confused deputy attacks because multiple customers use the same vendor software. Which trust-policy design best meets the requirement?
Trap 1: Allow the Account B root principal to assume the role if the caller…
This would work technically, but it is far too broad and does not protect against confused deputy abuse. Any principal in Account B that can reach the role could potentially use it, which violates the customer’s security requirement.
Trap 2: Attach a permissions boundary to the role so that the vendor cannot…
A permissions boundary limits what permissions the role can have after it is assumed, but it does not stop an unintended principal from assuming the role. It addresses privilege scope, not confused deputy risk.
Trap 3: Require MFA for the role assumption because it ensures only the…
MFA is not a practical control for non-human automation and does not solve cross-account confused deputy risk. The vendor’s automation should use a trust policy with a specific principal and an ExternalId instead.
- A
Allow the Account B root principal to assume the role if the caller knows the role ARN.
Why wrong: This would work technically, but it is far too broad and does not protect against confused deputy abuse. Any principal in Account B that can reach the role could potentially use it, which violates the customer’s security requirement.
- B
Allow only the vendor’s specific IAM principal to assume the role and require a unique sts:ExternalId condition.
This is the standard confused deputy protection pattern for third-party cross-account access. The trust policy limits who can call AssumeRole, and the sts:ExternalId condition lets the customer require a customer-specific value that the vendor must supply. That prevents another customer or a malicious party from reusing the same role ARN successfully.
- C
Attach a permissions boundary to the role so that the vendor cannot exceed the approved permissions.
Why wrong: A permissions boundary limits what permissions the role can have after it is assumed, but it does not stop an unintended principal from assuming the role. It addresses privilege scope, not confused deputy risk.
- D
Require MFA for the role assumption because it ensures only the vendor’s production automation can use the role.
Why wrong: MFA is not a practical control for non-human automation and does not solve cross-account confused deputy risk. The vendor’s automation should use a trust policy with a specific principal and an ExternalId instead.
A single EC2 instance hosts a low-latency database cache that writes a large random working set to block storage. The application needs sustained high IOPS and low latency, and the storage must remain attached to the instance while it runs. Which two design choices best meet the requirement? Select two.
Trap 1: Use an S3 bucket as the backing store because object storage scales…
S3 is object storage, not block storage. It does not provide the low-latency random write behavior required by a database cache or similar block-based workload.
Trap 2: Choose a cold HDD-based volume so the cache has durable low-cost…
Cold HDD volumes are optimized for low cost, not for high IOPS or latency-sensitive random access. They are a poor fit for a cache or database-like workload.
Trap 3: Use the root volume from a T-series instance because burst credits…
Burst credits do not provide the sustained, predictable IOPS needed for a latency-sensitive cache. T-series instances are designed for short CPU bursts, not for high-performance storage workloads.
- A
Use an io2 Block Express EBS volume for the highest sustained IOPS and low-latency performance.
io2 Block Express is designed for demanding block-storage workloads that need very high, consistent IOPS with low latency. It is a strong fit when the data must remain on attached EBS storage rather than on ephemeral instance store.
- B
Stripe multiple EBS volumes together with RAID 0 to increase aggregate IOPS and throughput.
RAID 0 across EBS volumes is a standard way to scale performance when a single volume cannot meet the required IOPS or throughput. It improves aggregate performance, but the application must tolerate the fact that RAID 0 increases the failure domain.
- C
Use an S3 bucket as the backing store because object storage scales automatically.
Why wrong: S3 is object storage, not block storage. It does not provide the low-latency random write behavior required by a database cache or similar block-based workload.
- D
Choose a cold HDD-based volume so the cache has durable low-cost storage.
Why wrong: Cold HDD volumes are optimized for low cost, not for high IOPS or latency-sensitive random access. They are a poor fit for a cache or database-like workload.
- E
Use the root volume from a T-series instance because burst credits can absorb the write spikes.
Why wrong: Burst credits do not provide the sustained, predictable IOPS needed for a latency-sensitive cache. T-series instances are designed for short CPU bursts, not for high-performance storage workloads.
A serverless checkout API uses AWS Lambda behind API Gateway. Every weekday at 09:00 UTC, marketing triggers a predictable surge. The first few minutes after each surge show cold-start latency, but traffic volume is forecastable and the business wants stable p95 latency. Which two changes should the team implement? Select two.
Trap 1: Increase the Lambda timeout so the function has more time to…
A longer timeout does not remove cold starts or pre-initialize execution environments. It only changes how long a function may run before timing out. The user-facing latency issue would remain, so this does not solve the core problem.
Trap 2: Double the memory size during the spike without changing the…
More memory can improve CPU allocation and sometimes reduce execution duration, but it does not guarantee that the environment is already warm. Without provisioned concurrency, the first requests can still incur cold-start penalties. The scenario specifically calls for stable p95 latency.
Trap 3: Move the function into more Availability Zones so the platform can…
Lambda already runs as a managed regional service and does not need the customer to place individual functions across AZs. Spreading across AZs does not eliminate cold starts. The issue is initialization time, not geographic distribution.
- A
Publish a Lambda version and attach provisioned concurrency to an alias that points to that version.
Provisioned concurrency keeps execution environments initialized and ready to serve requests, which is the correct way to reduce cold starts. Using an alias tied to a published version is the standard deployment pattern for managing that setting safely. This directly improves p95 latency during predictable bursts.
- B
Use Application Auto Scaling scheduled actions to raise provisioned concurrency before 09:00 UTC and lower it afterward.
Because the traffic spike is predictable, scheduled scaling lets the team pre-warm enough Lambda capacity before the busy period begins. Scaling down later avoids paying for unused concurrency for the entire day. This is both performant and cost-aware for a known recurring pattern.
- C
Increase the Lambda timeout so the function has more time to initialize during the spike.
Why wrong: A longer timeout does not remove cold starts or pre-initialize execution environments. It only changes how long a function may run before timing out. The user-facing latency issue would remain, so this does not solve the core problem.
- D
Double the memory size during the spike without changing the concurrency model.
Why wrong: More memory can improve CPU allocation and sometimes reduce execution duration, but it does not guarantee that the environment is already warm. Without provisioned concurrency, the first requests can still incur cold-start penalties. The scenario specifically calls for stable p95 latency.
- E
Move the function into more Availability Zones so the platform can spread cold starts across regions.
Why wrong: Lambda already runs as a managed regional service and does not need the customer to place individual functions across AZs. Spreading across AZs does not eliminate cold starts. The issue is initialization time, not geographic distribution.
A system processes events from Amazon SQS and sometimes sees duplicate messages due to retries. The business requirement is that each payment must be charged at most once. What design choice best addresses this resiliency requirement?
Trap 1: Assume duplicates never occur because the consumer deletes messages…
With SQS at-least-once delivery, duplicates can still occur if processing fails, times out, or crashes before the delete occurs. Even if you delete quickly after receiving, failures after the side effect can still lead to duplicates being delivered later.
Trap 2: Increase the SQS visibility timeout until duplicates never happen.
Changing visibility timeout only affects when messages are retried. It does not change SQS’s delivery semantics or guarantee that duplicates will never be delivered, nor does it prevent duplicate side effects from being executed.
Trap 3: Use SNS topics instead of SQS so retries are disabled by default.
Switching to SNS does not guarantee exactly-once processing for downstream systems. Duplicate notifications and retries can still occur due to delivery failures and subscriber behavior, so idempotency is still required to enforce at-most-once charging.
- A
Assume duplicates never occur because the consumer deletes messages immediately after receiving them.
Why wrong: With SQS at-least-once delivery, duplicates can still occur if processing fails, times out, or crashes before the delete occurs. Even if you delete quickly after receiving, failures after the side effect can still lead to duplicates being delivered later.
- B
Implement idempotent processing using a deduplication key (for example, paymentId) and record completed charges so duplicates are safely ignored.
Idempotency ensures at-most-once side effects even when duplicates are delivered. Persist a record keyed by paymentId (e.g., a unique constraint/conditional write). If the record indicates the payment was already charged, skip the charge for any subsequent duplicate message.
- C
Increase the SQS visibility timeout until duplicates never happen.
Why wrong: Changing visibility timeout only affects when messages are retried. It does not change SQS’s delivery semantics or guarantee that duplicates will never be delivered, nor does it prevent duplicate side effects from being executed.
- D
Use SNS topics instead of SQS so retries are disabled by default.
Why wrong: Switching to SNS does not guarantee exactly-once processing for downstream systems. Duplicate notifications and retries can still occur due to delivery failures and subscriber behavior, so idempotency is still required to enforce at-most-once charging.
A warehouse integration service must process every event at least once, but duplicate processing is acceptable if the consumer handles idempotency. Which eventing approach is most suitable? The architecture review board prefers a managed AWS-native control.
Trap 1: Use CloudFront signed URLs
Signed URLs control content access and do not provide event delivery.
Trap 2: Use UDP messages sent directly to workers
UDP does not provide durable at-least-once delivery.
Trap 3: Use an in-memory queue on one EC2 instance
A single in-memory queue is not durable or highly available.
- A
Use CloudFront signed URLs
Why wrong: Signed URLs control content access and do not provide event delivery.
- B
Use Amazon SQS standard queue and design consumers to be idempotent
SQS standard queues provide at-least-once delivery and high throughput; consumers must handle occasional duplicates.
- C
Use UDP messages sent directly to workers
Why wrong: UDP does not provide durable at-least-once delivery.
- D
Use an in-memory queue on one EC2 instance
Why wrong: A single in-memory queue is not durable or highly available.
A system uses multiple AWS Lambda functions behind different event sources. One Lambda occasionally spikes and causes other Lambdas to be throttled due to shared concurrency limits. Which setting best helps ensure the important Lambda keeps capacity during spikes?
Trap 1: Increase the function timeout so throttling is less likely.
Timeout affects how long a request can run, not how many requests can run concurrently. Throttling is typically related to concurrency limits rather than time limits. Increasing timeout does not reserve capacity for another function.
Trap 2: Enable Provisioned Concurrency for every Lambda in the account.
Provisioned Concurrency is useful for reducing cold starts, but it is not primarily a mechanism to guarantee capacity against account-wide spikes. Applying it to every function increases cost. Reserved concurrency is the direct control for prioritizing concurrency capacity.
Trap 3: Reduce the number of IAM policies attached to the Lambda roles.
IAM policy count does not control Lambda concurrency throttling. Throttling behavior depends on concurrency limits, scaling, and provisioned settings. Reducing IAM complexity improves manageability, not runtime concurrency availability.
- A
Increase the function timeout so throttling is less likely.
Why wrong: Timeout affects how long a request can run, not how many requests can run concurrently. Throttling is typically related to concurrency limits rather than time limits. Increasing timeout does not reserve capacity for another function.
- B
Set Reserved Concurrency for the important Lambda function.
Reserved concurrency allocates a guaranteed amount of concurrent execution capacity to a specific Lambda. This prevents other functions from consuming all concurrency and throttling the important one. If the reserved limit is reached, only that function is throttled, isolating impact.
- C
Enable Provisioned Concurrency for every Lambda in the account.
Why wrong: Provisioned Concurrency is useful for reducing cold starts, but it is not primarily a mechanism to guarantee capacity against account-wide spikes. Applying it to every function increases cost. Reserved concurrency is the direct control for prioritizing concurrency capacity.
- D
Reduce the number of IAM policies attached to the Lambda roles.
Why wrong: IAM policy count does not control Lambda concurrency throttling. Throttling behavior depends on concurrency limits, scaling, and provisioned settings. Reducing IAM complexity improves manageability, not runtime concurrency availability.
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.
Trap 1: Place a NAT gateway in the public subnet so the private instances…
A NAT gateway sends outbound traffic to the internet and adds cost and exposure that the requirement explicitly forbids. It is not a private-only connectivity solution.
Trap 2: Assign public IPv4 addresses to the instances and restrict them…
Public IPs contradict the requirement to stay private and do not remove internet exposure. Security groups alone do not make a workload private.
Trap 3: Use VPC peering to the AWS service endpoints instead of VPC…
VPC peering is for connectivity between VPCs, not for reaching managed AWS service endpoints. It is not the right mechanism for private service access.
- A
Create an S3 gateway VPC endpoint and update the route tables for the private subnets.
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.
- B
Place a NAT gateway in the public subnet so the private instances can reach AWS services.
Why wrong: A NAT gateway sends outbound traffic to the internet and adds cost and exposure that the requirement explicitly forbids. It is not a private-only connectivity solution.
- C
Create an interface VPC endpoint for AWS Secrets Manager and allow the workload security group to reach it.
Secrets Manager uses an interface endpoint for private connectivity. This keeps API calls inside the AWS network and avoids the need for internet access or NAT.
- D
Assign public IPv4 addresses to the instances and restrict them with security groups.
Why wrong: Public IPs contradict the requirement to stay private and do not remove internet exposure. Security groups alone do not make a workload private.
- E
Use VPC peering to the AWS service endpoints instead of VPC endpoints.
Why wrong: VPC peering is for connectivity between VPCs, not for reaching managed AWS service endpoints. It is not the right mechanism for private service access.
A solutions architect is designing an S3 bucket for a IoT ingestion API. The objects must never be publicly accessible, even if a developer later adds an overly broad bucket policy. What should the architect configure? The design must avoid adding custom operational scripts.
Trap 1: Enable S3 Transfer Acceleration
Transfer Acceleration improves upload performance but does not enforce private access.
Trap 2: Create an IAM policy that denies s3:GetObject to anonymous users
An IAM policy alone does not protect against every public ACL or bucket policy mistake.
Trap 3: Enable server access logging on the bucket
Access logging records requests but does not prevent public exposure.
- A
Enable S3 Transfer Acceleration
Why wrong: Transfer Acceleration improves upload performance but does not enforce private access.
- B
Create an IAM policy that denies s3:GetObject to anonymous users
Why wrong: An IAM policy alone does not protect against every public ACL or bucket policy mistake.
- C
Enable S3 Block Public Access at the account or bucket level
S3 Block Public Access prevents public ACLs and public bucket policies from exposing the bucket.
- D
Enable server access logging on the bucket
Why wrong: Access logging records requests but does not prevent public exposure.
A team wants to delegate IAM management to developers, but must ensure developers can never grant themselves permissions beyond a specific limit. Which AWS mechanism best matches this requirement?
Trap 1: Rely only on their IAM managed policies and instruct developers to…
Guidelines and self-checks are not enforceable controls. Developers could accidentally (or intentionally) attach policies that exceed the intended maximum permissions.
Trap 2: Use a service control policy (SCP) that applies only to the…
SCPs are evaluated at the organization/account level and constrain allowed API actions for principal types across affected accounts/OUs. They are not the most direct tool for capping an individual principal’s maximum effective permissions in the way permission boundaries do (and SCPs are not designed for per-identity “maximum permission” limits).
Trap 3: Use a KMS key policy to restrict IAM actions, because IAM actions…
KMS key policies govern cryptographic key usage (for example, Encrypt/Decrypt) and do not control whether a principal is authorized to grant or perform IAM permissions. KMS does not function as an IAM permissions cap mechanism.
- A
Use an IAM permission boundary on roles/users that developers create, so the developers’ effective permissions are capped by the boundary policy.
Permission boundaries constrain the maximum permissions that an identity can receive. Even if developers attach an identity policy that allows broader actions, the effective permissions are limited to the intersection of the identity policy and the boundary.
- B
Rely only on their IAM managed policies and instruct developers to self-check against internal guidelines.
Why wrong: Guidelines and self-checks are not enforceable controls. Developers could accidentally (or intentionally) attach policies that exceed the intended maximum permissions.
- C
Use a service control policy (SCP) that applies only to the developers’ IAM users in the account.
Why wrong: SCPs are evaluated at the organization/account level and constrain allowed API actions for principal types across affected accounts/OUs. They are not the most direct tool for capping an individual principal’s maximum effective permissions in the way permission boundaries do (and SCPs are not designed for per-identity “maximum permission” limits).
- D
Use a KMS key policy to restrict IAM actions, because IAM actions can be controlled with KMS.
Why wrong: KMS key policies govern cryptographic key usage (for example, Encrypt/Decrypt) and do not control whether a principal is authorized to grant or perform IAM permissions. KMS does not function as an IAM permissions cap mechanism.
A solutions architect is designing an S3 bucket for a healthcare document service. The objects must never be publicly accessible, even if a developer later adds an overly broad bucket policy. What should the architect configure?
Trap 1: Enable server access logging on the bucket
Access logging records requests but does not prevent public exposure.
Trap 2: Enable S3 Transfer Acceleration
Transfer Acceleration improves upload performance but does not enforce private access.
Trap 3: Create an IAM policy that denies s3:GetObject to anonymous users
An IAM policy alone does not protect against every public ACL or bucket policy mistake.
- A
Enable server access logging on the bucket
Why wrong: Access logging records requests but does not prevent public exposure.
- B
Enable S3 Transfer Acceleration
Why wrong: Transfer Acceleration improves upload performance but does not enforce private access.
- C
Create an IAM policy that denies s3:GetObject to anonymous users
Why wrong: An IAM policy alone does not protect against every public ACL or bucket policy mistake.
- D
Enable S3 Block Public Access at the account or bucket level
S3 Block Public Access prevents public ACLs and public bucket policies from exposing the bucket.
A solutions architect is designing an S3 bucket for a claims portal. The objects must never be publicly accessible, even if a developer later adds an overly broad bucket policy. What should the architect configure? The design must avoid adding custom operational scripts.
Trap 1: Create an IAM policy that denies s3:GetObject to anonymous users
An IAM policy alone does not protect against every public ACL or bucket policy mistake.
Trap 2: Enable server access logging on the bucket
Access logging records requests but does not prevent public exposure.
Trap 3: Enable S3 Transfer Acceleration
Transfer Acceleration improves upload performance but does not enforce private access.
- A
Enable S3 Block Public Access at the account or bucket level
S3 Block Public Access prevents public ACLs and public bucket policies from exposing the bucket.
- B
Create an IAM policy that denies s3:GetObject to anonymous users
Why wrong: An IAM policy alone does not protect against every public ACL or bucket policy mistake.
- C
Enable server access logging on the bucket
Why wrong: Access logging records requests but does not prevent public exposure.
- D
Enable S3 Transfer Acceleration
Why wrong: Transfer Acceleration improves upload performance but does not enforce private access.
You want to protect an Application Load Balancer (ALB) from common web exploits using AWS WAF. The application is not using CloudFront. Which AWS WAF deployment scope should you choose so the WAF rules apply to the ALB?
Trap 1: Use AWS WAF CloudFront (global) scope and associate the web ACL…
CloudFront scope is designed for CloudFront distributions. ALB traffic is handled by regional WAF, not the CloudFront (global) scope, so this association path would not provide the intended protection.
Trap 2: Use AWS Shield Advanced and rely on it to inspect payloads for SQL…
Shield Advanced primarily focuses on DDoS protection. AWS WAF provides rule-based inspection and blocking of application-layer threats such as SQL injection and XSS via managed rules/custom rules.
Trap 3: Use security groups only, because they can detect SQL injection…
Security groups control network traffic (protocols/ports/IPs). They do not inspect HTTP payload content, so they cannot detect and block application-layer exploit patterns like SQL injection or XSS.
- A
Use AWS WAF regional scope (associate the web ACL with the ALB resource)
ALBs are regional resources. When you protect an ALB without CloudFront, you should use the regional WAF scope and associate the web ACL directly with the ALB, so WAF can inspect incoming requests destined for that ALB.
- B
Use AWS WAF CloudFront (global) scope and associate the web ACL with the ALB
Why wrong: CloudFront scope is designed for CloudFront distributions. ALB traffic is handled by regional WAF, not the CloudFront (global) scope, so this association path would not provide the intended protection.
- C
Use AWS Shield Advanced and rely on it to inspect payloads for SQL injection and XSS
Why wrong: Shield Advanced primarily focuses on DDoS protection. AWS WAF provides rule-based inspection and blocking of application-layer threats such as SQL injection and XSS via managed rules/custom rules.
- D
Use security groups only, because they can detect SQL injection patterns in HTTP requests
Why wrong: Security groups control network traffic (protocols/ports/IPs). They do not inspect HTTP payload content, so they cannot detect and block application-layer exploit patterns like SQL injection or XSS.
A studio keeps 4 PB of completed video projects in Amazon S3. Editors work on active projects for about 60 days, auditors occasionally review the same objects for several months, and legal policy requires retention for 7 years. Retrieval of very old files can take hours. Which three actions should the architect recommend? Select three.
Trap 1: Keep the files in S3 Standard indefinitely so retrieval is always…
S3 Standard provides fast access, but it is unnecessarily expensive for multi-year retention of footage that is rarely needed.
Trap 2: Copy the files to a single EBS volume for lower per-GB cost.
EBS is block storage and is not suitable for massive archival libraries with lifecycle and retention requirements like these.
- A
Transition objects to S3 Standard-IA after 60 days.
Standard-IA is a good fit after the active editing window because the objects are accessed less often but still need relatively quick retrieval.
- B
Transition objects to S3 Glacier Deep Archive after the review period ends.
Deep Archive minimizes long-term storage spend when the oldest footage can tolerate hour-scale retrieval, exactly as stated in the scenario.
- C
Expire objects after 7 years.
Lifecycle expiration at the end of the legal retention window stops unnecessary storage charges after the policy requirement is satisfied.
- D
Keep the files in S3 Standard indefinitely so retrieval is always fast.
Why wrong: S3 Standard provides fast access, but it is unnecessarily expensive for multi-year retention of footage that is rarely needed.
- E
Copy the files to a single EBS volume for lower per-GB cost.
Why wrong: EBS is block storage and is not suitable for massive archival libraries with lifecycle and retention requirements like these.
A team runs a CPU-intensive image processing service on Amazon EC2. The service spends most of its time resizing and compressing images, and the team wants the best price-performance starting point for compute-heavy work. Which EC2 instance family should they choose?
Trap 1: Memory optimized instances
These are better when the workload is limited by RAM capacity, not CPU throughput.
Trap 2: Storage optimized instances
These are intended for very high sequential read or write throughput to local storage.
Trap 3: General purpose instances
These are balanced, but they are not the best first choice for heavy CPU processing.
- A
Memory optimized instances
Why wrong: These are better when the workload is limited by RAM capacity, not CPU throughput.
- B
Compute optimized instances
These instances are designed for workloads that need strong CPU performance and efficient compute price-performance.
- C
Storage optimized instances
Why wrong: These are intended for very high sequential read or write throughput to local storage.
- D
General purpose instances
Why wrong: These are balanced, but they are not the best first choice for heavy CPU processing.
A team needs a relational database solution that can automatically fail over to a standby instance if the primary database becomes unavailable. They want the standby to be located in a different Availability Zone. Which RDS/Aurora configuration best satisfies this requirement?
Trap 1: Single-AZ DB deployment and rely on manual snapshot restore during…
Single-AZ deployments do not provide an always-on standby in another AZ. Manual snapshot restore is a recovery process that requires intervention and is typically not an automatic failover to an AZ-level standby.
Trap 2: Enable read replicas only, and promote a replica manually when the…
Read replicas are for scaling reads and do not provide the same high-availability failover behavior as Multi-AZ deployments. Manual promotion adds recovery time and does not meet the automatic failover requirement.
Trap 3: Enable point-in-time recovery (PITR) without configuring any…
PITR helps recover from logical mistakes (for example, accidental writes/deletes) by restoring data to an earlier time, but it does not provide an automatically available standby in another AZ for failover.
- A
Single-AZ DB deployment and rely on manual snapshot restore during failures.
Why wrong: Single-AZ deployments do not provide an always-on standby in another AZ. Manual snapshot restore is a recovery process that requires intervention and is typically not an automatic failover to an AZ-level standby.
- B
Multi-AZ deployment with an automatically managed standby in a different Availability Zone and automatic failover.
RDS/Aurora Multi-AZ deployments maintain a standby instance in a separate AZ. When configured for Multi-AZ, RDS/Aurora can perform automatic failover to the standby, meeting both the “different AZ” and “automatic failover” requirements.
- C
Enable read replicas only, and promote a replica manually when the primary fails.
Why wrong: Read replicas are for scaling reads and do not provide the same high-availability failover behavior as Multi-AZ deployments. Manual promotion adds recovery time and does not meet the automatic failover requirement.
- D
Enable point-in-time recovery (PITR) without configuring any Multi-AZ standby.
Why wrong: PITR helps recover from logical mistakes (for example, accidental writes/deletes) by restoring data to an earlier time, but it does not provide an automatically available standby in another AZ for failover.
A startup expects steady compute usage around the clock for the next year. They want to reduce costs compared to On-Demand pricing, without tightly planning specific instance types. Which option best matches their goal?
Trap 1: Purchase a Reserved Instance that must be tied to exactly one…
Reserved Instances typically require commitment to attributes like instance family/operating system/tenancy, which limits flexibility. The statement that they must be tied to exactly one instance size with no flexibility is not the key distinction; more importantly, Savings Plans are generally more flexible across instance types than many Reserved Instance choices.
Trap 2: Only use Spot Instances and set the workload to stop immediately if…
Spot can reduce cost, but it is not aligned with a steady 24/7 usage expectation if the workload cannot tolerate interruptions or forced stops.
Trap 3: Rely on On-Demand pricing and add more alarms to detect when costs…
Monitoring and alarms help detect cost changes, but they do not reduce the underlying On-Demand pricing charges.
- A
Purchase a Compute Savings Plan to receive discounted rates for a usage amount over a 1-year term.
Compute Savings Plans provide discounted EC2 usage (and related compute usage) versus On-Demand for a committed amount per hour. They are not limited to a single instance type, so the team can change instance families while staying within the committed usage.
- B
Purchase a Reserved Instance that must be tied to exactly one specific instance size (no flexibility to switch instance families).
Why wrong: Reserved Instances typically require commitment to attributes like instance family/operating system/tenancy, which limits flexibility. The statement that they must be tied to exactly one instance size with no flexibility is not the key distinction; more importantly, Savings Plans are generally more flexible across instance types than many Reserved Instance choices.
- C
Only use Spot Instances and set the workload to stop immediately if capacity is interrupted.
Why wrong: Spot can reduce cost, but it is not aligned with a steady 24/7 usage expectation if the workload cannot tolerate interruptions or forced stops.
- D
Rely on On-Demand pricing and add more alarms to detect when costs spike.
Why wrong: Monitoring and alarms help detect cost changes, but they do not reduce the underlying On-Demand pricing charges.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.