Azure AZ-900 Fundamentals Exam

Understanding Azure Virtual Networks

Azure Virtual Networks (VNets) are essential for creating isolated and secure network environments for your Azure resources. VNets allow you to segment your network into subnets, which can be used to organize and secure your resources. Each subnet can have its own network security group (NSG) rules, which control the inbound and outbound traffic. Additionally, Azure Virtual Network Manager helps you manage and enforce security policies across your organization by using security admin rules that take precedence over NSG rules. Virtual network peering is a feature that enables you to connect VNets, allowing resources in different VNets to communicate with each other as if they were in the same network. This can be done within the same region or across different regions, known as global virtual network peering. Peering connections are private and do not require a public IP address, ensuring secure communication between VNets. Azure DNS provides name resolution for your resources within a VNet. You can manage DNS settings and specify custom DNS servers for your VNets. Azure DNS supports the availability aspect of the "CIA" security triad, ensuring that your resources are always reachable. Additionally, Azure Private Link allows you to access Azure services privately over a private endpoint, keeping your traffic within the Microsoft Azure backbone network and away from the public internet. VPN Gateway and ExpressRoute are two options for connecting your on-premises network to your Azure VNets. A VPN Gateway uses encrypted traffic over a public connection, while ExpressRoute provides a dedicated private connection facilitated by a connectivity provider. Both options ensure secure and reliable connectivity between your on-premises infrastructure and Azure.

In summary, Azure Virtual Networks provide a robust and flexible way to manage and secure your network resources in the cloud. By using features like subnets, NSGs, virtual network peering, Azure DNS, Private Link, VPN Gateway, and ExpressRoute, you can create a secure and efficient network environment tailored to your organization’s needs.

Examine Azure Virtual Subnets

Azure virtual subnets are essential components within a Virtual Network (VNet) that help segment the network into smaller, manageable sections. Subnets allow you to organize and secure network traffic by dividing the VNet into multiple sub-networks. This segmentation is crucial for managing and isolating resources, enhancing security, and optimizing performance within your Azure environment. When configuring virtual network peering, it’s important to note that a virtual network cannot be moved if it is part of a peering. To move a virtual network, you must first delete the peering, move the network, and then recreate the peering. Virtual network peering enables resources in different virtual networks to communicate with each other as if they were in the same network, maintaining the same bandwidth and latency. Peering can be established between virtual networks in the same or different subscriptions, and even across different Azure deployment models. However, peering is not transitive, meaning if you peer VirtualNetwork1 with VirtualNetwork2, and VirtualNetwork2 with VirtualNetwork3, VirtualNetwork1 and VirtualNetwork3 will not automatically communicate. You must create an explicit peering between them or use a Network Virtual Appliance (NVA) in a hub network. Azure DNS and custom DNS servers are necessary for name resolution in peered virtual networks, as default Azure name resolution does not work across peered networks. Additionally, resources in peered virtual networks within the same region can communicate with the same latency and bandwidth as if they were in the same virtual network, without any extra bandwidth restrictions. Finally, there are nominal charges for ingress and egress traffic that utilizes virtual network peering. Understanding these costs and the specific requirements and constraints of peering is essential for effective network management in Azure.

Evaluate Azure VPN Gateway and ExpressRoute

Azure offers two primary solutions for connecting on-premises networks to Azure: Azure VPN Gateway and ExpressRoute. Both services provide secure and reliable connectivity, but they differ significantly in their use cases and performance characteristics. Azure VPN Gateway uses the public internet to create secure connections between on-premises networks and Azure. It is suitable for scenarios where cost is a significant factor, and the performance requirements are moderate. VPN Gateway supports site-to-site, point-to-site, and VNet-to-VNet connections, making it versatile for various connectivity needs. However, because it relies on the public internet, it may experience variable latency and bandwidth. ExpressRoute, on the other hand, provides a private connection between on-premises networks and Azure, bypassing the public internet. This results in more reliable, faster, and secure connections with lower latency. ExpressRoute is ideal for mission-critical applications that require consistent performance and higher security. It supports connections from an any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection through a connectivity provider at a co-location facility.

In summary, Azure VPN Gateway is a cost-effective solution for secure connectivity over the public internet, suitable for less demanding applications. ExpressRoute offers superior performance and security for critical applications by providing private, dedicated connections to Azure. Understanding the specific needs of your applications and network will help determine the most appropriate solution.

Explore Azure DNS

Azure DNS is a hosting service for DNS domains that provides name resolution using Microsoft Azure infrastructure. This service translates domain names into IP addresses, allowing users to access websites and services easily. By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services, ensuring a seamless integration with your existing Azure environment. One of the key benefits of Azure DNS is its ability to manage DNS resolution within virtual networks (VNets). This integration allows for efficient traffic management and routing within Azure environments. You can specify DNS servers for a VNet, and these settings will be applied as the default DNS servers for all virtual machines (VMs) within that network. This ensures that all resources within the VNet can communicate effectively using domain names rather than IP addresses. Azure DNS also supports the availability aspect of the "CIA" security triad, which stands for Confidentiality, Integrity, and Availability. By ensuring that DNS services are always available, Azure DNS helps maintain the reliability and accessibility of your applications and services. Additionally, Azure DNS Private Resolver enables querying of Azure DNS private zones from on-premises environments and vice versa, without the need for VM-based DNS servers.

In summary, Azure DNS plays a crucial role in providing domain name resolution for Azure resources, integrating seamlessly with VNets, and ensuring efficient traffic management and routing within Azure environments. By leveraging Azure DNS, organizations can enhance the availability and reliability of their services while maintaining a unified management experience across their Azure infrastructure.

Analyze VNet Peering

Virtual Network (VNet) Peering in Azure allows you to connect two virtual networks, enabling resources in different VNets to communicate with each other as if they were within the same network. This connection provides low-latency, high-bandwidth connectivity without the need for a VPN. VNets can be peered within the same region or across different regions, and even across different subscriptions, provided they have non-overlapping IP address spaces. When setting up VNet peering, it’s important to note that a virtual network cannot be moved if it is part of a peering. To move a VNet, you must first delete the peering, move the VNet, and then recreate the peering. Additionally, resources in one VNet cannot communicate with the front-end IP address of a basic load balancer in a globally peered VNet, though standard load balancers are supported. Peering can be established between VNets created through the Resource Manager deployment model or between a Resource Manager VNet and a classic deployment model VNet. However, peering is not possible between two VNets created through the classic deployment model. For VNets created through Resource Manager, peering must be configured for each VNet in the peering relationship, and the status will show as "Initiated" until both peerings are configured, at which point the status changes to "Connected." It’s also important to understand that VNet peerings are not transitive. This means that if you have peered VirtualNetwork1 with VirtualNetwork2, and VirtualNetwork2 with VirtualNetwork3, there will be no direct connectivity between VirtualNetwork1 and VirtualNetwork3. To enable communication between them, you must create an explicit peering or use a network virtual appliance (NVA) in a hub network. Lastly, while VNet peering allows for seamless communication between VNets, it does not support default Azure name resolution across peered VNets. To resolve names, you must use Azure Private DNS or a custom DNS server. Additionally, there is a nominal charge for ingress and egress traffic that utilizes VNet peering.