SAA-C03 Practice Question: Cluster placement groups provide the lowest…
A company is deploying a high-performance computing (HPC) cluster with 16 EC2 instances. The workload requires the lowest possible network latency and highest throughput between all nodes for tightly coupled parallel MPI computations. Which EC2 placement group type should a solutions architect recommend?
⚠ Common exam trap
Spread and Partition placement groups improve availability by distributing instances across racks or partitions — they intentionally increase inter-node distance, which increases latency. For HPC requiring sub-microsecond inter-node communication, low latency trumps availability. Cluster PG = maximum performance in one AZ. Spread PG = maximum isolation across racks.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Cluster placement group
Cluster placement groups pack instances physically close together within a single Availability Zone, providing the lowest possible network latency and highest network throughput between instances. They support enhanced networking (SR-IOV) and Elastic Fabric Adapter (EFA) for inter-node MPI communication. Tightly coupled parallel HPC workloads require all nodes to communicate frequently with minimal latency. Cluster placement groups are specifically designed for this use case. The trade-off is all instances are in one AZ — if the AZ fails, the entire cluster is affected.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Cluster placement group
Why this is correct
A Cluster placement group is the definitive choice for tightly coupled HPC workloads because it co-locates instances in a single Availability Zone with dedicated, high-bandwidth, low-latency connectivity. This hardware-level proximity minimizes network jitter and switch hops, enabling the sub-microsecond latency required for MPI-style distributed computing. Additionally, Cluster placement groups fully support Elastic Fabric Adapter (EFA), which bypasses the OS kernel to deliver near-bare-metal performance for tightly coupled parallel jobs, making it the standard placement strategy for HPC clusters.
- ✗
Partition placement group
Why it's wrong here
A Partition placement group deliberately spreads instances across distinct hardware racks, each with independent power and network infrastructure, to contain the blast radius of a rack failure. While this improves fault tolerance and is well-suited for replicated workloads like Hadoop, Kafka, or Cassandra that tolerate higher inter-node latency, it directly conflicts with HPC requirements. Because instances land on different racks, network traffic traverses upstream switches, adding latency and reducing throughput—the exact opposite of what tightly coupled, latency-sensitive HPC applications need.
- ✗
Spread placement group
Why it's wrong here
A Spread placement group takes rack-level isolation to the extreme by placing each instance on its own dedicated rack, guaranteeing that no two instances share the same failure domain. This maximizes availability and is appropriate for small numbers of critical, stateless or failover-capable instances, but it inherently forces every inter-node communication to cross top-of-rack switches. For tightly coupled HPC, this added network distance and hop count destroys the low-latency, high-throughput performance required, so it is a poor fit for MPI-based simulations or real-time high-performance analytics.
- ✗
No placement group — use Auto Scaling across multiple AZs
Why it's wrong here
Using Auto Scaling across multiple Availability Zones without any placement group prioritizes resilience and capacity diversity over performance, but it scatters instances across geographically distinct data centers. The physical separation across AZs introduces network round-trip times in the millisecond range—orders of magnitude higher than the sub-microsecond latencies needed by tightly coupled HPC jobs. Even with placement groups, a single Cluster placement group is constrained to one AZ, so this cross-AZ approach fundamentally cannot meet the inter-node communication requirements of tightly coupled HPC and should be avoided for such workloads.
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.