Choosing compute: SAA-C03 study notes and practice questions
What to know about Choosing compute for the SAA-C03 exam, from the Design High-Performing Architectures domain (24% of the exam guide), then 3 free questions to test it. Part of the SAA-C03 study guide.
Compute questions describe a workload’s shape (how long each task runs, how spiky the load is, what it needs from the OS) and how much management the team wants. That narrows the choice quickly.
The map
Workload
Good fit
Why
Short, event-driven tasks with idle periods (under 15 minutes)
AWS Lambda
Scales from zero, billed per request and duration, nothing to manage
Containers without managing servers, including long-running services
Amazon ECS or EKS on AWS Fargate
No instances to patch or scale; billed for task CPU and memory
Containers at large, steady scale where you want instance-level control or pricing
ECS or EKS on EC2
Cheaper at high utilization; Savings Plans and Spot apply
Existing Kubernetes skills or tooling
Amazon EKS
Managed Kubernetes control plane
Full OS control, special licensing, GPUs, long-running servers
Amazon EC2
Any instance type, any software
Batch jobs at scale
AWS Batch
Queues jobs and provisions EC2 or Fargate capacity, including Spot
A web app or API from code or a container, with minimal setup
AWS App Runner or Elastic Beanstalk
Managed deployment and scaling
Lambda limits that decide questions
Maximum run time of 15 minutes per invocation. Longer work goes to Fargate, Batch or Step Functions to split it up.
Memory from 128 MB to 10,240 MB; CPU scales with memory.
Provisioned concurrency removes cold starts for latency-sensitive functions.
Reserved concurrency caps a function so it can’t overwhelm a downstream database.
EC2 placement groups
Type
Instances are
Use for
Cluster
Packed close together in one zone
Lowest latency, highest throughput between nodes (HPC)
Spread
On distinct hardware racks, up to 7 per zone per group
A small number of critical instances that mustn’t fail together
Partition
In partitions on separate racks
Large distributed systems such as Hadoop, Cassandra or Kafka
Instance families in one line each
General purpose (M, T) for balanced work; compute optimized (C) for CPU-bound work; memory optimized (R, X) for in-memory databases and caches; storage optimized (I, D) for high local disk I/O; accelerated (P, G, Inf, Trn) for ML and graphics. Graviton (the “g” suffix) gives better price performance for most Linux workloads.
Common traps
Lambda for jobs that run over 15 minutes.
EC2 for “no servers to manage”. Fargate or Lambda.
Cluster placement groups for high availability. They’re in one zone; use spread for resilience.
A photo-sharing app stores user uploads in an Amazon S3 bucket.
A thumbnail must be available within 10 seconds of each upload, and creating one takes about 2 seconds of processing. Uploads are irregular: there are none for hours overnight, then bursts of up to 600 uploads a minute after popular events. The small team does not want to manage servers or pay for capacity that sits idle.
Which solution meets these requirements with the LEAST operational overhead?
Choose one answer.
AA. Send S3 event notifications to an Amazon SQS queue, and process the queue with EC2 instances in an Auto Scaling group that scales on the queue backlog.
BB. Use Amazon EventBridge Scheduler to invoke an AWS Lambda function every minute that lists the bucket and processes any new objects it finds.
CC. Send S3 event notifications to an Amazon SQS queue, and process the queue with an Amazon ECS service that runs two AWS Fargate tasks at all times.
DD. Configure S3 event notifications for new objects to invoke an AWS Lambda function that writes each thumbnail to a separate bucket.
Show the answer and explanation
Answer: D
A. Wrong: Queue-based scaling with EC2 Auto Scaling is a sound pattern for bursty work and would keep up with the bursts. However, the team would have to patch and manage the instances, and at least one instance usually runs all night to avoid slow scale-out, which breaks both the no-servers and no-idle-capacity constraints. Learn more: Scaling policy based on Amazon SQS (opens in a new tab)
B. Wrong: This is serverless and costs little while idle, but polling once a minute means a photo can wait up to a minute before work starts, which misses the 10-second target. Listing a growing bucket on every run also gets slower and costlier over time; an event-driven trigger avoids both problems. Learn more: Managing a schedule in EventBridge Scheduler (opens in a new tab)
C. Wrong: Fargate removes server management, but two tasks working one photo at a time handle about 60 photos a minute, so a burst of 600 a minute builds a backlog far beyond 10 seconds. The two tasks also run and are billed all night when there is nothing to do. Learn more: AWS Fargate for Amazon ECS (opens in a new tab)
D. Right: Correct. S3 invokes the function for each new object within moments, and Lambda runs as many copies as the burst needs, so 600 uploads a minute (about 20 concurrent 2-second jobs) are handled without any servers. Nothing runs or is billed overnight, and writing to a separate bucket avoids the function triggering itself. Learn more: Process Amazon S3 event notifications with Lambda (opens in a new tab)
Explanation
The work is triggered by an event, is short, and arrives in unpredictable bursts with long idle periods. S3 event notifications invoking Lambda start each job straight away, scale out automatically to the roughly 20 concurrent jobs a 600-per-minute burst needs, and cost nothing when idle. Polling misses the 10-second target, a fixed pair of tasks cannot keep up with bursts, and an EC2 fleet adds servers to manage.
Each upload starts its own Lambda run, so bursts scale out on their own and quiet nights cost nothing.
A logistics company has packaged eight microservices as container images.
The services run all day behind an Application Load Balancer, and a nightly reconciliation job runs for about 2 hours. The operations team is small and does not want to patch operating systems, choose instance types or right-size a fleet of hosts. Each workload should be billed for the CPU and memory it requests.
Which solution meets these requirements?
Choose one answer.
AA. Run the services and the nightly job on Amazon ECS with an Auto Scaling group capacity provider that uses the latest ECS-optimized AMI.
BB. Run the services as Amazon ECS services on AWS Fargate, and start the nightly job as a Fargate task from an EventBridge Scheduler schedule.
CC. Deploy the services and the nightly job as AWS Lambda functions packaged as container images, invoked by the load balancer and by a schedule.
DD. Deploy the services to AWS Elastic Beanstalk on the Docker platform with managed platform updates, and run the nightly job with cron on an instance.
Show the answer and explanation
Answer: B
A. Wrong: ECS on an Auto Scaling group capacity provider runs the containers well, but the EC2 instances are self-managed. The team would still choose instance types, patch and replace the AMIs, and pay for whole instances rather than for what each task requests. Fargate removes that work. Learn more: Amazon ECS capacity providers for EC2 workloads (opens in a new tab)
B. Right: Correct. With Fargate there are no servers or clusters of instances to provision, patch or scale, and each task is sized and billed by the CPU and memory it requests. Fargate tasks can run for as long as needed, and EventBridge Scheduler can start the 2-hour job as an ECS task on a cron schedule. Learn more: Using Amazon EventBridge Scheduler to schedule Amazon ECS tasks (opens in a new tab)
C. Wrong: Lambda accepts container images and removes server management, and it suits short request-driven code. However, a Lambda invocation has a maximum timeout of 15 minutes (90 minutes only for some invocation types on Lambda Managed Instances), so a 2-hour job cannot run as a single function. Learn more: Lambda quotas (opens in a new tab)
D. Wrong: Elastic Beanstalk with managed platform updates takes over much of the patching, but it still runs EC2 instances in the account. The team would choose instance types, pay for whole instances, and keep a cron job on one instance, which is the host management it wants to avoid. Learn more: What is AWS Elastic Beanstalk? (opens in a new tab)
Explanation
AWS Fargate runs ECS tasks without any EC2 instances to choose, patch or scale. Each task declares its CPU and memory and is billed for them, and tasks can run for hours, so both the long-running services and the 2-hour nightly job fit. Lambda's 15-minute timeout rules it out for the job, and the EC2-based options leave the team managing instances.
An engineering firm runs a fluid dynamics simulation on 16 identical compute-optimized EC2 instances.
Every few milliseconds, each instance exchanges results with all the others, so job run time is dominated by network latency between the nodes. The jobs write a checkpoint every 10 minutes, so if an Availability Zone fails the firm is happy to restart a job elsewhere.
Which launch configuration will give the SHORTEST job run time?
Choose one answer.
AA. Launch the 16 instances into a spread placement group that spans three Availability Zones in the Region.
BB. Launch all 16 instances in a single request into a cluster placement group in one Availability Zone.
CC. Launch the 16 instances into a partition placement group with seven partitions in a single Availability Zone.
DD. Launch the 16 instances across two Availability Zones in the same VPC, with enhanced networking turned on.
Show the answer and explanation
Answer: B
A. Wrong: A spread placement group puts each instance on distinct hardware to reduce correlated failures, and with up to seven running instances per Availability Zone, 16 instances would fit across three zones. But spreading nodes across racks and zones raises the latency between them, which is the opposite of what this job needs. Learn more: Placement strategies for your placement groups (opens in a new tab)
B. Right: Correct. A cluster placement group packs instances close together inside one Availability Zone for the low-latency, high-throughput networking that tightly coupled HPC jobs need. Launching them in one request with one instance type reduces the chance of an insufficient capacity error, and checkpoints cover the single-zone risk. Learn more: Placement strategies for your placement groups (opens in a new tab)
C. Wrong: Partition placement groups keep groups of instances on separate racks so that a hardware failure affects only one partition, which suits HDFS, HBase or Cassandra. Placing nodes on different racks does not minimize node-to-node latency, so it would not give the shortest run time. Learn more: Placement strategies for your placement groups (opens in a new tab)
D. Wrong: Enhanced networking helps every instance, but traffic between Availability Zones has higher latency than traffic within one zone, and without a cluster placement group instances are not placed close together. The firm has already accepted the single-zone risk, so it does not need to pay this latency cost. Learn more: Placement groups for your Amazon EC2 instances (opens in a new tab)
Explanation
The workload is tightly coupled and latency-bound, and the firm accepts restarting from a checkpoint if a zone fails, so there is no reason to trade latency for resilience. A cluster placement group in one Availability Zone gives the lowest latency between instances; spread and partition groups deliberately separate hardware, and spanning zones adds latency.
Want more on Choosing compute? The 5 full-length practice sets have 11 more Choosing compute questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →