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
When planning your cloud infrastructure, you define an address space using Classless Inter-Domain Routing (CIDR) notation, such as 10.0.0.0/16. An Azure Virtual Network acts as your primary isolated network boundary, and its private IP range must not overlap with other connected networks. You divide this primary address space into smaller subnets to isolate different application layers. Within every subnet, Azure reserves five IP addresses (the first four and the last one) for routing, DNS, and DHCP operations. Resources that require a constant address, such as domain controllers, use a static allocation, whereas other virtual machines use a dynamic allocation that can change when the resource deprovisions.
To connect two virtual networks securely without sending traffic over the public internet, you establish Virtual Network Peering. Peering can connect networks in the same region or across different regions via Microsoft's private global backbone. Peered networks cannot have overlapping IP address spaces, and the connection is non-transitive. This means if Network A is peered with Network B, and Network B is peered with Network C, Network A cannot communicate with Network C. Additionally, default Azure DNS does not resolve hostnames across peered networks, so you must implement an Azure Private DNS zone to enable name resolution.
Every subnet inside your virtual network must have a unique name and an IP address range that fits within the parent network. To secure these boundaries, you associate a Network Security Group (NSG) with either the subnet or individual network interfaces. An NSG acts as a packet-filtering firewall, containing security rules that allow or deny traffic. If a subnet needs outbound internet connectivity without exposing its resources to inbound threats, you can associate an Azure NAT Gateway with that subnet. For advanced routing scenarios, you can override default system routes by applying User-Defined Routes (UDRs) through a custom route table.
Creating a virtual network peering connection requires configuring bidirectional links between two virtual networks. To allow traffic originating from one network to pass through a peered network, you must enable the forwarded traffic setting. Additionally, you can configure gateway transit, which allows a spoke network to utilize a Virtual Network Gateway located in a central hub network. Once both sides of the peering relationship transition to a Connected state, resources can communicate using their private IP addresses. If you need to verify that traffic is flowing as expected, you can monitor the network connection using network testing tools.
Security across peered networks remains tight because all traffic is kept entirely within Microsoft's private network infrastructure. You control management access to these peering links using Azure role-based access control, which typically requires the Network Contributor role. Because peering is non-transitive, it acts as a security boundary that prevents unauthorized lateral movement across unrelated networks. If your security policy requires deep packet inspection, you can use service chaining to redirect traffic through a Network Virtual Appliance (NVA). You implement this path by using a user-defined route that intercepts the peered traffic and forces it through the firewall appliance.
Peering connections provide low-latency and high-bandwidth links, though actual network speeds are limited by the sizes of the communicating virtual machines. To simplify the management of multiple peered networks, organizations often implement a hub-and-spoke topology. In this architecture, all spoke networks peer with a single hub network, sharing its gateway resource to reach on-premises networks. Note that global peering has some limitations, such as not supporting direct traffic to a Basic Load Balancer on the remote network. Finally, remember that data transfers over both regional and global peering connections incur ingress and egress costs.
A Public IP Address is a dedicated Azure resource that allows inbound traffic from the internet and outbound access to external networks. You can associate a public IP directly with virtual machines, firewalls, or load balancers. When creating a public IP, you must select either the Basic or Standard SKU, which determines its features and security. The Standard SKU is highly recommended for production because it is secure by default, meaning it blocks all inbound traffic unless you explicitly allow it. For organizations that need a consistent, predictable block of addresses, a Public IP Prefix can be deployed to reserve a range of contiguous IPs.
Choosing the right SKU for your public IP address impacts both security and architectural capabilities:
You must match the SKU of your public IP address with the SKU of the load balancer it connects to. Additionally, you can configure a routing preference to direct your outbound traffic either through the high-performance Microsoft Global Network or the public Internet.
A dynamic public IP address is assigned from a regional pool and can change whenever the associated virtual machine is stopped or deallocated. A static public IP address remains fixed to the resource until you delete it, making it ideal for services that rely on DNS records or SSL certificates. For internal private IPs, dynamic allocation assigns the next available IP in the subnet, while static allocation lets you choose a specific address. Developers often use dynamic IPs for non-critical dev/test workloads to save on costs. Production systems, however, depend on static IPs to ensure external clients can reliably reach the hosted services.
Azure automatically creates system routes to handle default traffic flow between your subnets, peered networks, and the internet. To control this path, you can define custom routing policies by creating a route table with custom rules. When deciding which route to use, Azure applies the Longest Prefix Match (LPM) algorithm to select the most specific destination. If two routes have matching prefixes, Azure prioritizes routes in a strict order: first User-Defined Routes, then Border Gateway Protocol (BGP) routes, and finally system routes. This priority order allows you to configure forced tunneling, which redirects all internet-bound traffic to an on-premises network or firewall.
To set up a custom route, you first create a route table and then define individual routes inside it. For each route, you must specify an address prefix and select a next hop type, such as Virtual Appliance, Virtual Network Gateway, or Internet. After defining the routes, you associate the entire route table with one or more subnets to apply the rules. You can combine these routing tables with network security groups to control both the path and the permission of network traffic. To confirm that your custom routing works, you can view the effective routes of a virtual machine's network interface.
Routing traffic through a central network virtual appliance requires enabling IP forwarding on the appliance's network interface. Once enabled, you create a custom route with the next hop set to the private IP of the appliance, and then associate this table with your source subnets. In hybrid cloud environments, you can use forced tunneling to redirect all outbound internet traffic to your on-premises network via a virtual network gateway. If you are managing multiple virtual networks, you can use Azure Virtual Network Manager to automate and enforce routing policies across your entire environment. This centralized management tool helps you maintain consistent routing rules across many subscriptions and regions.
Standard diagnostic commands like ping are often blocked inside Azure virtual networks, meaning you must use alternative tools. For testing name resolution inside web apps, you can use tools like nameresolver.exe to see if your DNS settings are correct. DNS failures are often caused by misconfigured private zones or rules that block access to the Azure virtual IP 168.63.129.16. For hybrid connections, you should confirm that your virtual network gateway is in a Succeeded state and that its BGP routes are propagating. Tools such as tcpping and Test-NetConnection are helpful for verifying that specific network ports are open and responding.
Network security groups filter traffic using a 5-tuple rule set, and a single misplaced deny rule can block your entire application. For inbound connections, Azure processes subnet-level security rules before processing network interface rules. For outbound connections, this order reverses, processing network interface rules first. To troubleshoot blockages, you should inspect the effective security rules on the resource to find any conflicting permissions. If you use Azure Firewall, ensure that your network rules and application rules do not conflict, and verify that IP forwarding is enabled on any network virtual appliances.
Azure Network Watcher is a dedicated suite of tools designed to help you troubleshoot and monitor your cloud network. Its Connection Monitor tool tracks network performance and latency between endpoints over time to find intermittent connection drops. If you need to test if a security rule is blocking a specific packet, IP Flow Verify will check the rules and pinpoint the exact block. You can use the Next Hop tool to see where traffic is being sent, which helps you identify misconfigured user-defined routes. For deep packet analysis, you can run a Packet Capture on a virtual machine to collect raw data for troubleshooting.
A Network Security Group acts as a stateful firewall, meaning that when it allows traffic in one direction, it automatically permits the return traffic. You can associate an NSG with an entire subnet, an individual network interface, or both to create a multi-layered security barrier. Rules are processed in order of priority from 100 to 4096, where lower numbers take precedence and stop further evaluation once a match is found. If you do not associate an NSG with a subnet or interface, Azure will block all default inbound traffic to resources that have public IP addresses. To simplify rule management, you can use Service Tags to represent IP address ranges for specific Azure services.
An Application Security Group (ASG) allows you to group virtual machines based on their application role rather than their IP addresses. For example, you can group your virtual machines into logical tiers like web servers, business logic, or databases. This approach allows you to write simple network security rules that apply to entire application groups, making your security policies easier to manage and scale. To use this feature, you create an ASG and then associate it with the network interfaces of your virtual machines. This grouping ensures that your security policies remain consistent, even when you add or remove virtual machines from your application tiers.
Creating effective network security rules requires defining the source, destination, protocol, and port ranges for your network traffic. You can use augmented security rules to group multiple ports and IP addresses into a single rule, which helps keep your NSG organized. Additionally, service tags can be used to dynamically allow traffic to and from Microsoft services without needing to manage individual IP ranges. When you apply an NSG to a subnet, the rules apply to all virtual machines within that subnet boundary. If you apply the NSG directly to a network interface, the rules only affect that specific virtual machine.
Azure evaluates network security rules by comparing their priority numbers, starting with the lowest number first. For inbound traffic, the subnet-level NSG is evaluated first, and if allowed, the network interface NSG is evaluated second. Outbound traffic reverses this flow, requiring permission from the network interface NSG first before reaching the subnet-level NSG. Default rules exist with the lowest priority to allow basic internal communications, but any custom rule you create will override them. If you use Azure Virtual Network Manager, its security admin rules are evaluated before standard NSG rules, establishing a firm organizational security baseline.
Configuring inbound and outbound rules allows you to precisely control which services can communicate with your virtual machines. When creating an inbound rule, you specify parameters like the destination port, such as port 22 for SSH or port 3389 for RDP. Outbound rules are configured similarly, allowing you to restrict which external networks or services your virtual machines can access. Once you define these rules, you associate the NSG with your subnet to apply the traffic rules across your resources. Regularly auditing these rules ensures that you do not leave management ports open to unauthorized external traffic.
To quickly verify if your network security rules are working as intended, you can use the diagnostic tools in Azure Network Watcher. The IP Flow Verify tool allows you to simulate a packet exchange to see which specific security rule is allowing or blocking your traffic. You can also view the effective security rules for any running virtual machine to see a consolidated list of all active policies. To track and audit network traffic, you can enable NSG Flow Logs to record traffic decisions and send the data to an Azure Storage account. For a more visual analysis of your network traffic, you can integrate these flow logs with Traffic Analytics.
Azure Bastion is a fully managed service that provides secure administrative access to your virtual machines without exposing them to the public internet. You deploy the Bastion host within a dedicated subnet named AzureBastionSubnet, which must have an IP address prefix size of at least /26. The Bastion host connects to a public IP address using the Standard SKU to receive incoming management traffic over secure port 443. Once deployed, administrators can connect to virtual machines using SSH or RDP directly through their web browser. To secure this connection, you must attach an NSG to the Bastion subnet that permits inbound HTTPS traffic and outbound management traffic.
If users encounter connection errors or black screens when using Bastion, you should use the Connection Troubleshoot tool in Network Watcher to isolate the issue. Common connection problems are caused by client-side firewalls blocking web sockets or missing rules in the Bastion subnet's NSG. If your virtual machines use Just-In-Time (JIT) VM Access, you must assign the proper roles to ensure the Bastion service can request temporary access. To support high-traffic environments, you can scale your Bastion deployment up to 50 instances if you use the Standard SKU. To audit administrative sessions, you can enable BastionAuditLogs or use the Premium SKU's session recording feature.
Azure Bastion secures your management path by keeping your virtual machines completely isolated from public internet access. You can control who can use the Bastion service by configuring role-based access control with Microsoft Entra ID. Users need the Reader role on the target virtual machine, its network interface, the virtual network, and the Bastion resource itself. For high-security environments, you can use the Premium SKU to deploy a private-only Bastion host that does not require a public IP address. To maintain security compliance, you should monitor your Bastion connections using Azure Monitor and Microsoft Defender for Cloud.
Virtual Network Service Endpoints provide a secure way to connect your virtual network resources directly to Azure PaaS services over the Microsoft backbone. When you enable a service endpoint on a subnet, the traffic to the destination service is kept off the public internet, which improves security. This configuration extends your virtual network's identity to the target Azure service, allowing you to restrict access so the service only accepts traffic from your specific subnets. Service endpoints are a simple, no-cost security option that can be applied to core services such as Azure Storage and Azure SQL.
Enabling a service endpoint changes the routing path of your traffic at the network layer, directing it over the Microsoft backbone network. This routing change causes the target Azure service to see the traffic as originating from the private IP of your virtual machine rather than a public IP. You configure these endpoints at the subnet level, meaning that all virtual machines within that subnet will automatically use the optimized route. DNS resolution still returns the public IP address of the service, but the network layer handles the private routing. To allow this traffic, you must register the specific resource providers, such as Microsoft.Storage, within your Azure subscription.
Understanding the differences between service endpoints and private endpoints is crucial for network security design:
Service endpoints can carry a minor risk of data exfiltration because users could potentially transfer data to unauthorized accounts on the same service. Private endpoints prevent this risk by restricting connectivity to one specific resource instance. While service endpoints are free and simple to manage, private endpoints incur additional costs and require custom DNS configurations.
Private Endpoints utilize Azure Private Link technology to connect your virtual network to Azure PaaS services using a private IP address. This connection ensures that your management and data traffic remains entirely on the Microsoft backbone network, reducing the risk of exposure to the public internet. You can use network security groups and application security groups to filter traffic to and from your private endpoints. To apply these security rules, you must enable network policies on the subnet where the private endpoint is deployed. Private endpoints also allow secure access from on-premises networks using a VPN or an Azure ExpressRoute connection.
Because Azure PaaS services use public domain names, you must configure your DNS settings so that these names resolve to your private endpoint's IP address. If you use Azure-provided DNS, you can link an Azure Private DNS zone to your virtual networks to handle these records automatically. In a hub-and-spoke network design, you typically link a single private DNS zone in the hub network to all peered spoke networks to ensure consistent resolution. If you need to resolve these names from on-premises systems, you must deploy a DNS forwarder or use the Azure DNS Private Resolver service.
Deploying a private endpoint involves creating a network interface in your virtual network that maps directly to an Azure PaaS resource. To secure your setup, you should disable public network access on the target PaaS resource so that it only accepts traffic from your private endpoint. This configuration ensures that your data transfers remain secure and compliant with corporate security guidelines. You can monitor and audit the data flow through your private endpoints using Azure Monitor and network logging tools. By replacing service endpoints with private endpoints, you gain precise control over your cloud security boundary.
Azure DNS is a hosting service that allows you to manage and resolve domain names using Microsoft's global infrastructure. A DNS zone is a container that holds the records for a specific domain name, such as contoso.com. Within this zone, you create records such as A records to map hostnames to IPv4 addresses, or CNAME records to alias one domain name to another. You can manage your DNS zones using standard Azure administration tools, allowing you to secure access using role-based access control. Additionally, Azure Public DNS supports DNSSEC to protect your name resolution from cache poisoning and spoofing attacks.
For hybrid networks that require name resolution between cloud and on-premises environments, you can implement the Azure DNS Private Resolver. This managed service uses inbound endpoints to receive DNS queries from on-premises networks, and outbound endpoints to forward queries to external DNS servers. You manage these forwarding behaviors by configuring a DNS forwarding ruleset, which contains rules that redirect specific domain queries to your local servers. This service integrates with your virtual networks and eliminates the need to run and maintain custom DNS virtual machines. To resolve private domains within Azure, you can link an Azure Private DNS zone to your virtual networks.
If your virtual machines need to join an on-premises domain, you can configure custom DNS settings on your virtual network. When you specify custom DNS server IPs, your virtual machines will use those servers for name resolution instead of the default Azure DNS. If you change these DNS settings on an active virtual network, the running virtual machines will not receive the update until they renew their DHCP lease. To avoid connection drops, you should configure your custom DNS servers to forward unresolved queries to the Azure recursive resolver at the virtual IP 168.63.129.16.
An Azure Load Balancer operates at Layer 4 of the OSI model to distribute incoming network traffic across a backend pool of resources. You can deploy a public load balancer to distribute internet traffic to virtual machines, or an internal load balancer to manage traffic within private networks. The Standard SKU is the recommended option for modern deployments because the Basic SKU is scheduled for retirement. A Standard Load Balancer is secure by default, meaning it blocks all inbound traffic unless you create explicit rules to allow it. This service helps ensure that your applications remain highly available and responsive to user demand.
To maximize application availability, you should distribute your virtual machines across multiple Availability Zones behind a Standard Load Balancer. Correctly configuring health probes is essential, as they tell the load balancer to stop sending traffic to any backend instance that becomes unhealthy. If you experience connectivity issues, check that your network security groups allow traffic from the health probe IP address 168.63.129.16. For outbound connection failures, monitor your resources for SNAT port exhaustion and consider deploying an Azure NAT Gateway to handle outbound traffic.
Every load balancer configuration begins with a frontend IP, which serves as the single entry point for all incoming client traffic. Behind this frontend IP is the backend pool, which contains the network interfaces or IP addresses of the target virtual machines. You use load balancing rules to define how traffic from the frontend IP and port should be distributed to the backend pool. Additionally, you can configure inbound NAT rules to forward external traffic directly to a specific virtual machine for administrative access. Health probes constantly monitor the backend pool to ensure that traffic is only sent to active, responsive hosts.
If traffic is distributed unevenly across your backend virtual machines, check if your load balancer's session persistence is set to source IP affinity. If you need even traffic distribution, you should change the session persistence setting to None. If your backend virtual machines are not responding to traffic, verify that your application is actively LISTENING on the correct port. Additionally, inspect your network security groups to ensure they are not blocking the load balancer's infrastructure IP or the clients' source IPs.
You can use Azure Monitor to track key load balancer metrics, such as data path availability and health probe status. Monitoring these metrics helps you identify issues like SNAT port exhaustion, which occurs when too many outbound connections are attempted simultaneously. You can also enable VNet flow logs to analyze traffic patterns and detect potential security threats or misconfigured rules. If you need a comprehensive view of your load balancer's health, you can use the Load Balancer Insights dashboard to visualize traffic flow and dependencies.
Health probes are the primary mechanism used by the load balancer to determine if your backend instances are healthy or unhealthy. These probes test your application using protocols like TCP, HTTP, or HTTPS, and they expect a successful response to keep sending traffic to that instance. If a virtual machine stops responding to these probes, the load balancer will automatically redirect new connections to other active virtual machines. To troubleshoot persistent probe failures, you can use tools like Psping or network traces to isolate whether the issue is caused by a guest firewall, an NSG, or an application crash.
Network Security Groups (NSGs) act as a virtual firewall that filters traffic for Azure resources using a set of security rules. Each rule uses a five-tuple system—source, source port, destination…
Network Security Groups (NSGs) act as a virtual firewall that filters traffic for Azure resources using a set of security rules. Each rule uses a five-tuple system—source, source port, destination…
Create and configure virtual networks and subnets
Create and configure virtual networks and subnets
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 creat…
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 creat…
StudyCerts
StudyCerts