AZ-900: How Azure Networking Fits Together

A web application needs visitors to reach a public front end while keeping its database private. The developers also want to connect a company office to the cloud and avoid unexpected network paths between environments. Those requirements sound like one networking problem, but they are really several: segmentation, addressing, routing, name resolution, private access and hybrid connectivity. AZ-900 introduces the Azure services that fit those requirements without expecting candidates to configure enterprise routing protocols.

The fastest way to learn cloud networking is to follow packets conceptually. Where does the request originate? Which endpoint receives it? Is the destination reachable through the public internet, a private Azure network or a private connection to the office? Which name resolves to which address? Azure gives these decisions explicit service boundaries. Remembering those boundaries prevents the misconception that putting two resources “in Azure” automatically makes them privately connected.

A virtual network gives workloads an address space

An Azure Virtual Network is a foundational private networking construct for Azure resources that support virtual-network integration. It defines an address space that can be divided into subnets. Subnets organize portions of that space and provide placement boundaries for resources using network interfaces or subnet integration. Planning nonoverlapping addresses is important because future connectivity to a corporate network or a second virtual network can become difficult when the networks claim the same IP ranges.

Consider a company using an office network numbered 10.20.0.0/16. Creating an Azure network with exactly the same range may seem harmless until the business wants a VPN. Routers must decide whether a destination in that range is local or remote; overlapping ranges make reliable routing and name resolution much harder. Good planning asks which systems may need to communicate later, not just which subnets the first deployment needs this afternoon.

Subnetting does not automatically create complete isolation. Network security controls, routes and access requirements still need careful configuration. An explanation of subnets versus VLANs is useful here because cloud subnets and traditional on-premises switching segmentation address related but different parts of a network design. Treat them as concepts to understand, not interchangeable configuration objects.

Peering connects networks without merging their management

Virtual network peering enables connectivity between selected Azure virtual networks over Microsoft’s backbone. It does not turn the two networks into one resource group or one subscription, and it does not by itself eliminate the need to reason about address spaces and security rules. Peering is often a good conceptual answer when two Azure environments need low-friction private communication, provided their network design supports it.

A common architectural pattern separates shared services from application networks. A central network may host connectivity or security components, while development and production workloads use distinct virtual networks. That arrangement can make responsibilities clearer, but it does not mean every peering relationship provides transitive routing by default. If network A peers with B and B peers with C, do not assume A can automatically reach C. Hub-and-spoke designs rely on explicit routing and supporting components when traffic must traverse the center.

The AZ-700 specialization addresses hybrid and Azure connectivity in much greater detail. For AZ-900, the crucial distinction is between networking two Azure environments and connecting Azure to another location. Peering belongs to the former problem; VPN gateways and ExpressRoute can address the latter.

VPN Gateway and ExpressRoute solve different hybrid needs

A site-to-site VPN creates an encrypted tunnel between networks over an IP-based path, commonly the public internet. Azure VPN Gateway supports Azure-side VPN connectivity for applicable architectures. It may be suitable when a business wants a secure connection from an existing location without acquiring a dedicated private circuit. The design still depends on gateway capacity, compatible network devices, routing and the quality of the underlying connection.

ExpressRoute offers private connectivity through a connectivity provider rather than relying on ordinary public-internet routing for the circuit path. That can appeal to organizations with specific connectivity, reliability, compliance or predictable-network requirements. It is not the same thing as saying all traffic is encrypted automatically; private routing and encryption are distinct properties. Nor does buying a private connection cure every failure in a connected application. The service choice should follow requirements and the connected network design.

Understanding site-to-site IPsec VPN tunnels helps explain what a VPN actually protects. An encrypted tunnel can secure traffic in transit, yet applications still need authorization, availability planning and sensible endpoint exposure. Networking is a layer of the security model, not the entire model.

Public and private endpoints are not just IP labels

An internet-facing application needs a reachable public access path. A private endpoint, where supported, can provide private connectivity to a platform service from a virtual network. That matters when a storage account or database should be reachable through a controlled private network path rather than exposed through a publicly accessible endpoint. A public endpoint serves a different access model and may still be protected through appropriate authentication, access rules and transport encryption.

Do not assume that using a private endpoint is sufficient on its own. Name resolution must direct clients to the intended private address, and other network or service settings must support that path. A machine resolving the public address for a database may fail to use the private route even when a private endpoint exists. Conversely, changing DNS without configuring the necessary connectivity may produce a private address that the client cannot reach.

An effective architecture records which callers should use each access path. A customer browser may access a public website while the website uses private connectivity to a database. The same diagram can contain both access models without contradiction. Security comes from correctly limiting each path and authenticating each interaction.

DNS matters because people use names and networks route addresses

Azure DNS provides domain name hosting for supported public and private DNS scenarios. The basic job of DNS is to map names to relevant records so applications can locate services. That is not the same as forwarding a packet or granting permission to a resource. A network can be perfectly routable while an application fails because its hostname resolves to the wrong address. Cloud migrations frequently reveal this when old records remain cached or split-horizon name resolution is inconsistent.

For example, an application running on premises might need a storage service’s private endpoint address. Its resolvers must be designed to obtain the correct private DNS response, potentially through a hybrid resolution arrangement. If the workstation instead receives a public address, the observed traffic path can differ from the architectural intention. The technical specifics belong to implementation guides, but the principle is fundamental: connectivity requires both the intended route and the intended name resolution.

The mechanics of DNS caching also explain why changing a record may not fix every client immediately. Records can remain cached until their applicable time-to-live behavior permits refresh. During an incident, distinguish a network policy failure from a stale or unexpected DNS answer instead of changing firewalls reflexively.

Design the path before adding network protection

A network security group can allow or deny traffic according to defined network rules; other services can provide specialized network security and application delivery. However, a rule allowing a port says little about whether the receiving application will authenticate a caller correctly. Zero Trust principles likewise do not remove the need for routing and connectivity. A private environment can contain overprivileged applications; a public endpoint can enforce strong identity and application controls. An effective model combines network restrictions with service-level and identity safeguards.

Suppose a security team reports that a subnet cannot reach a private database. The relevant evidence starts with the actual source and destination addresses, routes, DNS responses, network rules and service configuration. Opening broad internet access would be a poor default response because it bypasses the intended private design. Similarly, an application timeout is not proof that the selected subnet mask is wrong. The symptom must be tied to the network layer that can cause it.

The practical value of understanding CIDR addressing is that it enables precise discussion of network ranges without resorting to vague “internal IP” labels. AZ-900 rarely requires a detailed subnet calculation, but candidates should know why distinct, appropriately sized address ranges matter.

Trace a customer request and an employee request separately

A customer opens the website from a phone. That request follows the site’s publicly available route, reaches the web tier and is handled by application controls. The web tier may then access a private data service. An employee at headquarters connects through a VPN or private circuit to a management workload. The two interactions can arrive at Azure through different paths and face different controls, even if they touch the same application estate. One diagram that separates them often resolves otherwise confusing service-choice questions.

In a fundamentals scenario, ask whether the desired outcome is to create an Azure address space, connect two virtual networks, connect an office, host DNS records or give private access to a platform service. Those requirements suggest different network constructs. The correct answer is usually a recognizable relationship between the problem and the service, not the most complex solution the organization could afford. More detailed routing and security engineering comes later; AZ-900 should leave you able to explain why a connectivity design makes sense.