{"id":2825,"date":"2026-10-08T18:04:43","date_gmt":"2026-10-08T18:04:43","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/?p=2825"},"modified":"2026-10-08T18:04:43","modified_gmt":"2026-10-08T18:04:43","slug":"microsoft-az-305-network-architecture-decisions","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/microsoft-az-305-network-architecture-decisions\/","title":{"rendered":"Microsoft AZ-305: Network Architecture Decisions"},"content":{"rendered":"

Network design in Microsoft AZ-305<\/a> connects every other architecture decision. Address space, connectivity, routing, name resolution, traffic inspection, private access, and global ingress determine whether workloads can communicate safely and predictably.<\/p>\n

The exam is not a routing-configuration test. It asks the architect to choose patterns that meet isolation, hybrid connectivity, availability, performance, and security requirements. A strong answer explains both the traffic path and the administrative model behind it.<\/p>\n

Begin with address space and segmentation<\/h2>\n

Plan virtual-network address ranges so they do not overlap with each other or with connected on-premises networks. Overlap complicates peering, VPN connectivity, route propagation, and future mergers. Subnets should reflect routing and security boundaries rather than arbitrary equal slices.<\/p>\n

Segmentation should align with trust and ownership. Shared services, application tiers, management components, and private endpoints may need different subnets so policies and routes remain understandable.<\/p>\n

Use hub-and-spoke when central services need shared control<\/h2>\n

A hub-and-spoke topology<\/a> centralizes services such as firewalls, DNS, gateways, and connectivity while keeping application networks separated in spokes. This can simplify governance and reduce duplicated infrastructure.<\/p>\n

The pattern is not free. Centralized traffic inspection can create bottlenecks or asymmetric routes, and every spoke-to-spoke path must be understood. Architects should verify whether traffic really needs to traverse the hub or whether direct peering is justified.<\/p>\n

Select hybrid connectivity by performance and risk<\/h2>\n

Site-to-site VPN is fast to deploy and uses the public internet, while dedicated private connectivity can provide more predictable performance and a different security posture. Redundant circuits, active-active gateways, and diverse providers may be needed for critical workloads.<\/p>\n

The mechanics behind site-to-site IPsec tunnels<\/a> are useful context, but AZ-305 focuses on the architecture decision: bandwidth, latency, reliability, encryption, cost, and how routing behaves when one path fails.<\/p>\n

Treat DNS as part of application architecture<\/h2>\n

Private endpoints, hybrid services, and multi-region applications depend on correct name resolution. Architects should decide which DNS zones are authoritative, how queries flow between cloud and on-premises environments, and how private names are resolved from every required network.<\/p>\n

A design that has perfect routing but inconsistent DNS still fails. Split-horizon requirements, forwarding rules, and resolver availability should be documented alongside IP addressing.<\/p>\n

Prefer private service access when exposure is unnecessary<\/h2>\n

Private endpoints can place service access behind private IP addresses so application traffic stays within controlled networks. Service firewalls and public-network restrictions can further reduce exposure.<\/p>\n

Private access increases DNS and routing complexity, so the architect should use it where the risk and compliance requirements justify that complexity. A private endpoint that is not resolvable from the client network provides security but not usability.<\/p>\n

Design inbound traffic for layer, scope, and resilience<\/h2>\n

Global HTTP routing, regional application gateways, transport load balancers, and reverse proxies solve different problems. The architect should identify whether the requirement is global failover, TLS termination, web-application inspection, layer-4 distribution, path-based routing, or private load balancing.<\/p>\n

Health probes must reflect application health rather than merely whether a port is open. If a backend can accept TCP connections but cannot reach its database, the load-balancer design should be able to remove it from service.<\/p>\n

Control outbound traffic explicitly<\/h2>\n

Outbound internet access is often overlooked. Large environments benefit from predictable egress addresses, centralized filtering, and clear routes so security teams know where traffic leaves the network.<\/p>\n

Firewalls should be selected for policy and inspection requirements rather than as decoration in a diagram. Effective firewall inspection and filtering<\/a> must account for traffic direction, connection state, routing symmetry, and the specific threats the design is expected to stop.<\/p>\n

Avoid asymmetric routing and hidden next hops<\/h2>\n

Custom routes, network virtual appliances, gateways, and service integrations can create multiple possible paths. Stateful security appliances may drop return traffic if the forward and reverse paths differ.<\/p>\n

Architects should trace packets hop by hop and understand effective routes. Complexity grows quickly when multiple hubs, regions, or third-party appliances participate, so route ownership and propagation rules should be explicit.<\/p>\n

Solve AZ-305 networking scenarios from the traffic flow<\/h2>\n

Use Microsoft AZ-700<\/a> concepts as deeper networking context, but keep the AZ-305 lens at design level. Identify the source, destination, protocol, required inspection, acceptable latency, and failure behavior. Then choose connectivity and security components that create the simplest valid path.<\/p>\n

The best architecture usually has fewer accidental dependencies. Clear address planning, intentional routing, resilient gateways, correct DNS, and explicit ingress\/egress controls make the network easier to secure and easier to recover.<\/p>\n

Network architecture should also include a deliberate management plane. Administrators, automation pipelines, monitoring agents, and security tools often require connectivity that application users do not. Mixing management traffic with general application paths can broaden exposure and complicate troubleshooting. Separate access patterns, controlled jump paths, and role-based administration can reduce that risk.<\/p>\n

Global applications need a decision about where traffic first enters Azure and how users are steered during degradation. DNS-based distribution, global edge routing, and regional load balancing have different failover characteristics. TTLs, health probes, client caching, and session behavior all influence how quickly traffic really moves after an incident. Marketing language such as ‘global’ is not enough; the failover mechanics matter.<\/p>\n

East-west traffic can become the dominant network pattern in microservice systems. If every internal call crosses a centralized appliance, inspection may become expensive or introduce latency. Some organizations centralize only north-south traffic while using distributed controls for internal communication. AZ-305 questions may not name this distinction directly, but the architecture should avoid hairpin routes that exist only because the diagram has a firewall in the center.<\/p>\n

Service endpoints and private endpoints solve related but different connectivity goals. A private endpoint gives the service a private address in a virtual network, while other service-integration approaches may keep the service on its public endpoint with restricted network access. The design should choose based on exposure requirements, DNS implications, and whether on-premises clients need private reachability.<\/p>\n

Network security groups and application-aware firewalls also operate at different levels. NSGs are efficient for subnet or interface-level packet filtering, while a firewall can centralize richer policy, logging, and application or threat controls. Using both can create defense in depth, but duplicated rules without clear ownership make troubleshooting difficult. Each control should have a defined purpose.<\/p>\n

Hybrid routing requires attention to advertisement and failover. Learned routes, static routes, gateway propagation, and user-defined routes can interact in unexpected ways. A preferred private circuit may fail over to VPN, but only if both paths advertise compatible prefixes and the surrounding security policy permits the alternate route.<\/p>\n

Finally, network design should be observable. Flow logs, firewall logs, connection monitoring, synthetic tests, and route inspection give operations teams evidence when users report a connectivity problem. Architecture diagrams tell teams how traffic should move; observability shows how it is actually moving during an incident.<\/p>\n

Network address planning should reserve room for growth. A design that consumes an entire address block for the first few subnets can force disruptive renumbering later. Architects should consider future spokes, private endpoints, platform services, and merger connectivity when choosing address ranges, while avoiding unnecessary over-allocation that collides with enterprise plans.<\/p>\n

Service chaining needs particular care. Sending traffic through multiple security appliances, proxies, and gateways can make the path difficult to predict and can introduce asymmetric routing. Each hop should have a clear security purpose, and the team should know which component owns the final allow-or-deny decision for a flow.<\/p>\n

Regional designs should include network failure domains. Redundant gateways in one region do not protect against regional loss, while two regions with a single on-premises circuit can still share a dependency. The architecture should trace connectivity from users and datacenters all the way to application endpoints and identify every single point that can interrupt the service.<\/p>\n

Private DNS zones require governance when many teams create private endpoints. Duplicate zones or inconsistent links can cause one network to resolve a service while another cannot. Central ownership or a standard delegation model helps keep name resolution predictable as the environment grows.<\/p>\n

Network governance benefits from reusable patterns for new applications. Standard subnet sizes, DNS integration, egress rules, private endpoint conventions, and hub connections let teams deploy quickly without inventing routing from scratch. Exceptions should be documented because unusual network paths are difficult to support during incidents.<\/p>\n

Performance requirements should include network latency and bandwidth between every important tier. A design that meets compute and database sizing targets can still fail if a cross-region link becomes the bottleneck. Synthetic tests and flow metrics help validate that the actual path meets the architecture\u2019s assumptions.<\/p>\n

Finally, architecture teams should document expected traffic flows in plain language as well as diagrams. A sentence such as ‘branch users resolve a private name, traverse the private circuit, pass the regional firewall, and reach a private endpoint’ gives operations teams a testable path. Clear flow descriptions make incident isolation much faster than relying on icons connected by unlabeled lines.<\/p>\n

The simplest valid network is usually the most supportable. Every extra hop, appliance, peering relationship, or custom route should justify itself with a requirement. Complexity that has no clear purpose increases the number of places an outage or misconfiguration can hide.<\/p>\n","protected":false},"excerpt":{"rendered":"

Network design in Microsoft AZ-305 connects every other architecture decision. Address space, connectivity, routing, name resolution, traffic inspection, private access, and global ingress determine whether workloads can communicate safely and predictably. The exam is not a routing-configuration test. It asks the architect to choose patterns that meet isolation, hybrid connectivity, availability, performance, and security requirements. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,1],"tags":[],"class_list":["post-2825","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2825","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=2825"}],"version-history":[{"count":1,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2825\/revisions"}],"predecessor-version":[{"id":3328,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2825\/revisions\/3328"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=2825"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=2825"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=2825"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}