Welcome to a brand-new AWS batch for cloudtech.how. This set launches our SAA-C03 Questions 1-10 series on EC2 Auto Scaling and compute selection, and it lands in a big week for AWS silicon. Graviton5-powered M9g and M9gd instances just went generally available, and AWS is positioning them squarely at agentic AI and general-purpose workloads. As a result, the way you pick an instance family and design your Auto Scaling group matters more than ever.
Every question below follows the same pattern the real exam uses. First, a business or technical constraint is spelled out. Then, four services or configurations are offered — three feel plausible, but only one truly fits. Therefore, your job is to identify the requirement that eliminates the others.
This batch mixes fundamentals with newer material. For example, you will see classic questions about purchase models and placement strategies, alongside modern scenarios covering warm pools, predictive scaling, and Graviton-based instance selection. In addition, the difficulty ramps up gradually — the last three questions are the toughest.
Question 1: Choosing a Purchase Model for a Steady Workload
Contoso runs a public-facing e-commerce API on m7i instances with predictable, 24/7 utilization. However, leadership wants the lowest possible compute cost across a three-year horizon. Meanwhile, the platform team plans to migrate portions of the workload to Graviton within that window. Therefore, which purchase model best fits both goals?
A) One-year All Upfront EC2 Reserved Instances for m7i.
B) Three-year Compute Savings Plans.
C) Three-year Standard EC2 Reserved Instances for m7i.
D) On-Demand with Spot fallback.
👁 Reveal Answer
Correct Answer: B
Explanation: Compute Savings Plans deliver up to 66% off On-Demand and apply across instance family, size, region, tenancy, and operating system. Because Contoso plans to migrate to Graviton mid-term, the family flexibility matters. EC2 Reserved Instances (A, C) lock you to m7i and lose value when you migrate. On-Demand with Spot (D) provides no long-term discount for a steady 24/7 workload. Compute Savings Plans therefore hit both cost and flexibility goals.
Question 2: Selecting an Instance Family for CPU-Bound Web Servers
Fabrikam is sizing a fleet for a stateless web tier. Specifically, most cycles go to TLS termination and JSON serialization. Memory usage stays under 2 GB per instance; however, CPU regularly runs hot. Therefore, which instance family gives the best price-performance for this workload?
A) R7i memory-optimized instances.
B) M7i general-purpose instances.
C) C7i compute-optimized instances.
D) X2gd memory-intensive instances.
👁 Reveal Answer
Correct Answer: C
Explanation: C-family instances (C7i in this case) are compute-optimized, offering higher CPU-to-memory ratios and often the best price per vCPU. TLS termination and JSON serialization are CPU-bound tasks, so C7i is the clear match. R-family (A) and X2gd (D) target memory-heavy workloads such as in-memory databases; you would pay for RAM you do not use. M-family (B) is a reasonable general-purpose choice, but not as cost-efficient as C-family for this specific profile.
Question 3: EC2 Auto Scaling Across Availability Zones
Your team must design an EC2 Auto Scaling group for a customer-facing API. Specifically, four instances must remain online at all times, even during a full Availability Zone outage in one AWS Region. In addition, the Region has three AZs available. Therefore, what is the correct minimum configuration?
A) Single AZ, min=4, max=8.
B) Two AZs, min=4, max=8.
C) Three AZs, min=6, max=12.
D) Three AZs, min=4, max=12, with cross-zone rebalancing disabled.
👁 Reveal Answer
Correct Answer: C
Explanation: To keep four instances running during a full AZ failure, you need capacity spread so that losing one AZ still leaves four healthy instances. With three AZs and a min of six, EC2 Auto Scaling distributes two instances per AZ; losing one AZ leaves four. Option A has no AZ redundancy. Option B loses half the capacity if one of two AZs fails. Option D sounds close, but a min of four cannot survive losing any AZ — the group would fall to roughly three instances.
Question 4: Choosing a Scaling Policy Type
Northwind Traders wants their EC2 Auto Scaling group to hold average CPU utilization near 60% across the fleet. However, they want to avoid manually defining thresholds and step adjustments. In addition, the traffic pattern is bursty but continuous. Therefore, which scaling policy fits best?
A) Simple scaling on a CloudWatch alarm.
B) Step scaling with three adjustment tiers.
C) Target tracking scaling on ASGAverageCPUUtilization.
D) Scheduled scaling with hourly actions.
👁 Reveal Answer
Correct Answer: C
Explanation: Target tracking is the simplest policy for “hold metric X at value Y.” It manages the alarms and adjustments for you. Simple scaling (A) requires a manual cooldown and only reacts one step at a time. Step scaling (B) is more flexible but demands hand-tuned thresholds. Scheduled scaling (D) is for predictable time-based patterns, not for reactive CPU targeting. For “hold CPU near 60%,” target tracking is the textbook answer.
Question 5: Using Spot Instances for a Fault-Tolerant Pipeline
Litware runs a nightly video-transcoding pipeline in AWS. For example, each job takes 3–8 minutes, jobs are independent, and workers pull from an SQS queue. In addition, the workload can tolerate occasional interruptions if the job is simply retried. Therefore, what is the most cost-effective compute choice?
A) On-Demand instances behind an Auto Scaling group.
B) EC2 Spot Instances in a mixed-instances Auto Scaling group.
C) Reserved Instances sized for peak overnight demand.
D) Fargate on a Compute Savings Plan.
👁 Reveal Answer
Correct Answer: B
Explanation: Spot Instances offer up to 90% savings, and mixed-instances policies let you pool diverse instance types to reduce interruption risk. Because jobs are short, stateless, and retryable, a 2-minute Spot interruption notice is easy to handle — the job simply retries. On-Demand (A) costs far more. Reserved Instances (C) are wasteful for overnight-only capacity. Fargate on a Savings Plan (D) is fine but pricier than Spot for pure batch work.
Question 6: Picking the Right Placement Group Strategy
The architecture team is deploying a tightly coupled HPC simulation across 20 EC2 instances. Specifically, the nodes exchange large amounts of MPI traffic every millisecond. Therefore, latency and throughput between nodes are the top priority. In addition, a full AZ failure would already halt the job. Which placement strategy should they use?
A) Spread placement group.
B) Partition placement group with four partitions.
C) Cluster placement group.
D) No placement group; rely on Elastic Network Adapter alone.
👁 Reveal Answer
Correct Answer: C
Explanation: Cluster placement groups pack instances into the same high-bisection-bandwidth network segment within one AZ, minimizing latency and maximizing per-flow throughput. This is the recommended pattern for MPI-style HPC. Spread groups (A) intentionally scatter instances across hardware for resilience, which hurts latency. Partition groups (B) reduce correlated failures but do not optimize node-to-node latency. Skipping placement groups entirely (D) leaves performance on the table.
Question 7: Launch Templates for EC2 Auto Scaling
Woodgrove Bank wants their EC2 Auto Scaling group to run a mix of On-Demand and Spot capacity across several instance types. In addition, they need versioned rollouts of new AMIs. However, the current group uses a launch configuration. Therefore, what should they migrate to?
A) Keep the launch configuration and add a mixed-instances override.
B) Replace the launch configuration with a launch template.
C) Replace the launch configuration with a user-data script that self-configures.
D) Duplicate the launch configuration for each instance type.
👁 Reveal Answer
Correct Answer: B
Explanation: Launch templates are AWS’s recommended replacement for launch configurations. They add versioning, mixed-instances policies, Spot integration, and newer features such as Instance Refresh. Launch configurations (A) do not support mixed-instances policies at all. User-data self-configuration (C) does not solve the core problem. Duplicating launch configurations (D) is unmanageable. Launch templates are now the default for EC2 Auto Scaling in new AWS accounts.
Question 8: Warm Pools for Long-Boot Applications
An online marketplace runs a Java application whose instances take about six minutes to boot. Specifically, that time covers cache warming and load-balancer registration. However, during flash sales, EC2 Auto Scaling reacts too slowly and customers see errors. Therefore, what should be added first?
A) A larger cooldown period.
B) Simple scaling policies with shorter cooldowns.
C) An EC2 Auto Scaling warm pool.
D) An additional AZ.
👁 Reveal Answer
Correct Answer: C
Explanation: Warm pools hold pre-initialized instances in Stopped, Running, or Hibernated state outside active capacity. During scale-out, the group pulls warm instances first, cutting readiness time dramatically. Increasing cooldown (A) makes the problem worse. Shorter cooldowns on simple scaling (B) still cannot skip the six-minute boot. Adding an AZ (D) improves resilience but does nothing for scale-out latency. Warm pools directly target long-boot scale-out delay.
Question 9: Graviton-Based Instances for Cost-Performance
Adventure Works runs a Linux-based microservices platform on x86 m7i instances. In addition, the application is written in Go and Java 21 — both fully supported on ARM64. However, leadership wants a documented path to reduce compute cost while gaining performance. Therefore, which action should be recommended first?
A) Migrate to m8g or m9g Graviton-based instances.
B) Migrate to Windows-based m7i.large instances.
C) Increase the ASG cooldown period.
D) Switch every service to Lambda.
👁 Reveal Answer
Correct Answer: A
Explanation: Graviton-based M8g and the newer Graviton5-powered M9g instances typically deliver better price-performance than comparable x86 instances. M9g is up to 30% faster for databases and 35% faster for web and ML workloads compared to M8g. Because Go and Java 21 are first-class on ARM64, migration is realistic. Switching to Windows (B) does not help. Cooldown changes (C) are unrelated. A full Lambda rewrite (D) is a much larger, higher-risk change.
Question 10: Predictive Scaling for EC2 Auto Scaling
Tailwind Traders sees a sharp daily traffic peak around 09:00 in every region. However, their target-tracking policy always lags by several minutes as the fleet scales out. In addition, they want capacity ready before the peak arrives, without hand-writing scheduled actions each week. Therefore, which enhancement fits best?
A) Add a scheduled scaling action at 08:45 each weekday.
B) Switch to step scaling with tighter thresholds.
C) Enable predictive scaling alongside target tracking.
D) Increase the maximum size of the Auto Scaling group.
👁 Reveal Answer
Correct Answer: C
Explanation: Predictive scaling uses machine learning to forecast load from historical CloudWatch metrics, then launches capacity ahead of demand — often 5–15 minutes early via a scheduling buffer. It complements target tracking, which handles unexpected spikes. Scheduled scaling (A) works but demands manual updates as patterns shift. Step scaling (B) still reacts after the fact. Bumping the maximum (D) permits growth but does not prelaunch capacity. Predictive scaling is purpose-built for this problem.
Study Tips for Mastering EC2 Auto Scaling
Use these tips to sharpen your instincts for the EC2 Auto Scaling questions on the SAA-C03.
- Read the constraint first. Every scenario hinges on one line — RPO, RTO, cost, latency, or blast radius. Identify it before you scan the answers.
- Know your placement groups cold. Cluster for latency, spread for tiny fleets that must never fail together, partition for large distributed systems.
- Default to launch templates. If a question mentions launch configurations, the answer usually involves replacing them.
- Match the scaling policy to the pattern. Target tracking for “hold at X,” predictive for repeatable peaks, scheduled for known events.
- Do not forget Graviton. When workloads are ARM-friendly, Graviton-based families almost always win on price-performance.
Keep Practicing EC2 Auto Scaling Scenarios
You made it through the first ten questions of the new SAA-C03 batch series on EC2 Auto Scaling and compute strategy. Keep working through scenarios daily — pattern recognition is what turns a passing score into a comfortable margin. For additional practice, review these earlier single-question posts on related topics: Auto Scaling Group Across Multiple AZs, Auto Scaling Replacing Unhealthy Instances, and Cheapest Compute for Fault-Tolerant Batch Jobs.
For the official reference on scaling policies and warm pools, see the AWS EC2 Auto Scaling User Guide. More SAA-C03 practice questions are in the AWS section of the menu.