AZ-305 Design infrastructure solutions: 572 practice questions

12 of the 572 Design infrastructure solutions questions in the Certsqill AZ-305 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-305? Take the free 5-min readiness check →

1. M-series with local NVMe SSDs: Which VM SKU family should the architect recommend?

1. M-series (memory optimized) with local NVMe SSDs, providing up to 12 TB RAM and fast local scratch for large in-memory analytics ✓

   Correct. M-series VMs offer up to 12 TB RAM with local NVMe storage, purpose-built for in-memory databases and analytics that need massive memory plus fast local scratch space.
2. E-series (memory optimized), giving a strong memory-to-vCPU ratio but capping near 672 GB RAM, well short of the 2 TB in-memory requirement here

   Incorrect. E-series supports up to roughly 672 GB RAM, which is far below the 2 TB in-memory requirement. The M-series is designed for the largest in-memory workloads.
3. L-series (storage optimized), delivering high local NVMe IOPS but only up to 384 GB RAM, far below the 2 TB in-memory need

   Incorrect. L-series is optimized for disk throughput and IOPS but offers only up to about 384 GB RAM, insufficient for a 2 TB in-memory dataset.
4. N-series (GPU optimized), accelerating ML and rendering but offering RAM that cannot hold a 2 TB in-memory workload

   Incorrect. N-series provides GPU acceleration for ML and rendering, not large in-memory analytics. GPU capacity does not substitute for the RAM needed to hold 2 TB in memory.

M-series VMs provide up to 12 TB RAM and local NVMe, purpose-built for massive in-memory analytics workloads.

2. VMSS with overprovisioning disabled: Which VMSS configuration minimizes cost while meeting the 2-minute SLA?

1. VMSS with Flexible orchestration and Reserved Instances for the maximum expected capacity

   Reserving maximum capacity eliminates scaling benefit entirely — paying for idle VMs at maximum capacity is not cost-optimized.
2. VMSS with overprovisioning disabled, autoscale, and a warm pool (standby pool) configured ✓

   Warm pools (standby pools) keep VMs in a pre-initialized state so they can be added to the scale set rapidly — typically in under 30 seconds — meeting the 2-minute SLA cost-effectively.
3. VMSS with Uniform orchestration, autoscale policy, and a minimum count of 0 with scale-out trigger on queue depth

   Scaling from 0 with VM initialization (3-5 minutes typical) would violate the 2-minute SLA when all VMs are deallocated.
4. VMSS with Flexible orchestration mode and Spot VMs with overprovisioning enabled

   Spot VMs can be evicted at any time, making them unsuitable for SLA-bound workloads. Overprovisioning helps availability but Spot eviction undermines the 2-minute SLA.

Warm pools (standby pools) keep VMs pre-initialized, enabling rapid scale-out to meet tight SLAs without permanently paying for idle capacity.

3. Deploy all 8 VMs in a single Proximity Placement Group so: Which deployment option best meets this requirement

1. Deploy the VMs across two Availability Zones connected by VNet peering, balancing low latency with resilience against a single-zone failure

   Incorrect. Cross-zone traffic adds 1-2ms of latency and VNet peering does not shorten the physical distance between VMs. This raises latency above what a single-zone Proximity Placement Group deployment achieves.
2. Deploy the VMs in an Availability Set spread across 3 fault domains so co-location keeps network hops and latency to a minimum within the datacenter

   Incorrect. Availability Sets spread VMs across fault domains for resilience but do not guarantee network co-location, so latency is not minimized the way a Proximity Placement Group guarantees.
3. Deploy all 8 VMs in a single Proximity Placement Group so they are co-located on the same hardware cluster for the lowest inter-VM latency ✓

   Correct. Proximity Placement Groups co-locate VMs on the same physical hardware cluster, minimizing network hops and achieving the lowest possible inter-VM latency within a single region, which is exactly what the trading system needs.
4. Deploy the VMs in an Accelerated Networking-enabled VNet without placement constraints, relying on SR-IOV to drive latency down to sub-millisecond

   Incorrect. Accelerated Networking reduces CPU overhead and jitter but does not control physical VM placement. Without a Proximity Placement Group the VMs may sit far apart in the datacenter, keeping latency high.

Proximity Placement Groups co-locate VMs on the same physical cluster to achieve minimum inter-VM network latency.

4. Azure Dedicated Hosts with maintenance control enabled: Which solution meets both requirements?

1. Isolated VM sizes (e.g., Standard_M128s) in an Availability Set

   Isolated VM sizes use an entire physical host but only for that specific VM instance — they don't provide hardware-level isolation for multiple VMs and don't support maintenance control scheduling.
2. Azure VMware Solution with dedicated ESXi hosts

   Azure VMware Solution provides VMware-based isolated compute but is designed for migrating existing VMware workloads. It doesn't integrate with standard Azure VM workloads and adds significant operational complexity.
3. Confidential VMs with AMD SEV-SNP encryption

   Confidential VMs encrypt VM memory to protect data in use but run on shared physical hardware — they don't satisfy the physical isolation from other tenants requirement.
4. Azure Dedicated Hosts with maintenance control enabled ✓

   Dedicated Hosts provide single-tenant physical servers exclusively allocated to one customer, satisfying the isolation requirement. Maintenance control on Dedicated Hosts lets you defer and schedule host-level updates within a 35-day window.

Azure Dedicated Hosts provide single-tenant physical isolation and support maintenance control for scheduling updates outside batch windows.

5. Connect AVS to an Azure VNet over its ExpressRoute circuit: What is the recommended connectivity approach?

1. Connect AVS to an Azure VNet over its ExpressRoute circuit, then use Private Endpoints so AVS VMs reach Azure SQL and Blob Storage on private IPs ✓

   Correct. AVS connects to an Azure VNet over a dedicated ExpressRoute circuit, and Private Endpoints for the PaaS services let AVS-hosted VMs reach Azure SQL and Blob Storage over private IP addresses without any public internet exposure.
2. Configure Service Endpoints on the AVS management subnet so traffic to Azure SQL and Blob Storage stays on the Microsoft backbone, off the public internet

   Incorrect. Service Endpoints are configured on Azure VNet subnets, not on AVS infrastructure. AVS subnets are VMware-managed and do not support Azure Service Endpoint configuration.
3. Deploy an Azure VPN Gateway between AVS and the VNet that hosts the Private Endpoints, tunneling SQL and Blob Storage traffic privately over IPsec

   Incorrect. AVS uses ExpressRoute, not VPN, as its primary connectivity to Azure VNets. A VPN Gateway is not the supported path from AVS to Azure PaaS services.
4. Reach Azure SQL and Blob Storage through their public endpoints, using storage and SQL IP firewall rules that only allow the AVS outbound NAT IP

   Incorrect. Using public endpoints routes traffic over the internet, which violates the requirement to keep the connections private and off the public internet.

AVS connects to Azure VNet via ExpressRoute; Private Endpoints then route PaaS access over private IP without internet exposure.

6. Hub VNet with Azure Firewall and an ExpressRoute Gateway: Which architecture satisfies all three requirements?

1. Azure Virtual WAN Standard hub with a routing intent policy that automatically steers all inter-spoke and on-premises traffic through the secured hub firewall

   Incorrect. vWAN with routing intent can satisfy the requirements, but the question specifies a hub-and-spoke topology. vWAN is a distinct managed architecture that replaces hub-and-spoke rather than implementing it.
2. Hub VNet with Azure Firewall and an ExpressRoute Gateway; spokes peered using AllowGatewayTransit/UseRemoteGateways and UDRs sending 10.0.0.0/8 to the firewall ✓

   Correct. Azure Firewall in the hub inspects spoke-to-spoke traffic via UDRs, UseRemoteGateways and AllowGatewayTransit share the ExpressRoute Gateway across all spokes, and the UDRs force traffic through the firewall without any BGP configuration.
3. Hub VNet with an active-active third-party NVA running BGP, using VXLAN tunnels between spokes to carry and inspect all cross-spoke traffic flows

   Incorrect. VXLAN tunnels and BGP with third-party NVAs add significant complexity and require BGP route management, violating the no-additional-BGP requirement, and VXLAN tunnels also bypass native peering-based inspection.
4. Spoke VNets peered directly to one another with NSGs on each subnet blocking any unauthorized cross-spoke traffic between the workloads

   Incorrect. Direct spoke-to-spoke peering bypasses the centralized NVA, so traffic is never inspected. NSGs filter by rules but do not provide the deep inspection of a firewall, failing the first requirement.

Hub Azure Firewall with UseRemoteGateways peering flags and UDRs provides centralized inspection, shared ExpressRoute, and no BGP requirement.

7. 3 subnets: a /25 for AKS , a /27 for Application Gateway: What is the minimum number of subnets required and w

1. 2 subnets: a /25 for AKS with its pods, and a /26 shared between the Application Gateway v2 and the five management VMs to conserve address space

   Incorrect. Application Gateway v2 requires a dedicated subnet and cannot share one with other resources, so combining the gateway and the management VMs in a single /26 violates that constraint.
2. 4 subnets: separate ranges for AKS nodes, AKS pods, Application Gateway v2, and management VMs, isolating each tier for clearer IP planning

   Incorrect. With Azure CNI, node and pod IPs come from the same subnet, so separate node and pod subnets are unnecessary and would actually break Azure CNI addressing.
3. 3 subnets: a /25 for AKS (Azure CNI assigns both node and pod IPs from it), a /27 for Application Gateway v2, and a /28 for the management VMs ✓

   Correct. Azure CNI needs a subnet sized for node plus pod IPs, so ~100 pods plus nodes fits a /25. Application Gateway v2 needs its own subnet (a /27 is recommended for autoscaling), and 5 management VMs fit a /28 (11 usable). Three dedicated subnets are required.
4. 1 subnet: a single flat /24 shared by AKS, Application Gateway v2, and the management VMs to maximize address flexibility across the workloads

   Incorrect. Application Gateway v2 requires its own dedicated subnet, and AKS with Azure CNI also benefits from a dedicated subnet to avoid IP conflicts, so a single shared /24 is not supported.

Three dedicated subnets are required: AKS (Azure CNI), Application Gateway v2 (must be dedicated), and management VMs.

8. Traffic is allowed because Priority 100 matches first: What is the outcome?

1. Traffic is denied because Priority 200 denies 10.0.1.0/24 and overrides the broader allow

   NSGs do not evaluate all matching rules and apply the most specific. They stop at the first matching rule in priority order. Priority 100 matches first, so Priority 200 is not evaluated.
2. Traffic is denied because same-subnet traffic is blocked by default

   Azure does not block intra-subnet traffic by default. The VirtualNetwork service tag (priority 65000) explicitly allows same-VNet traffic, and Priority 100 allows it even earlier.
3. Traffic is allowed by the VirtualNetwork default tag at Priority 65000

   Priority 65000 is only evaluated if no earlier rule matches. Priority 100 already matches, so Priority 65000 is irrelevant in this scenario.
4. Traffic is allowed because Priority 100 matches first and allows TCP 443 from Any ✓

   NSG rules are evaluated in priority order lowest-to-highest number. Priority 100 (Allow TCP 443 from Any) matches first and allows the traffic. Priority 200's deny for 10.0.1.0/24 is never evaluated because the match already occurred at Priority 100.

NSG rules are evaluated in ascending priority order and stop at the first match — Priority 100 allows TCP 443 before the Priority 200 deny is evaluated.

9. Azure Firewall Premium with TLS inspection: Which Azure Firewall configuration is required?

1. Azure Firewall Premium with TLS inspection, IDPS running in Alert and Deny mode, and a Web Categories URL filtering policy with full path awareness ✓

   Correct. Azure Firewall Premium delivers all three requirements: TLS inspection that intercepts and re-signs sessions to inspect encrypted traffic, signature-based IDPS with alert-and-deny, and URL filtering with full path awareness rather than FQDN-only.
2. Azure Firewall Standard with Threat Intelligence set to Alert and Deny mode, matching flows against Microsoft feeds of known malicious IPs and domains

   Incorrect. Standard Threat Intelligence only matches known bad IPs and domains from Microsoft feeds; it does not perform TLS inspection, signature-based IDPS, or full URL path filtering, all of which are Premium-only features.
3. Azure Firewall Basic paired with the Azure DDoS Protection Network plan to filter malicious sessions and absorb volumetric attacks at the perimeter

   Incorrect. Azure Firewall Basic targets SMB workloads and lacks TLS inspection, IDPS, and URL path filtering, and DDoS Protection addresses volumetric attacks rather than content inspection, so this combination cannot meet the requirements.
4. Azure Firewall Standard with an Application Gateway WAF in front performing TLS offload and layer-7 inspection of the inbound HTTPS web traffic

   Incorrect. Application Gateway WAF inspects HTTP/HTTPS for web apps but does not provide signature-based IDPS or network-level east-west inspection, so it cannot replace Premium IDPS for this requirement.

Azure Firewall Premium provides TLS inspection, signature-based IDPS, and full URL path filtering — all unavailable in Standard or Basic tiers.

10. Azure Bastion Standard SKU deployed in the hub VNet: Which Azure Bastion configuration meets these requirement

1. Azure Bastion Basic SKU deployed in each VNet

   Bastion Basic only supports browser-based RDP/SSH — it does not support native client connectivity. It also requires deployment per VNet, not peered-VNet sharing.
2. Azure Bastion Standard SKU deployed in the hub VNet with IP-based connection enabled ✓

   Bastion Standard supports native client connectivity (SSH/RDP via Azure CLI or native client), and when deployed with IP-based connection, it can connect to VMs in peered VNets without requiring Bastion in each spoke. Standard also enables VNet peering support.
3. Azure Bastion Developer SKU with private-only deployment

   Bastion Developer SKU is a lightweight, no-cost option for dev/test but doesn't support native client connectivity, VNet peering, or scaling. It's not suitable for production DevOps workflows.
4. Azure Bastion Basic SKU with Just-In-Time VM access from Microsoft Defender for Cloud

   JIT VM access temporarily opens inbound RDP/SSH on the VM's public IP — it doesn't eliminate the public IP requirement and Basic Bastion doesn't support native clients.

Azure Bastion Standard with IP-based connection supports native SSH clients and connectivity to VMs in peered VNets from a single Bastion deployment.

11. Attach an Azure NAT Gateway to the application subnet: Which solution resolves SNAT exhaustion with minimal ar

1. Enable outbound rules on the Standard Load Balancer with manually pre-allocated SNAT ports so each backend VM receives a guaranteed port range

   Incorrect. Outbound rules improve SNAT port pre-allocation but the ports are still shared proportionally across the pool, so as VM count grows each VM gets fewer ports. This does not scale as well as NAT Gateway's per-VM allocation.
2. Add several more public IP addresses to the Standard Load Balancer frontend so the extra SNAT ports are distributed across all 100 backend VMs

   Incorrect. Each extra Load Balancer public IP adds ports that are still distributed across all VMs, so with 100 VMs and variable load the improvement is limited and requires tracking per-IP allocation.
3. Attach an Azure NAT Gateway to the application subnet, giving 64,512 SNAT ports per public IP dedicated per-VM instead of shared across the pool ✓

   Correct. NAT Gateway provides 64,512 SNAT ports per public IP allocated dynamically per VM rather than shared across a pool, supports up to 16 public IPs for roughly a million ports, and takes precedence over the Load Balancer for outbound flows on the subnet.
4. Deploy a dedicated HTTP proxy tier that all VMs route outbound through, consolidating and reusing connections to external APIs behind fewer IPs

   Incorrect. An HTTP proxy can consolidate and reuse connections, but it introduces a new component, a potential bottleneck, and operational overhead, so it is not the minimal architectural change the question asks for.

NAT Gateway provides dedicated per-VM SNAT ports (64,512 per public IP) and scales by adding public IPs, resolving exhaustion without architectural change.

12. Link the zone to all three VNets and enable: What must be configured?

1. Link the Private DNS zone to all three VNets and enable autoregistration on every link at once so all VMs register and resolve without extra setup

   Incorrect. This option assumes autoregistration behaves identically to the correct design, but it omits the per-link registration nuance and the requirement to keep resolution working across all links, so it does not correctly describe the supported configuration.
2. Link the zone to the three VNets as resolution-only links and add an Azure DNS Private Resolver with forwarding rules to handle cross-VNet name resolution

   Incorrect. DNS Private Resolver with forwarding is meant for cross-environment resolution such as on-prem to Azure, not for autoregistration across VNets, and resolution-only links let VMs query the zone but never register automatically.
3. Link the zone to all three VNets, enable autoregistration on just one VNet, and manually create A records for the VMs in the other two VNets

   Incorrect. This allows resolution across VNets but forces manual record management for VMs in the two non-autoregistration VNets, which is not scalable and prone to drift as VMs change.
4. Link the zone to all three VNets and enable autoregistration on each VNet's link, so VMs register in their VNet while every linked VNet can resolve ✓

   Correct. Each VNet link to a Private DNS zone can have autoregistration enabled so VMs in that VNet register their records, and all linked VNets can resolve every record regardless of which VNet registered it, giving the mutual name resolution required.

Link the Private DNS zone to all three VNets; each link enables that VNet's VMs to resolve the zone, while autoregistration on each link auto-registers those VMs' DNS records.

Other AZ-305 domains

• Design identity, governance, and monitoring solutions — 470 questions →
• Design data storage solutions — 340 questions →
• Design business continuity solutions — 270 questions →
• All 1652 AZ-305 questions →