The Load Balancing Decision: Load Balancer, Application Gateway, Front Door and Traffic Manager
This is the single most tested decision on AZ-305, and it collapses into two questions asked in order. First, is the requirement global or regional. Front Door and Traffic Manager operate across regions, while Application Gateway and Azure Load Balancer operate inside one. Second, does the service need to understand HTTP. Front Door and Application Gateway work at layer 7, so they can route on hostname and URL path, terminate TLS, hold sessions and run a web application firewall. Load Balancer and Traffic Manager cannot, because one works at layer 4 on TCP and UDP and the other only answers DNS queries. Answer both questions and exactly one service is left. The two remaining subtleties are worth knowing. Traffic Manager fails over more slowly than Front Door because clients keep using a cached DNS record after an endpoint goes unhealthy, so any scenario about fast global failover for web traffic wants Front Door. And when a requirement is global, non-HTTP and needs a single fixed frontend address, cross-region Load Balancer is the layer 4 answer that Traffic Manager cannot provide. Real designs frequently combine services, with Front Door at the edge and Application Gateway or Load Balancer inside each region.
Exam tip. Do not start from the features. Establish global or regional from the scenario, then whether the traffic is HTTP, and the four-way choice becomes a single answer every time. If the wording says web application and worldwide users, it is Front Door.
Choosing a Compute Platform
Compute questions on this exam reward moving as far away from managing servers as the requirements allow, and then stopping at the first option that still meets them. Virtual machines are the fallback, correct only when something genuinely reaches the machine: an unsupported operating system, kernel or driver dependencies, licensed software that must see the host, or a vendor appliance. App Service is the natural home for an ordinary web application or API in a supported runtime, giving managed patching, scaling, certificates and deployment slots with nothing underneath to operate. Azure Functions fits work that is genuinely event-driven and idles in between, triggered by a queue message, a file arriving, a timer or an HTTP call. Containers occupy the middle, offering portability and consistent packaging, and they split further into Container Instances for a single short-lived container, Container Apps for microservices that need scaling and revisions without Kubernetes knowledge, and AKS when a team really does need the Kubernetes API. The exam does not reward choosing the most powerful option. It rewards choosing the least operationally expensive one that satisfies every stated constraint, so the useful habit is to look for the constraint that eliminates the simpler choice rather than the feature that justifies the complex one.
Exam tip. Work downward from the most managed option and stop at the first one nothing in the scenario rules out. If you are choosing virtual machines, be able to point at the exact sentence that forced it.
Container Hosting: Container Instances, Container Apps and AKS
Once a design settles on containers, the platform choice is about how much of Kubernetes the team should be exposed to. Azure Container Instances runs a single container or a small group with no orchestration around it, which makes it right for a short-lived job, a build agent or a burst of processing, and wrong for anything that needs rolling updates or service discovery. Azure Container Apps is built on Kubernetes but hides it, offering scaling driven by HTTP traffic or event sources, revisions and traffic splitting for safe releases, and a managed ingress, so a microservices application gets what it actually needs without anyone learning cluster operations. Azure Kubernetes Service is for the cases where the Kubernetes API itself is the requirement: custom operators and controllers, specific node configuration such as GPU or Windows nodes, existing Helm charts and manifests, or an established Kubernetes toolchain. AKS then carries its own design decisions, including separating system node pools that run the cluster add-ons from user node pools that run workloads, spreading nodes across availability zones, choosing a private cluster when the API server must not be publicly reachable, and pairing it with Azure Container Registry for images. The recurring mistake is recommending AKS for a workload that never touches Kubernetes concepts.
Exam tip. Look for evidence that the team needs Kubernetes rather than containers. Words like operators, Helm, custom scheduling or GPU nodes justify AKS, while just needs to scale and deploy safely points at Container Apps.
Hub and Spoke Topology and Azure Virtual WAN
Almost every Azure network design ends up as some form of hub and spoke, because it lets shared services be paid for and governed once while workloads stay isolated from each other. The hub holds the things everything needs: the firewall or network virtual appliance, the gateways for VPN and ExpressRoute, DNS resolution and often shared management tooling. Each workload lives in its own spoke virtual network peered to that hub. The detail that catches people out is that peering is not transitive, so two spokes peered to the same hub cannot talk to each other through it by default. Making that work means routing spoke traffic through a device in the hub using user-defined routes, which is usually what you want anyway because it puts inspection in the path. Azure Virtual WAN is the managed version of the same idea, where Microsoft operates the hub, its routing and the connectivity between hubs, and it becomes the recommendation once the estate spans several regions or many branch sites, because building and maintaining that transit yourself stops being reasonable. The trade is control. A hand-built hub gives you complete freedom over its contents and routing, while Virtual WAN gives you far less to operate in exchange for working within its model.
Exam tip. Any question where two spokes must communicate, or where all traffic must be inspected, is testing the non-transitive nature of peering. The answer involves user-defined routes sending traffic to a firewall in the hub.
Messaging and Eventing: Service Bus, Event Grid and Event Hubs
Azure has three integration services that look interchangeable in a diagram and are not, and the distinction is what the payload means. Service Bus carries messages, meaning instructions or business records that a receiver is expected to process and that must not be lost, so it offers ordering with sessions, transactions, duplicate detection, dead-lettering and topics with filtered subscriptions. Event Grid carries events, meaning notifications that something has happened, delivered to subscribers who react, which makes it the reactive glue between Azure services and the right answer when a blob landing in storage should trigger a function. Event Hubs carries streams, meaning very high volumes of telemetry or clickstream data consumed in order by readers that keep their own position, with partitions for parallelism and consumer groups so several independent consumers read the same stream without competing. Storage queues sit underneath all of this as a plain, inexpensive queue, and the moment a requirement mentions ordering, transactions, duplicate detection or publish and subscribe, the answer moves to Service Bus. The question to ask about any integration requirement is what happens if one item is lost, because that answer separates a business message from a telemetry event immediately.
Exam tip. Let the vocabulary in the scenario decide. Order, transaction and must not be lost mean Service Bus. React when something happens means Event Grid. Millions of readings per second means Event Hubs.
Connecting On-Premises: ExpressRoute and VPN Gateway
The choice between ExpressRoute and a VPN gateway comes down to one question: may the traffic cross the public internet. ExpressRoute is a private circuit provided by a connectivity partner, so traffic never touches the internet and bandwidth and latency are predictable, which is what regulated workloads and large steady data flows need. It takes time to provision and costs more. A VPN gateway builds encrypted tunnels over the internet, which is far cheaper and can be running the same day, at the price of depending on internet conditions you do not control. Within ExpressRoute, private peering reaches resources in your virtual networks by private address, while Microsoft peering carries traffic to public endpoints of Microsoft services over the circuit instead of the internet, and Global Reach links two on-premises sites to each other through the Microsoft network. Resilience deserves explicit attention, because a single circuit through a single provider facility is a single point of failure, so the recommendation is either redundant circuits at different peering locations or a site-to-site VPN configured as a failover path. Point-to-site is a separate tool for individual devices connecting from anywhere, which is what remote administrators and developers need rather than a whole-network link.
Exam tip. Look for the words dedicated, private, predictable or consistent latency, which all point at ExpressRoute. Words about cost, speed of delivery or a temporary link point at a VPN gateway.
Service Endpoints, Private Endpoints and Private Link
Platform services such as storage accounts and Azure SQL Database are reached through public endpoints by default, and there are two very different ways to change that. A service endpoint extends your virtual network identity to the service so traffic takes the Microsoft backbone rather than the internet, and the service can then restrict access to that subnet. What it does not do is change the address: the service still answers on its public endpoint, so anything else that is allowed can still reach it from elsewhere. A private endpoint is a stronger construct. It places a network interface with a private IP from your subnet in front of the specific service instance, so the service becomes part of your address space and public network access can be disabled entirely. That also means it works from on-premises over ExpressRoute or VPN and from peered networks, which service endpoints cannot do. The cost of a private endpoint is that DNS becomes part of the design, because clients must resolve the service name to the private address, which requires a private DNS zone linked to the relevant virtual networks and a resolver or forwarder for on-premises clients. Private Link service is the same technology turned outward, letting you publish your own service behind a standard load balancer for consumers in other tenants.
Exam tip. The deciding phrase is usually about the public endpoint. If the requirement says the service must not be reachable from the internet at all, only a private endpoint with public access disabled satisfies it.
Designing Azure App Service Solutions
App Service is the default recommendation for hosting a web application or API in Azure, and the design decisions around it are about scale, network integration and release safety. An App Service plan is the compute the apps run on, and several apps sharing a plan share its resources, which is convenient and occasionally the cause of one noisy application starving another. Scaling comes in two forms that get confused: scaling up moves to a bigger plan tier and unlocks features, while scaling out adds instances and is what autoscale rules act on. Deployment slots are the release mechanism, letting you deploy to staging, warm it up and swap it into production instantly with the previous version still available to swap back, which is zero-downtime release and instant rollback without extra infrastructure. Network integration has two directions worth separating: virtual network integration governs outbound traffic from the app into your network, while a private endpoint governs inbound traffic so the app can be reached privately and its public access disabled. When the requirement is complete isolation inside your own virtual network, an App Service Environment is the single-tenant answer. For a global footprint, App Service instances in several regions behind Front Door is the standard pattern.
Exam tip. Separate the two networking questions. A requirement about the app reaching private resources is virtual network integration, while a requirement about the app not being reachable from the internet is a private endpoint.
Layered Network Security: NSGs, Azure Firewall and WAF
Azure network security is built from several controls that each answer a different question, and a good design uses them together rather than choosing between them. Network security groups are the base layer, free and stateful, applied to a subnet or a network interface and filtering by address, port and protocol, with service tags and application security groups to keep the rules readable as the estate grows. They are excellent at segmentation and useless at understanding what is inside the traffic. Azure Firewall sits in the hub as a managed, scalable appliance for centralised control, and its real value is outbound: filtering by fully qualified domain name, applying threat intelligence and logging everything in one place, with the premium tier adding TLS inspection, intrusion detection and prevention, and URL filtering. A web application firewall is a different concern entirely, protecting HTTP applications from application-layer attacks, and it lives either on Front Door for edge protection or on Application Gateway when the entry point is regional. Third-party appliances remain an option when an organisation needs a vendor's specific capability, at the cost of owning that appliance's availability and scaling. The recurring exam pattern is defence in depth: NSGs for segmentation, a firewall for egress, a WAF for the application.
Exam tip. Read what the control has to inspect. Address and port means an NSG, a destination domain name or centralised egress control means Azure Firewall, and protecting a web application from application-layer attacks means a WAF.
Migration Strategy and the Role of Azure Migrate
Migration questions are really strategy questions wearing a tooling costume. The strategies form a spectrum: rehosting moves servers as they are, which is fastest and changes nothing about how the workload runs or costs; replatforming makes targeted changes such as moving a database onto a managed service while leaving the application alone; refactoring or rearchitecting reshapes the workload around cloud services, which delivers the most and takes the longest; and retiring or replacing acknowledges that some workloads should not move at all. A good design usually mixes them, rehosting the long tail to hit a deadline while replatforming the pieces where the benefit is obvious. Azure Migrate is the tooling that makes this decidable, discovering the estate, mapping dependencies between servers so nothing is moved in isolation, and producing sizing and cost assessments, before moving servers, databases and web applications. Azure Site Recovery underpins server replication and the Database Migration Service handles databases with an online option that keeps downtime short. Azure VMware Solution is the specialist answer for a large VMware estate that must move quickly without changing its operating model, keeping vSphere intact and buying time to modernise workloads individually afterwards.
Exam tip. Let the constraint pick the strategy. A hard datacentre exit date points at rehosting or Azure VMware Solution, while a scenario emphasising reduced operational overhead is asking you to replatform onto managed services.
Designing Name Resolution in Azure
DNS is the part of a network design that gets forgotten until something quietly does not work, and private endpoints have made it unavoidable. Every virtual network has a default resolver that handles Azure-provided names, and that is enough until you introduce private endpoints or need to resolve on-premises names. Azure Private DNS zones hold the private records, and a zone only takes effect for a virtual network it is linked to, which is the single most common cause of a private endpoint that resolves to a public address and therefore behaves as if it were not there at all. When on-premises clients also have to resolve those private names, or Azure resources have to resolve on-premises ones, Azure DNS Private Resolver is the managed answer, offering inbound endpoints for queries arriving from on-premises and forwarding rules for queries heading the other way, replacing the DNS forwarder virtual machines that designs used to rely on. Public DNS is a separate concern handled by Azure DNS public zones, and a well-designed system keeps the two apart deliberately, with split-horizon behaviour so the same name resolves privately inside and publicly outside. In a hub and spoke topology, private zones are usually linked centrally from the hub so that resolution is consistent everywhere rather than configured per spoke.
Exam tip. If a scenario describes a private endpoint that is deployed but still being reached over its public address, the fault is DNS. The fix is a private DNS zone linked to the virtual network, not another network control.
Designing for Cost in Azure Infrastructure
Cost is a design constraint on this exam rather than a finance exercise, and the recommendations fall into three groups. The first is commitment: a reservation commits to a specific resource type in a region for a term and gives the deepest discount for genuinely steady workloads, a savings plan commits to an hourly spend and stays flexible across services and regions, and Azure Hybrid Benefit applies Windows Server and SQL Server licences you already own to reduce the licensing component. The second is workload shape. Spot virtual machines are dramatically cheaper and can be evicted at any moment, so they are correct for batch processing, rendering and disposable test estates and wrong for anything that must stay up. Autoscale, serverless compute tiers and consumption-based hosting all express the same idea, which is paying for what is actually used rather than for a peak that occurs rarely. The third is choosing the right service in the first place, which usually saves more than any discount: storage tiering and lifecycle rules for cold data, an elastic pool instead of many separately sized databases, and a managed service instead of virtual machines that somebody has to patch. Governance closes the loop, since tags, budgets and Azure Advisor recommendations are what make the design visible after it is deployed.
Exam tip. Match the discount to the stability described. Steady and predictable means reservations, a changing mix at a stable overall level means a savings plan, and interruptible batch work means Spot.