AZ-305 Design infrastructure solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Azure Virtual Machine Scale Sets with a Proximity Placement Group

  Why this is correct

  Azure Virtual Machine Scale Sets with a Proximity Placement Group (PPG) is the correct choice for tightly coupled HPC workloads because a PPG co-locates all VM instances within the same Azure datacenter, minimizing network latency to the sub-10 microseconds required by MPI applications. VMSS integrates with PPG by allowing you to scale the compute cluster out while ensuring every new instance remains within the placement group, preserving low-latency inter-node communication. This combination also enables the use of high-throughput, low-latency networking such as InfiniBand on supported HPC VM SKUs, which is essential for parallel jobs that need frequent, low-latency message passing.

• ✗

  Azure Availability Sets

  Why it's wrong here

  Azure Availability Sets are unsuitable for tightly coupled HPC workloads because they are designed for high availability within a single datacenter by distributing VMs across fault domains and update domains. That distribution physically separates VMs into different racks and switches, adding network latency far beyond the sub-10 microsecond requirement for MPI communication. Additionally, an Availability Set has a hard limit of 100 VMs and does not support automatic scaling, making it impossible to dynamically grow the HPC cluster while maintaining low, consistent latency. The placement in separate fault domains works against the co-location that tightly coupled jobs demand.

• ✗

  Azure Virtual Machine Scale Sets across Availability Zones

  Why it's wrong here

  Azure Virtual Machine Scale Sets spread across Availability Zones place VMs in distinct physical datacenters within a region, which inherently introduces cross-datacenter network latency that is orders of magnitude higher than sub-10 microseconds. Even when using a VMSS, the default zone-spreading policy intentionally distributes instances to maximize availability, directly conflicting with the need to co-locate compute nodes for MPI workloads. Although zones provide redundancy, that resilience comes at the cost of placement control; without a Proximity Placement Group, VMSS instances within a zone may also be spread across racks, preventing the tight coupling that HPC requires. The network path between zones traverses additional switches and often public or regional infrastructure, making it an unsuitable topology for latency-sensitive jobs.

• ✗

  Azure Kubernetes Service (AKS)

  Why it's wrong here

  Azure Kubernetes Service (AKS) is a poor fit for a tightly coupled HPC workload because Kubernetes introduces an orchestration layer that abstracts nodes and adds overhead to network packet processing, making sub-10 microsecond latencies unattainable. AKS clusters typically use standard virtual network interfaces and cannot guarantee that pods are placed on nodes with physical proximity or low-latency interconnect such as InfiniBand, unless you manually construct agent pools with complex node affinity rules—yet even then, AKS does not integrate with Proximity Placement Groups directly for all VM sizes. The control-plane components and networking plugins (e.g., kube-proxy, overlay networks) add jitter and latency that are unacceptable for MPI-style message passing. For HPC, you need direct control over VM placement and low-level network characteristics, which AKS abstracts away.