Near-Right Architecture — Azure Administrator (AZ-104)
Two options were architecturally valid — you picked the one that violates a constraint buried in the scenario. Read constraints before evaluating answers.
Technically sound, professionally wrong under the actual constraint
Architecture requirement: secure cross-region data replication with low-latency reads. Competing choices: geo-redundant storage with read access versus zone-redundant storage with application-layer replication. Both work in isolation. The deciding constraint is whether the scenario specifies read access from a secondary region — if it does, application-layer replication adds operational overhead that RA-GRS eliminates. Near-right answers pass the technical test but fail the professional one.
The Scenario
The question asks you to design a globally distributed web application with real-time bidirectional communication via WebSockets. Two options: Azure Front Door with backend pools, or Traffic Manager with regional Application Gateways. Both achieve global distribution. But Front Door operates at Layer 7 with HTTP/HTTPS — it supports WebSocket connections. Traffic Manager is DNS-based and does not proxy traffic at all, so it cannot maintain WebSocket connections across failovers. The trap is that Traffic Manager sounds like the "global load balancer" answer, but it only does DNS resolution, not connection proxying.
How to Spot It
- •Azure Front Door vs. Traffic Manager is a Layer 7 vs. DNS-level distinction. If the scenario needs connection proxying, SSL offloading, or WebSocket support, Traffic Manager is eliminated. If it only needs DNS-based routing with health probes, Front Door may be over-engineering.
- •Pay attention to "real-time," "bidirectional," or "persistent connections." These require a proxy-based load balancer (Front Door, Application Gateway), not DNS-only routing (Traffic Manager).
- •When both architectures distribute traffic globally, the tiebreaker is always in the connection semantics — HTTP request-response vs. persistent connections vs. raw TCP.
Decision Rules
Whether to replace imperative New-Az* resource-creation cmdlets with a single New-AzResourceGroupDeployment call targeting an ARM template, accepting the declarative model's built-in idempotency over the familiar imperative scripting pattern already in use.
Whether to assign an Azure Policy (DeployIfNotExists, CanNotDelete lock) once at the Production management group scope — which cascades to all current and future child subscriptions automatically — or to apply Resource Locks manually at each individual subscription or resource group, which satisfies the current requirement but breaks the least-effort and forward-coverage constraints.
Whether to use Entra ID dynamic group membership rules (requires P1/P2 license) or Azure PowerShell-scripted static group membership (works on free tier) when the scenario explicitly prohibits premium license spend.
Select the narrowest built-in RBAC role scoped to the subscription that grants sufficient Azure Policy management permissions without also conferring general resource write or delete rights.
When the scenario explicitly requires packet capture, hop-level path tracing, or connection-path diagnosis — not just metric dashboards — Azure Network Watcher satisfies signal-completeness; Azure Monitor Insights does not.
Whether to apply a performance-visualization tool (Azure Monitor Insights) or a network-diagnostic tool (Azure Network Watcher) when metric dashboards are clean but network-layer connectivity failures persist — the deciding constraint is diagnostic depth at the packet and flow level, not metric surface area.
Should network-isolation for the storage account be enforced at the NIC or subnet layer (NSG) or at the storage account layer (storage firewall virtual network rule backed by a service endpoint)?
Whether to configure customer-managed keys (CMK) backed by a Key Vault with RBAC authorization enabled, versus enabling only platform-managed SSE (satisfies encryption-at-rest generally but cedes key ownership) or using vault access policies (satisfies CMK but fails the RBAC authorization mandate).
Whether network isolation is enforced at the NIC layer via an NSG (leaves the storage account's public endpoint reachable from outside the VNet) or at the storage-account layer via a Private Endpoint with public-network-access disabled (removes the public endpoint entirely), where only the latter satisfies the 'no public endpoint exposure' constraint.
Select Encryption at Host (platform-enforced, covers OS disk, data disks, and temp disk) over Azure Disk Encryption (guest-enforced, excludes temp disk and requires guest-OS changes) when the compliance mandate explicitly includes temporary storage and forbids guest-level configuration.
Select the App Service network control that enforces inbound-only VNet isolation without disabling deployment slot swaps — Private Endpoints (inbound) versus VNet Integration (outbound only).
Select Private Endpoints over Service Endpoints when the constraint requires instance-level isolation of a single PaaS resource, not merely service-category backbone routing.
Domain Coverage
Difficulty Breakdown
Related Patterns