Amazon Web Services · Free Practice Questions · Last reviewed May 2026
24real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.
30% of exam · 6 sample questions below
A Lambda function needs to read the current value of exactly one AWS Secrets Manager secret at startup. Which least-privilege IAM permission (action and resource scope) should you grant to the Lambda execution role?
secretsmanager:ListSecrets on all secrets (resource set to "*")
secretsmanager:GetSecretValue on only the secret’s full ARN
GetSecretValue is the only AWS Secrets Manager API action that returns the encrypted secret's decrypted string, which is exactly what the Lambda function must read. By restricting the Action to secretsmanager:GetSecretValue and the Resource to the secret's full ARN, the IAM policy grants access to that single secret while denying all other Secrets Manager operations. This follows least privilege because the function cannot update, list, or describe any other secret, and the full ARN is more precise than using a wildcard or partial name.
secretsmanager:UpdateSecret on the specific secret ARN
secretsmanager:DescribeSecret on all secrets (resource set to "*")
A security team requires that every object uploaded to s3://secure-bucket/uploads/ must be encrypted using SSE-KMS with a specific customer-managed KMS key. Which S3 bucket policy condition approach best enforces this requirement for PutObject requests?
Deny PutObject unless s3:x-amz-server-side-encryption equals "aws:kms" and s3:x-amz-server-side-encryption-aws-kms-key-id equals the required CMK ARN
This enforces the encryption choice at upload time by validating the request headers that specify SSE-KMS and the exact KMS key ID/ARN. Using a Deny condition ensures uploads that do not include the correct SSE-KMS headers (for example, unencrypted uploads or uploads using a different KMS key) are rejected immediately.
Allow PutObject only when aws:SecureTransport is true; encryption is then guaranteed automatically
Deny PutObject if the request includes Content-Type other than "application/octet-stream"
Deny PutObject when the caller’s role is not allowed to kms:Decrypt in their IAM policy
An application in Account B (IAM role arn:aws:iam::account-b:role/app-read) reads objects from an S3 bucket in Account A. The bucket uses SSE-KMS with a customer-managed KMS key in Account A. Object reads consistently fail with an error that includes "AccessDenied" and "kms:Decrypt".
The IAM permissions in Account B for kms:Decrypt are correct, but the requests still fail.
Which change will most directly fix the failure?
Add kms:Decrypt to the KMS key policy in Account A for the Account B role arn:aws:iam::account-b:role/app-read, and remove kms:Decrypt from the role policy in Account B.
Update the IAM role in Account B to use the s3:GetObject permission only, and rely on S3 to authorize KMS decrypt automatically.
Modify the KMS key policy in Account A to allow kms:Decrypt for the Account B role arn:aws:iam::account-b:role/app-read, using the appropriate cross-account conditions (for example, allowing the use via S3 and the expected encryption context for the bucket).
For SSE-KMS, S3 must call KMS Decrypt when serving objects. KMS authorization is evaluated against the KMS key policy in Account A in addition to the identity policy in Account B. If the error includes kms:Decrypt AccessDenied in a cross-account scenario, the most direct fix is to update the KMS key policy to allow the Account B role to use the key for decrypt (often with conditions tied to S3 usage and the specific bucket/object encryption context).
Switch the S3 bucket encryption from SSE-KMS to SSE-S3, keeping all existing IAM and KMS configuration unchanged.
A server assumes an IAM role and must read export objects only from this prefix in an S3 bucket: s3://customer-data/exports/acme/ . The application also needs to list the objects under that exact prefix so it can discover which export folders exist. The application performs ListBucket requests with Prefix set to exactly "exports/acme/".
The current role policy allows s3:ListBucket on the bucket ARN without a prefix condition, and security reports the role can list other tenants’ export object keys.
Which IAM policy change best enforces least privilege for both ListBucket and GetObject?
Keep s3:ListBucket allowed on arn:aws:s3:::customer-data, but restrict s3:GetObject to arn:aws:s3:::customer-data/exports/acme/*.
Allow s3:ListBucket on arn:aws:s3:::customer-data only when s3:prefix equals "exports/acme/" (for example, using a StringEquals condition on s3:prefix). Also allow s3:GetObject only on arn:aws:s3:::customer-data/exports/acme/*.
ListBucket must be authorized at the bucket ARN level, then scoped using a Condition on the request prefix (so only the approved listing prefix is allowed). GetObject is authorized at the object ARN level and is restricted to exports/acme/*, preventing reads outside the prefix.
Allow s3:ListBucket only on arn:aws:s3:::customer-data/exports/acme/* and allow s3:GetObject on arn:aws:s3:::customer-data/*.
Add a Deny statement for s3:GetObject outside arn:aws:s3:::customer-data/exports/acme/*, but keep s3:ListBucket unrestricted on arn:aws:s3:::customer-data.
A company serves private images stored in S3 through Amazon CloudFront. Only authenticated users should be able to access each image, and access should expire after 1 hour. Which CloudFront feature best meets this requirement?
Signed URLs or signed cookies with an expiration time of 1 hour
Signed URLs or signed cookies are the native CloudFront authorization mechanism for restricting access to private content. Each signature is generated with a CloudFront key pair and embeds an expiration timestamp via a canned or custom policy; when a request arrives, edge locations cryptographically verify both the signature and the expiration field before forwarding the request to the S3 origin through an origin access control (OAC). After the 1-hour window passes, CloudFront rejects the request with an HTTP 403 error at the edge, so the S3 bucket never needs to perform time-based authorization logic. Because the authentication is cryptographic and enforced independently at every CloudFront edge location, it provides exactly the desired time-limited, per-resource access control without exposing the bucket directly.
A WAF rule that blocks requests without valid JWTs, without using signed URLs
Turning on S3 bucket public access block, without any CloudFront viewer authentication
Enabling CloudFront geo restriction to allow only one country
A backend service uses an IAM role to read files from an S3 bucket. It must only read objects under s3://prod-reporting/incoming/ but currently receives AccessDenied (403) on GetObject for that prefix.
The role already has this statement: - Action: s3:ListBucket - Resource: arn:aws:s3:::prod-reporting
Which policy statement would most directly follow least privilege to allow only the required reads under the incoming prefix?
Allow only listing and reading with a single statement: Action = ["s3:*"], Resource = ["arn:aws:s3:::prod-reporting/incoming/*"].
Allow reads with a prefix-scoped statement: Action = ["s3:GetObject"], Resource = ["arn:aws:s3:::prod-reporting/incoming/*"].
This grants only the specific action s3:GetObject and scopes it to the exact prefix that the service needs. It aligns with least privilege by avoiding extra permissions like PutObject or DeleteObject. Since the service already has ListBucket, this completes the required read path for objects in incoming.
Allow all S3 reads at the account level: Action = ["s3:GetObject"], Resource = ["arn:aws:s3:::*"].
Allow bucket listing with a condition that forces the prefix: Action = ["s3:ListBucket"], Resource = ["arn:aws:s3:::prod-reporting"], Condition = {"StringLike": {"s3:prefix": "incoming/*"}}.
Want more Design Secure Architectures practice?
Practice this domain26% of exam · 6 sample questions below
An order-processing service consumes messages from an Amazon SQS Standard queue using a custom worker. During traffic spikes, the worker occasionally times out after performing some work but before acknowledging the message, so SQS redelivers it and it may be processed again.
You also observe that a small set of “poison” messages always fail validation.
What change most directly improves resilience by (1) preventing poison messages from retrying indefinitely and (2) avoiding duplicate side effects caused by legitimate retries?
Increase the SQS visibility timeout and, when validation fails, call DeleteMessage in the consumer to remove the message immediately.
Move to SNS topics with subscriptions and rely on SNS to provide exactly-once delivery to eliminate duplicates automatically.
Configure a dead-letter queue (DLQ) with a redrive policy that moves messages after maxReceiveCount, and implement idempotent processing in the consumer using an idempotency key.
SQS Standard is at-least-once delivery, so timeouts can cause redelivery and duplicates. A DLQ with a redrive policy prevents poison messages from retrying forever by moving them after repeated failures. Idempotent processing (for example, storing a processed marker in a database with conditional logic keyed by an idempotency key) prevents duplicate side effects when retries occur for valid messages.
Change the queue to FIFO and enable content-based deduplication, leaving the consumer logic unchanged.
Based on the exhibit, the application sees several minutes of connection errors during an Aurora failover. What is the best change to reduce failover impact?
Change the application to use the Aurora cluster writer endpoint and retry transient connections.
The current configuration targets a specific instance endpoint, which becomes stale after failover. The Aurora cluster writer endpoint always resolves to the current writer, so the application can reconnect without manual endpoint changes. Adding retries with backoff helps the application survive the short DNS and connection transition during failover.
Add an Aurora read replica and keep using the same JDBC URL.
Increase the EC2 instance size of the application servers.
Switch to a single-AZ RDS PostgreSQL instance for simpler connectivity.
A payments service receives payment orders by consuming messages from an Amazon SQS Standard queue. The downstream processor occasionally exceeds its processing timeout. As a result, some messages reappear in the queue and may be processed more than once.
The team wants to prevent duplicate side effects (for example, double-charging) and also ensure poison messages do not repeatedly consume processing capacity.
What approach best satisfies both goals?
Implement idempotent processing (for example, store processed payment IDs in DynamoDB) and configure an SQS dead-letter queue (DLQ) using a redrive policy with an appropriate maxReceiveCount.
With SQS Standard’s at-least-once delivery, duplicates can occur. Idempotency ensures repeated processing of the same payment ID does not create duplicate side effects. A DLQ with redrive policy isolates poison messages: after a message is received and fails processing more than maxReceiveCount times, SQS moves it to the DLQ instead of cycling it back to the main queue indefinitely.
Rely only on increasing the SQS visibility timeout so duplicates rarely occur, without adding idempotency checks or a DLQ.
Switch to a FIFO queue and delete messages immediately upon receipt to avoid duplicates.
Move the workload to SNS and use synchronous HTTP endpoints so the sender retries until the receiver confirms success.
A company runs an application behind an Application Load Balancer (ALB). An Auto Scaling group (ASG) is configured with desired capacity 2, but it is attached only to subnets in a single Availability Zone. The ALB is healthy because it is configured across multiple Availability Zones.
When the Availability Zone that contains the ASG subnets experiences an outage, what change most directly improves resilience and allows capacity to be restored automatically?
Update the ASG to use subnet IDs that span at least two Availability Zones so it can launch replacement instances after an AZ outage.
If the ASG is attached to subnets in multiple Availability Zones, when instances in the failed AZ become unhealthy/terminate, Auto Scaling can launch new instances in the remaining AZs to restore the desired capacity. This directly addresses the root cause: the ASG cannot create capacity outside the AZs it is configured for.
Reduce the ALB health check interval to speed up detection of unhealthy targets.
Enable connection draining on the ALB so existing requests complete before targets are terminated.
Increase the ASG desired capacity from 2 to 6 to compensate for the missing subnets.
Based on the exhibit, DNS still sends traffic to the primary Region even though Route 53 health checks show the primary endpoint is unhealthy. What is the best change to make failover work as intended?
Change both records to weighted routing with a 50/50 split so Route 53 can shift traffic gradually.
Use a failover routing policy with a primary record and a secondary record, and attach the health check to the primary record.
Failover routing is designed for active-passive DNS behavior. With a primary and secondary record, Route 53 answers with the primary record when it is healthy and returns the secondary record when the primary health check fails. The exhibit shows simple routing, which does not express the failover intent. Switching to failover routing aligns the DNS policy with the stated requirement.
Switch to latency-based routing so users are always directed to the lowest-latency Region.
Use geolocation routing so clients in one Region are sent to the healthier endpoint.
Based on the exhibit, the web application must remain available even if one Availability Zone fails. What is the best change to improve resilience with the least redesign?
Increase DesiredCapacity to 4 while keeping all instances in subnet-a1.
Add subnet-b1 in a different Availability Zone to the Auto Scaling group.
This spreads EC2 instances across two Availability Zones, so the Auto Scaling group can continue serving traffic if one AZ becomes unavailable. Because the ALB is already deployed in both subnets, this is the smallest change that adds true zonal resilience to the compute tier.
Replace the Application Load Balancer with a Network Load Balancer.
Enable EBS encryption on the launch template volumes.
Want more Design Resilient Architectures practice?
Practice this domain24% of exam · 6 sample questions below
An Aurora PostgreSQL application has an OLTP writer and a reporting dashboard that issues many read-only queries. The writer is healthy, but read latency rises noticeably during reporting windows. Which two changes should you make? Select two.
Add Aurora Replicas to scale out the read workload.
Aurora Replicas are independent compute instances in the same Aurora cluster that share the underlying storage volume. By adding one or more replicas, you create additional read endpoints that can absorb dashboard queries and other read-only traffic, directly offloading the writer instance. Because Aurora's storage is distributed and replicated separately, adding replicas does not cause significant write overhead, making horizontal read scaling the most efficient and cost-effective solution for an OLTP workload with heavy reads.
Send read-only application traffic to the reader endpoint.
The reader endpoint is a connection endpoint that load-balances across all available Aurora Replicas in the cluster. Directing read-only traffic such as the dashboard to this endpoint ensures that queries are spread across the replicas instead of hitting the writer instance. This reduces CPU and connection pressure on the writer, improving overall throughput and allowing write performance to remain stable, while the writer endpoint exclusively handles OLTP writes.
Scale up only the writer instance and keep all queries on it.
Replace the cluster with a single-AZ RDS instance to reduce replication overhead.
Move the dashboard to DynamoDB without changing the query model.
A production application writes to an Amazon Aurora PostgreSQL cluster. Users report that during business-hour reporting runs, write latency increases. The application team wants to keep the writer focused on OLTP writes while still providing low-latency reads for reporting queries. What architectural approach should the solutions architect recommend?
Create Aurora read replicas and direct reporting read-only connections to the cluster reader endpoint.
Aurora read replicas are separate DB instances that share the same underlying storage volume, so they serve read-only traffic without adding load to the writer. The cluster reader endpoint automatically load-balances connections across all replicas, allowing reporting queries to run in parallel with production writes. This decouples read and write workloads, reducing contention on the writer and improving overall responsiveness. It also lets you scale read capacity independently by adding or resizing replicas.
Resize the writer instance to a larger class so it can handle both writes and reads with fewer slowdowns.
Enable cross-region replication for the entire cluster so reporting always runs in the secondary Region.
Disable read replicas and use caching only in the application layer, keeping all queries connected to the writer endpoint.
A DynamoDB table stores device status items. The partition key is deviceId, and the partition distribution is healthy (no single partition dominates). However, during peak periods the application experiences high read latency because many clients repeatedly request the latest status for the same devices. Which action best improves read latency without changing the DynamoDB partitioning model?
Add Amazon DAX as a caching layer in front of DynamoDB and route repeated read operations through DAX.
Amazon DAX is an in-memory caching layer for DynamoDB that accelerates repeated reads. When many clients request the same items (for example, “latest status” point reads by deviceId), DAX can serve cached responses directly, reducing round trips to DynamoDB and lowering read latency during peak periods.
Change the partition key to a random value for each request to eliminate hot partitions.
Increase write capacity only, because writes generally determine read latency in DynamoDB.
Create an additional Global Secondary Index (GSI) and read exclusively from the index to accelerate reads.
An API team runs an AWS Lambda function behind an Application Load Balancer (ALB). During predictable hourly traffic spikes, p95 response latency increases due to occasional cold starts. The team wants stable latency during those spikes without permanently overprovisioning resources for all functions. Which configuration is the most appropriate way to reduce cold starts for this Lambda function?
Publish a version of the function and configure provisioned concurrency on an alias, using autoscaling for the alias.
Provisioned concurrency pre-initializes execution environments for a specific published function version. By attaching provisioned concurrency to an alias, you can control warm capacity and (with the right settings) autoscale the provisioned capacity for predictable spike patterns, reducing cold-start-driven latency increases.
Increase the function memory size and rely on faster initialization to reduce cold starts.
Set reserved concurrency equal to the expected peak requests per second for the function.
Use an event source mapping with a higher batch size so Lambda triggers earlier and keeps the runtime warm.
A Lambda function behind an API needs consistent low latency. Traffic normally drops to near zero, then spikes several times per hour. During spikes, the p95 latency often spikes above 800 ms due to cold starts. The team wants to keep using Lambda (no containers) but minimize cold start impact during predictable spikes. What is the best AWS configuration to meet this goal?
Enable Lambda provisioned concurrency on a published function alias and set the minimum provisioned instances to the baseline expected during spikes.
Provisioned concurrency pre-creates and initializes Lambda execution environments for a specific published alias or version, so requests are served immediately without a cold start. Setting the provisioned minimum to your baseline expected during spikes ensures that the required capacity is already warm and ready, maintaining consistent low latency under load. This is the correct, managed mechanism designed by AWS for this exact problem.
Increase the function memory size to the maximum and rely on the larger memory to eliminate cold starts.
Configure an ALB with target group health checks to keep Lambda warm by sending periodic requests.
Turn on AWS CloudTrail data events to monitor cold start frequency and tune the runtime accordingly.
A media processing service runs ECS tasks in multiple Availability Zones. Each task must read and write the same shared filesystem with low latency because tasks stream intermediate artifacts to other tasks. The team currently mounts an EBS volume per task, and cross-AZ tasks frequently cannot see each other’s files. Which option best resolves the shared filesystem requirement while supporting high-performing access?
Keep using EBS, but attach the same EBS volume to tasks in multiple Availability Zones using EBS multi-attach so all tasks share the filesystem.
Use Amazon EFS with mount targets in each Availability Zone so all tasks mount a common NFS filesystem over the AWS network.
EFS is designed for shared, NFS-like file storage that can be mounted concurrently from compute resources across multiple Availability Zones. By creating mount targets in each AZ used by the ECS tasks, you enable low-latency network access patterns so tasks can read and write the same shared filesystem reliably.
Use Amazon S3 for the intermediate artifacts and rely on S3 event notifications to emulate POSIX file operations.
Switch to instance store on each task and use SQS messages between tasks to copy intermediate artifacts.
Want more Design High-Performing Architectures practice?
Practice this domain20% of exam · 6 sample questions below
You store application logs in an S3 bucket. After 30 days, the logs are rarely accessed, but you must retain them for 1 year for compliance. Which S3 feature is the best way to reduce storage cost while meeting the retention requirement?
Create an S3 lifecycle rule to transition older objects to a colder storage class after 30 days, then expire after 1 year
S3 lifecycle policies can automatically transition objects to lower-cost storage classes based on age. Transitioning after 30 days reduces ongoing storage costs because the logs are rarely accessed, while expiring after 1 year ensures you still meet the compliance retention window.
Keep all logs in S3 Standard and rely on lower request rates to reduce cost
Copy logs to EBS snapshots each week and delete the original files
Use S3 replication to a second bucket in another region to reduce costs
CloudWatch metrics show your EC2 instances have average CPU utilization around 10% with stable performance over several weeks. The application does not require additional headroom right now. What is the most effective cost-optimization action?
Right-size the instances to a smaller size that matches the observed utilization
Right sizing reduces cost by matching instance capacity to actual demand. If average CPU is consistently low (around 10%) and performance is stable, it strongly indicates overprovisioning. Moving to a smaller instance (or a smaller capability within the same family) typically lowers hourly cost while maintaining sufficient capacity for the workload.
Increase the Auto Scaling desired capacity to add more instances
Switch to Spot Instances immediately even though interruptions would impact users
Disable detailed monitoring to reduce CPU usage from the monitoring agent
A marketing site serves versioned JavaScript and CSS files from Amazon S3 through CloudFront. The origin bill is rising because CloudFront keeps fetching the same files too often, and the application never changes a file at the same URL once it is published. Which two changes should you make? Select two.
Set long-lived Cache-Control headers, such as a high max-age and immutable policy, on the versioned assets.
Versioned assets are ideal for long cache lifetimes because their URLs change when the content changes. Strong Cache-Control headers let CloudFront serve more requests from edge locations instead of repeatedly fetching the same files from S3.
Configure the CloudFront cache policy to avoid forwarding unnecessary query strings, headers, and cookies.
A smaller cache key improves the cache hit rate because more viewer requests map to the same cached object. Avoiding unnecessary request attributes also reduces origin fetches and lowers the bandwidth sent to the origin.
Move the static assets to an EC2 web server behind an Application Load Balancer.
Disable CloudFront caching so every request always reaches the origin.
Add more viewer-facing headers to the cache key so each browser variation gets a unique cached object.
An application serves static images through Amazon CloudFront. The team observes higher-than-expected origin fetches, which increases origin bandwidth costs. Which change most directly improves CloudFront cache reuse to reduce origin requests for the static content?
Set appropriate Cache-Control headers (or origin cache settings) so CloudFront caches responses longer
Setting appropriate Cache-Control headers on the origin instructs CloudFront's edge locations to serve static images for a longer period without requesting them from S3. A longer TTL, such as a max-age of one year for immutable assets, increases the cache hit ratio and dramatically reduces the number of origin fetches. This directly lowers S3 request costs and reduces latency for end users.
Disable caching for the distribution so every request goes back to the origin
Configure CloudFront to forward all request headers and query strings to the origin
Move the S3 bucket to a different AWS Region, without changing CloudFront caching behavior
Your team runs a batch processing workload on EC2 that can tolerate interruptions. If an instance is terminated, the job can restart from checkpoints. To reduce compute costs, what is the most cost-optimized approach?
Use EC2 Spot Instances for the batch workers
Spot provides significantly lower pricing than On-Demand for interruptible workloads. Because the workload can restart from checkpoints, termination interruptions are acceptable and the application can recover efficiently, meeting both correctness and throughput requirements at a lower cost.
Use Dedicated Hosts to ensure capacity for the cheapest instance
Use On-Demand instances and schedule extra runs to offset interruptions
Use Reserved Instances only, because they eliminate instance termination events
A company has a steady, predictable workload that must run continuously (24/7) in a single AWS Region. The team wants the lowest cost option available for this steady usage, but also expects they may choose different EC2 instance families in the future (without re-buying compute discounts). Which AWS purchase option best meets these goals?
On-Demand Instances only, because they automatically adjust to future needs
Compute Savings Plans, committed for a 1- to 3-year term in the Region
Compute Savings Plans provide discounted pricing in exchange for committing to a consistent hourly spend (scoped to a Region). They apply to EC2 usage and are flexible enough that you can change EC2 instance families over time while still receiving the Savings Plans discount within the commitment scope.
Standard Reserved Instances tied to a single instance type and Availability Zone
EC2 Spot Instances, because they are always cheaper than savings programs
Want more Design Cost-Optimized Architectures practice?
Practice this domainThe SAA-C03 exam has 65 questions and must be completed in 130 minutes. The passing score is 720/1000.
Architecture scenario questions on AWS service selection, resilience, cost optimisation, security, and networking trade-offs.
The exam covers 4 domains: Design Secure Architectures, Design Resilient Architectures, Design High-Performing Architectures, Design Cost-Optimized Architectures. Questions are weighted by domain — higher-weight domains appear more on your actual exam.
No. These are original exam-style practice questions written against the official Amazon Web Services SAA-C03 exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.
Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.