SAA-C03 Sample Questions and Explanations

See exam objectives and study plan.

Q1/Security

An industrial IoT company has a VPC using 10.0.0.0/16. Each of its 40 factory OT networks also uses 10.0.0.0/16 and cannot be renumbered. The company wants to eliminate the large data-collection servers at each factory and use AWS-managed compute where possible, while retaining a lightweight gateway if needed. Which solution is most cost-optimized and avoids the overlapping CIDR conflict?

• A. Run the data collector as AWS IoT Greengrass Lambda functions on the factory gateways and publish preprocessed data to AWS IoT Core.✓
• B. Run the data collector on EC2 instances in a transit VPC that uses AWS Marketplace firewall appliances to NAT factory traffic into unique ranges.
• C. Run the data collector on EC2 instances in the VPC and connect every factory location to that VPC using an AWS Site-to-Site VPN.
• D. Run the data collector on EC2 instances in the VPC and connect each factory with an AWS Direct Connect private virtual interface.

This is correct because AWS IoT Greengrass runs Lambda functions on the factory gateway and communicates with AWS IoT Core over TLS, so it does not require layer-3 routing between the overlapping factory network and the VPC. The Site-to-Site VPN option is the strongest distractor: it is the standard way to connect a branch to AWS, but when the factory network and VPC both use 10.0.0.0/16, the route to that prefix is ambiguous and cannot be used without NAT or renumbering. The Direct Connect option fails for the same overlapping-prefix reason. The transit-VPC NAT option can be made to work, but it adds a second VPC and licensed firewall appliances, so it is not the most cost-optimized. General rule: when an existing network conflicts with a VPC CIDR, choose edge/message-based integration or add an explicit NAT boundary, then compare cost.

Q2/Cost

A research institute with a two-person DevOps team runs bursty genomic-analysis jobs. Each job is a container that reads one file from Amazon S3 and writes results back to S3. A single batch can include hundreds to thousands of independent jobs, and results can wait for hours. The team is willing to pay a little more to avoid cluster maintenance and custom job plumbing. Which approach gives the LEAST operational overhead?

• A. Run a custom job pipeline on Amazon ECS with Fargate tasks, an SQS queue for S3 object-created events, and retry logic in an application container.
• B. Create an Amazon EKS cluster with managed node groups, an SQS queue, and a custom controller that creates a Kubernetes Job for each S3 object.
• C. Configure AWS Batch with a Fargate compute environment, a job queue, and a job definition; submit one job for each S3 object.✓
• D. Maintain a persistent Auto Scaling group of EC2 Spot Instances; workers poll an SQS queue, run the container, and scale the group on queue depth.

This is correct because AWS Batch is a fully managed batch service: with a Fargate compute environment it also removes instance and cluster management, while the service handles job queueing, retries, and scaling. The strongest distractor is the custom ECS/Fargate pipeline: it avoids managing servers, but the team still has to build and operate the S3-to-SQS-to-task plumbing, retries, and job states. The EKS and EC2 Spot worker options require owning cluster, image, or scaling maintenance. General rule: for delay-tolerant, independent container jobs, the lowest operational overhead comes from the most managed service that natively fits the batch pattern, not from assembling the same pattern out of general-purpose AWS components.

Q3/Performance

A university research group collects small telemetry readings from 200 lab instruments, plus one high-resolution imager that produces a 3 MB TIFF image with every experiment. They need all data in Amazon S3 so AWS Glue can transform it into Parquet for Athena queries. Which ingestion solution meets the requirement with the least custom code?

• A. Put telemetry records and TIFF images in a standard SQS queue; a Lambda writes them to S3 and starts the Glue job for every object.
• B. Use Firehose for telemetry and images; turn on Dynamic Partitioning so Glue can separate the TIFF files before transformation.
• C. Use Firehose for telemetry; have the imager PUT TIFFs directly into S3; use an S3 event to invoke a Lambda function that starts the Glue job.✓
• D. Send the TIFF as multiple Firehose records; reassemble it with Lambda; use Firehose for telemetry; publish an S3 event to start Glue.

The correct solution keeps telemetry on Firehose because those records are small, and moves the 3 MB TIFF to a direct S3 PUT because S3 accepts objects up to 5 GB in a single upload. Kinesis Data Firehose is otherwise the obvious managed streaming option, but it has a per-record ceiling of 1,000 KB; a 3 MB TIFF cannot be ingested as one Firehose record. The strongest distractor is the Dynamic Partitioning option: Dynamic Partitioning changes how Firehose groups objects by keys in S3 and does not raise the per-record limit, so the 3 MB TIFF would still be rejected. The rule that generalizes is to check per-item, per-partition, and per-connection ceilings before relying on a service's aggregate throughput; a scalable service can still fail on a single input above one of those limits.

Q4/Resilience

A media company serves video files globally and runs its content catalog in an Amazon RDS MySQL database in us-east-1. A compliance rule requires that after a Regional outage the catalog can be made available in us-west-2 with an RPO of 1 second and an RTO of 1 minute. Which solution meets this requirement?

• A. Keep RDS MySQL and create a Cross-Region Read Replica in us-west-2; after the failure, promote the replica to primary.
• B. Convert to Amazon Aurora and use a global database with a secondary cluster in us-west-2; promote it for failover.✓
• C. Keep RDS MySQL and take manual snapshots every hour, copying each completed snapshot to us-west-2 for restore.
• D. Keep RDS MySQL and enable Multi-AZ in us-east-1 so automatic failover selects the standby database.

An Aurora Global Database replicates to a secondary Region and is documented for an RPO of 1 second and an RTO of about 1 minute when the secondary cluster is promoted, so it is the only option that can meet the stated compliance numbers. The Cross-Region Read Replica is the strongest distractor: it is a legitimate multi-Region disaster-recovery pattern, but RDS MySQL read-replica replication is asynchronous and has no 1-second RPO guarantee; replication lag can exceed one second under load or with large transactions. Multi-AZ protects only against an Availability-Zone failure, not a Regional outage, and hourly snapshot copies allow up to sixty minutes of data loss. When a compliance requirement states a hard RTO/RPO, choose the service explicitly designed and documented for that target rather than a pattern that usually performs well.

Q5/Resilience

A research institute runs bursty batch workloads that store sensitive experiment metadata in an Amazon RDS for PostgreSQL DB instance in us-east-1. The metadata must be encrypted and, if us-east-1 is completely unavailable, the database must be recoverable as a read-write database in another Region. Which solution meets this requirement with the LEAST operational overhead?

• A. Use AWS Backup to copy encrypted RDS snapshots to us-west-2 and restore the snapshot after a failure.
• B. Create an encrypted cross-Region read replica of the DB instance in us-west-2 and promote it when needed.✓
• C. Run a second PostgreSQL database on EC2 in us-west-2 and use AWS DMS to keep it synchronized.
• D. Enable Amazon RDS Multi-AZ with a standby in a different Availability Zone and keep encryption enabled.

The cross-Region read replica option is correct because RDS can replicate the encrypted DB instance to another Region, and promoting that replica makes it a standalone read-write database after a Regional failure. AWS manages the replication, so there is no extra database server to run and no restore workflow to build. The Multi-AZ option is the strongest distractor because Multi-AZ protects against loss of an Availability Zone, not loss of the entire Region; its standby is still in us-east-1. The snapshot-copy option and the DMS option could also produce a database in another Region, but snapshot restore is slower and more manual, while running an EC2 database with DMS adds servers and ongoing maintenance. The general rule is to use RDS Multi-AZ for Availability Zone resilience and a cross-Region read replica for Regional disaster recovery.

Q6/Cost

A SaaS company is expanding an existing event-ingestion service into a second Region. The service stores event data in Amazon DynamoDB. In the existing Region, the table handles a steady baseline of millions of writes each day with a sharp daily spike from 6:00 PM to 7:00 PM local time. The company knows the new Region will follow the same predictable pattern. It wants the most cost-effective database deployment for the new Region while avoiding throttling. What should the company do?

• A. Use DynamoDB provisioned capacity with scheduled scaling to scale up before the daily spike and scale down after.✓
• B. Use DynamoDB provisioned capacity with Reserved Capacity for the maximum write capacity needed during the daily spike.
• C. Use DynamoDB on-demand capacity mode so the new table automatically scales to handle the daily spike.
• D. Use DynamoDB provisioned capacity with target-tracking auto scaling and set minimum write capacity to the peak.

The scheduled-scaling option is correct because the peak is predictable and repeats daily: it can temporarily raise provisioned write capacity before the spike and lower it afterward, avoiding throttling without paying for peak capacity all day. The on-demand option is the strongest distractor because on-demand is the common choice for spiky workloads, but its per-request price is higher than provisioned capacity when the load shape is known in advance. Target-tracking with the minimum set to the peak value and Reserved Capacity sized for the peak both avoid throttling, but they pay for peak write capacity around the clock. The general rule is that a known, scheduled load should be handled with scheduled capacity changes rather than reactive or always-on capacity.

Q7/Cost

A research institute receives thousands of small data files from field sites at the same time each month and once mid-month. The existing pipeline places an Amazon S3 object key for each file into an SQS queue. A stateless Java application running on a fleet of EC2 instances polls the queue and writes transformed Parquet files to S3. The fleet is idle except for a few hours during each batch. A solutions architect must reduce compute cost while making the fewest changes to the application. What should the architect do?

• A. Replace the EC2 fleet with Lambda functions that are invoked by S3 object events, transform each object to Parquet, and remove the SQS queue.
• B. Create an AWS Glue job with a schedule trigger to read the S3 objects, transform them with Python, and write Parquet output to S3.
• C. Use an Auto Scaling group with scheduled scaling before each batch and an SQS queue-depth scaling policy to scale back in after the backlog clears.✓
• D. Run the existing Java code as a custom JAR step on a transient EMR cluster launched before each batch and terminated when the step finishes.

This is correct because the workload has a predictable batch pattern and the existing Java application must remain unchanged. Auto Scaling with scheduled scaling adds capacity just before each expected batch, and scaling on SQS queue depth removes capacity when the backlog clears, eliminating idle EC2 cost without rewriting the application. The Lambda option is the strongest distractor: serverless is a common response to bursty workloads and would reduce idle cost, but it requires rewriting the Java transformation and replacing the SQS pipeline, so it violates the fewest-changes constraint. The general rule is to align capacity to predictable load with scheduled scaling when the application is stateless, and reserve managed or serverless rewrites for cases where application changes are acceptable.

Q8/Security

A regulated financial services company runs an internet-facing web application behind an Application Load Balancer. A new compliance directive requires AWS-managed protection for common web exploits, including SQL injection and cross-site scripting, and centralized access logging of Web ACL decisions. The directive does not require DDoS cost protection or 24/7 DDoS support. What should be done to meet the directive at the lowest cost?

• A. Use AWS WAF managed rules and also enable AWS Shield Advanced on the ALB, with WAF logs delivered to Amazon S3.
• B. Enable AWS Shield Advanced on the ALB for enhanced DDoS protection and rely on the 24/7 DDoS Response Team.
• C. Use an AWS WAF web ACL with only a custom rate-based rule, associate it with the ALB, and log WAF decisions to CloudWatch Logs.
• D. Use an AWS WAF web ACL with the Core Rule Set managed rule group, associate it with the ALB, and enable WAF logs to Amazon S3.✓

The required controls are AWS-managed protection for common web exploits and centralized Web ACL decision logging. Option D meets both with AWS WAF Core Rule Set and WAF logs to Amazon S3, and it is the lowest-cost compliant choice. Option A also satisfies the logging and WAF protection requirement but adds AWS Shield Advanced, which is not required by the stated directive and creates unnecessary cost; this is the strongest distractor for someone who skims the scenario and assumes a financial firm needs the premium DDoS service. Option B provides only Shield Advanced, not WAF web ACL logging or managed exploit rules, and option C uses only a custom rate-based rule, so it does not provide managed SQL injection or cross-site scripting protection.

Q9/Security

A media streaming company runs video transcoding on EC2 instances. The instances use an instance profile with an IAM role that grants read/write access to S3 media buckets. A new process on those instances must publish job status to an SNS topic, and the security team requires that SNS and S3 permissions remain separate. What should the architect do?

• A. Create a second IAM role and attach it to this instance profile
• B. Allow the existing instance role to publish to the SNS topic
• C. Assume a separate SNS role via STS for temporary credentials✓
• D. Add SNS Publish to the policy of the existing instance role

An EC2 instance profile can contain only one IAM role, and that quota cannot be increased. To keep S3 and SNS permissions separate while running on the same instance, the application should use STS AssumeRole to obtain temporary credentials for a separate SNS publishing role. The strongest distractor is the option that it seems like the direct way to add a second role, but attaching a second IAM role to the same instance profile is not allowed. B and C keep the permissions together, violating the stated separation requirement.

Exam facts on this page come from Amazon Web Services’s own pages (official exam page). Prices, versions and policies change — confirm there before you book.