You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
Azure DNS is a hosting service for managing your domain names. A DNS zone is the container that holds all the DNS records for a specific domain, like contoso.com. Within that zone, you create individual records that tell computers how to find your resources. For example, an A record points a name like www.contoso.com to an IPv4 address, while a CNAME record can point that same name to another domain name instead. Other common records include AAAA for IPv6 addresses, MX for mail servers, and TXT for verification text.
You manage Azure DNS zones and records just like any other Azure resource, using the Azure portal, PowerShell, or the CLI. This integration means you can use Azure role-based access control to decide who can change records and view audit logs to track those changes. For security, Azure Public DNS supports DNSSEC, which adds digital signatures to DNS data to prevent spoofing attacks by ensuring the answers you get are authentic.
Azure DNS works with other Azure services to direct traffic. For instance, you can use Azure Traffic Manager for advanced routing, like sending users to the closest healthy endpoint. The DNS zone holds the record that points your domain name to the Traffic Manager profile, which then decides the best destination based on its rules. This separation means you manage the domain in Azure DNS and the traffic logic in Traffic Manager.
For hybrid networks where Azure resources need to talk to on-premises servers and vice versa, the Azure DNS Private Resolver is a key managed service. It replaces the need to run your own DNS servers on virtual machines. The resolver uses two main components: inbound endpoints and outbound endpoints. An inbound endpoint gives you an IP address inside your Azure virtual network where your on-premises DNS servers can send queries. An outbound endpoint lets your Azure resources send queries out to your on-premises or other external DNS servers.
To control where queries go, you configure a DNS forwarding ruleset. This is a collection of rules that say, "queries for the corp.contoso.com domain should be sent to this specific on-premises DNS server IP." This is called conditional forwarding. You can link one ruleset to many virtual networks, which is useful in a hub-and-spoke network design to centralize DNS management. The resolver uses the outbound endpoint to send these forwarded queries.
For internal name resolution within Azure, you use Azure Private DNS zones. These zones host records for your private domains (like private.contoso.com) and are only accessible from virtual networks you link to them, not the public internet. To make a virtual machine use a private zone, you must create a virtual network link between the zone and the VM's network. You can also enable autoregistration, which lets VMs automatically create their own A records in the private zone when they get an IP address.
Sometimes you need to use your own custom DNS servers for a virtual network, such as when joining VMs to an on-premises Active Directory domain. You specify the IP addresses of these servers in the virtual network's settings. A common setup is to have your custom server handle queries for your internal corporate domains and then forward all other queries to the Azure recursive resolver at the special IP address 168.63.129.16. This ensures VMs can resolve both internal and Azure hostnames.
DNS settings can be configured at two levels: the virtual network or directly on a network interface (NIC). The NIC-level settings always win over the network-level settings. If you enable custom DNS for a network but do not list any server IPs, Azure will ignore the setting and use its default DNS. When you change the DNS servers for a virtual network, running VMs will not see the change until they renew their DHCP lease, which you can force with a command like ipconfig /renew on Windows. Avoid setting DNS inside the VM's operating system, as Azure may overwrite it during maintenance.
For complex forwarding, like sending queries for a specific domain to a particular server, you set up conditional forwarding rules on your custom DNS servers. If using Windows Server as a forwarder, you must set the forwarding timeout to more than four seconds. This gives the Azure resolver enough time to respond and prevents it from incorrectly returning a public IP address for a private name. As a managed alternative, the Azure DNS Private Resolver simplifies this with built-in high availability and scalability. It integrates with Network Security Groups (NSGs), so you can control DNS traffic on port 53 while ensuring the resolver's necessary traffic is allowed.
The Azure Load Balancer is a central service that operates at Layer 4 of the Open Systems Interconnection (OSI) model to distribute incoming network traffic across backend resources. It acts as the single point of contact for clients, using predefined load-balancing rules and health probes to direct data flows. By managing these incoming requests, the service ensures that applications remain highly available, scalable, and responsive to user demand.
Administrators can deploy two primary types of load balancers depending on the source of the incoming traffic. A public load balancer accepts internet traffic and distributes it to virtual machines in a virtual network, while also translating private IP addresses to public ones for outbound connections. In contrast, an internal load balancer handles traffic strictly within a private virtual network or from connected on-premises systems in hybrid environments.
Azure provides load balancers in three distinct stock keeping units (SKUs) known as Basic, Standard, and Gateway. The Standard SKU is the recommended option for modern deployments because the Basic SKU is scheduled for retirement on September 30, 2025. A Standard Load Balancer utilizes a closed-by-default security design that blocks all inbound traffic unless it is explicitly permitted by security group rules.
This load balancing service supports both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) applications across millions of concurrent flows. Key use cases include establishing high availability by distributing resources across physical zones, configuring outbound network pathways, and mapping specific public ports to individual virtual machines. It also supports IPv6 traffic distribution and integrates with Azure Monitor to provide deep operational metrics.
Optimizing an Azure Load Balancer deployment requires selecting the Standard SKU to unlock advanced performance and security features. Administrators should distribute virtual machine resources across Availability Zones to protect applications against the failure of a single physical datacenter. Integrating health probes correctly ensures that the load balancer actively diverts network traffic away from any backend instance that becomes unhealthy.
When troubleshooting connection issues, administrators should use Azure Monitor to observe metrics such as Data Path Availability and Health Probe Status. If backend instances fail to respond, confirm that your network security groups permit traffic from the Azure health probe IP address, which is always 168.63.129.16. For problems where VMs cannot establish outbound connections, check for Source Network Address Translation (SNAT) port exhaustion and deploy an Azure NAT Gateway to provide more stable port management.
For specialized network designs, administrators can configure High Availability (HA) Ports to load balance all TCP and UDP traffic across every single port simultaneously. While session persistence can be enabled to keep routing a specific client to the same backend host, this setting should be used carefully because it can cause an uneven distribution of workload. Finally, enabling TCP reset on idle timeouts allows the load balancer to send clean connection closure signals directly to application endpoints.
Deploying a Standard Load Balancer ensures that public endpoints are secure by default because inbound connections are blocked until rules are explicitly created. To further shield public-facing services from malicious traffic spikes, administrators should integrate their public endpoints with Azure DDoS Protection. Additionally, setting up Azure Policy definitions allows teams to enforce configuration compliance automatically and quickly identify any drift from security baselines.
Every load balancer relies on a frontend IP configuration that serves as the single entry point for incoming client requests. This configuration can be assigned either a public or internal IP address, which establishes the load balancer's operational boundary. Behind this entry point lies the backend pool, which contains the target virtual machines or scale sets designated to process the incoming network load.
Administrators can construct backend pools using two different methods to suit their design network topology. A NIC-based pool links directly to the specific virtual network interface cards of the target virtual machines. Alternatively, an IP-based pool targets raw IP addresses directly, which offers greater flexibility when adding or removing backend resources.
To keep the system reliable, health probes constantly monitor the operational status of the backend instances. If an instance fails its health checks, the load balancer stops routing new connections to that specific resource. The routing behavior itself is determined by load balancing rules, which apply a five-tuple hash algorithm to map traffic from the frontend IP and port to the appropriate backend instances.
To manage individual machines, administrators configure inbound NAT rules to forward external traffic directly to a single virtual machine rather than the entire backend pool. This port-forwarding capability is highly effective for administrative access to specific nodes within your network. For more complex routing scenarios, utilizing HA Ports allows the system to direct all traffic across all ports to the appropriate destination.
Azure Load Balancer distributes traffic based on connections rather than packets, and understanding this distinction is key to troubleshooting. If virtual machines behind a load balancer are receiving uneven traffic, the most common cause is session persistence configured to use source persistence distribution mode. To resolve this, update session persistence to None so traffic distributes evenly across all healthy instances. Additionally, clients behind proxies might appear as a single client to the load balancer, which also causes uneven distribution because the load balancer treats all proxy traffic as coming from one source.
When virtual machines in the backend pool do not respond to traffic on the configured data port, check two primary areas. First, ensure the VM is listening on the target port by running netstat -an in the command prompt; if the port is not listed as LISTENING, configure the proper listener port. Second, network security groups might block the port or source IP. Verify the security group settings to ensure the IP address of the clients is allowed, and confirm that the load balancer infrastructure IP is not blocked.
To diagnose and resolve issues, sign in to the backend VM and check if the application is listening on the data port using netstat -an. Then, list the network security groups configured on the backend VM and ensure they allow incoming and outgoing traffic on the data port. Make sure the load balancer IP is allowed through any NSG rules, because blocking this IP will cause all health probes to fail and stop traffic from reaching the backend.
Azure Monitor provides multi-dimensional metrics that give real-time visibility into load balancer operations. Critical metrics include Data Path Availability, which measures the health of load-balancing rules' frontend IP and port combinations, and Health Probe Status, which indicates backend instance health. SYN Count metrics help detect potential security threats by tracking TCP connection attempts, while SNAT Connection Count and Used SNAT Ports metrics reveal outbound connectivity issues such as port exhaustion that leads to failed connections.
VNet flow logs are essential for analyzing traffic patterns flowing through the load balancer, helping identify anomalous behavior or security threats. By enabling these logs, you can trace packet paths and detect issues like uneven traffic distribution, often caused by misconfigured session persistence such as source IP affinity, or by rule configurations. Additionally, configure diagnostic settings to send logs to Azure Monitor, Storage, or Event Hubs for comprehensive analysis and alerting.
When investigating dropped traffic or health probe failures, start by verifying backend instance health via health probes. Ensure network security groups allow traffic from the Azure infrastructure IP for probes. For SNAT exhaustion, monitor the Used SNAT Ports metrics and consider using Azure NAT Gateway for more predictable outbound connectivity. If uneven distribution is suspected, review the distribution mode and adjust rules to balance load effectively.
Leverage Load Balancer Insights for preconfigured dashboards that visualize flow distribution, dependency views, and connection monitors. Set up Azure Monitor alerts for metrics like Data Path Availability dropping below thresholds or Health Probe Status indicating unhealthy instances. For robust security, integrate with Azure Firewall for traffic inspection and use TCP reset on idle timeouts to ensure clear connection state information. Regularly review Azure Policy controls and resource tagging to maintain compliance and governance across deployments.
The health probes are essential mechanisms used by Azure Load Balancer to determine the status of instances within a backend pool. These probes periodically send requests using configured protocols, such as TCP, HTTP, or HTTPS, to the port where the application is actively listening. An instance is marked as healthy only if it responds correctly, preventing connection attempts to failed or unresponsive services. The probe protocol must align with the application's listener, meaning an HTTP probe expects an HTTP 200 status while a TCP probe simply requires a successful connection. You can confirm the application is listening on the correct port by using commands like netstat -an directly on the backend virtual machine.
When backend instances are not receiving traffic, the issue often lies with misconfigured network security rules or application-level failures. Network security groups must permit traffic from the load balancer's IP and the health probe port. A common mistake is having a deny rule with higher priority than the default allow rule for Azure Load Balancer. Additionally, the application itself must be running and listening on the expected port. High CPU utilization on a backend VM can also prevent it from responding to probes in a timely manner, causing it to be marked unhealthy.
For persistent issues, more advanced diagnostics are required. Tools like Psping or TCPing can be used from another VM within the same virtual network to test connectivity to the probe port, helping to isolate whether the problem is network-related or specific to the target VM. Simultaneous network traces (using netsh on Windows) on both the backend VM and a test VM can capture probe packets. If incoming packets are absent on the backend, the cause is likely an NSG or user-defined route (UDR) misconfiguration. If outgoing packets are missing, the issue is likely on the VM itself, such as an application or OS firewall blocking the response.
The Azure Load Balancer is a central service that operates at Layer 4 of the Open Systems Interconnection (OSI) model to distribute incoming network traffic across backend resources. It acts as th…
The Azure Load Balancer is a central service that operates at Layer 4 of the Open Systems Interconnection (OSI) model to distribute incoming network traffic across backend resources. It acts as th…
Implement DNS Zones and Records
Implement DNS Zones and Records
Azure Load Balancer distributes traffic based on connections rather than packets, and understanding this distinction is key to troubleshooting. If virtual machines behind a load balancer are recei…
Azure Load Balancer distributes traffic based on connections rather than packets, and understanding this distinction is key to troubleshooting. If virtual machines behind a load balancer are recei…
StudyCerts
StudyCerts