AZ-305 · Compute and Networking

Exam domain: 25–30%

The exam loves “which compute service” and “how would you connect on-prem to cloud” questions. Have a picture in your head for both.

Compute — the decision tree

flowchart TD
  start([Workload?])
  start -->|Containerized microservices, need orchestration| aks[AKS]
  start -->|Simple web app / API, want managed platform| appservice[App Service]
  start -->|Serverless, event-driven| funcs[Functions / Container Apps]
  start -->|Legacy / lift-shift Windows or Linux| vmss[VM Scale Sets]
  start -->|Batch / HPC| batch[Azure Batch]

The trade-off you should memorize

Service	Control ↑	Ops burden ↓	Cold start	Sweet spot
VMSS	Full OS control	High	N/A	Legacy, custom kernels, VMs at scale
AKS	K8s API	Medium	Pod startup	Microservices, portable workloads
Container Apps	Container + Dapr	Low	Cold start possible	Serverless containers, events
App Service	App code + config	Low	Warm slots	Web apps, APIs
Functions	Function code	Lowest	Cold start	Event handlers, glue

Rule of thumb

If the scenario mentions existing containers but says “no Kubernetes team”: Container Apps. If it says “many services + service mesh + fine control”: AKS.

Hub-spoke topology

Most AZ-305 network questions want a hub-spoke answer. Draw it before you read the options:

flowchart LR
  subgraph OnPrem[On-prem DC]
    er[ExpressRoute / S2S VPN]
  end
  subgraph HubVNet[Hub VNet]
    fw[Azure Firewall]
    bastion[Bastion]
    dns[Private DNS zones]
  end
  subgraph SpokeA[Spoke: Prod]
    aks2[AKS]
    sql1[SQL MI]
  end
  subgraph SpokeB[Spoke: Non-prod]
    aks3[AKS test]
    sql2[SQL DB]
  end
  er --> fw
  fw --> aks2
  fw --> aks3
  fw --> sql1
  fw --> sql2

Why hub-spoke

• Egress choke point — one Azure Firewall / NVA to audit and control outbound.
• Shared services — DNS, Bastion, Log Analytics live in the hub, not each spoke.
• Peering scales linearly — each spoke peers only to the hub, not to every other spoke.

Private endpoints — the exam favorite

Public endpoint vs Service endpoint vs Private endpoint

• Public endpoint — PaaS service on the public internet with IP firewall rules. Not private.
• Service endpoint — VNet subnet extended to the PaaS service over the Azure backbone. Still uses the service’s public FQDN. Simple, but not truly on-VNet.
• Private endpoint — a NIC inside your VNet with a private IP for the PaaS service. DNS resolves the FQDN to that private IP. This is the answer 9/10 times on AZ-305.

Don't forget Private DNS zones

Private endpoints without a linked privatelink.database.windows.net (etc.) zone will resolve to the public IP — defeating the point. Automate the DNS zone with Policy DeployIfNotExists.

Connectivity choices

Site-to-Site VPN

• IPsec/IKEv2 tunnel over the public internet.
• Cheap. Slow-ish. High jitter.
• Use for: small offices, non-critical hybrid.

ExpressRoute

• Private circuit via a Microsoft partner.
• SLA-backed, low latency, up to 100 Gbps.
• Use for: primary hybrid connectivity, hybrid AD, data replication.
• Global Reach connects two ER circuits directly (site-to-site through Azure backbone).

Virtual WAN

• Managed hub-spoke service. Azure hosts the hub — you attach VNets + branches.
• Use for: many branches, SD-WAN integrations, global mesh.

Loosely-related exam pitfalls

Do not confuse

• AKS API server public endpoint — put it behind Private Cluster (private endpoint) or an authorized-IP allow-list. Never leave it wide open in prod.
• NSG vs Azure Firewall — NSGs are stateful L4 rules on a subnet/NIC. Firewall is centralized L4–L7 with TLS inspection and threat intel.
• Front Door vs Application Gateway — Front Door is global (edge). App Gateway is regional. Combined? Sure — Front Door for global routing, App Gateway per region for WAF + L7.