Azure AZ-800 common mistakes
Azure AZ-800 · Understand the traps and how to avoid them.
When a scenario needs Group Policy, OU structure, Kerberos to on-prem file servers, or LDAP application binding, the candidate answers that the servers should just be joined to Microsoft Entra ID (Azure AD) and policy applied there.
The name similarity leads candidates to assume Entra ID is the cloud version of AD DS and therefore interchangeable. Under time pressure, 'join to Entra ID' feels like the modern answer, so the requirement list is never checked against what Entra ID actually provides.
What to do instead
Before choosing a directory technology, list the requirements and map them: Entra ID provides identity/SSO/MDM and no GPO, no OU-based delegation, no Kerberos/NTLM to on-prem resources, no LDAP. Entra Domain Services provides managed LDAP/Kerberos/NTLM and domain join but has a one-way sync out of Entra ID and no schema extension or Domain Admin access. On-prem or IaaS-hosted AD DS is required when you need GPO, custom schema, or full domain admin control. Practice by classifying each requirement into 'Entra ID / Entra Domain Services / AD DS'.
Using Seize-ADDirectoryServerOperationMasterRole (ntdsutil seize) to move a FSMO role off a domain controller that is temporarily offline, and then bringing that original DC back online afterward.
The exam prompt says the DC 'is not responding', which reads as an emergency. Candidates also blur role scope, so they seize a role they could have simply transferred, or seize more roles than needed.
What to do instead
Memorise the split: forest-wide are Schema Master and Domain Naming Master; domain-wide are RID Master, PDC Emulator, and Infrastructure Master. Transfer gracefully with Move-ADDirectoryServerOperationMasterRole whenever the current holder can be reached, even if degraded. Seize only when the holder is permanently gone, and never reconnect a DC whose roles were seized. Read the role name verbatim before answering.
Designing Microsoft Entra Connect with a default configuration when users' on-premises UPNs use a non-routable suffix (e.g., contoso.local), and choosing only one authentication method without justifying it against the stated constraints.
Candidates treat sync as a checkbox and skip the identity-mapping step. The .local suffix is common in diagrams, and the authentication options (password hash sync, pass-through authentication, federation) look interchangeable unless the constraints (no inbound firewall, need for on-prem password policy enforcement, existing AD FS investment) are read.
What to do instead
Check the UPN suffix first: add a routable verified domain suffix and update user UPNs, or anchor sync with the ms-DS-ConsistencyGuid/sourceAnchor and alternate login ID. Then select auth from constraints: password hash sync for simplicity and resilience, pass-through authentication when passwords must never leave on-prem, federation only when an existing AD FS/smart card requirement exists. State the trade-off explicitly in your answer rationale.
Assuming an on-premises Windows Server is automatically manageable by Azure Policy, Azure Monitor, or Azure Update Manager just because it is in the same subscription or has an Azure Arc-enabled server resource created, and overlooking outbound connectivity and resource provider registration.
Candidates who work mostly in the portal expect Azure VMs and on-prem servers to behave the same. The Arc agent install, the Microsoft.HybridCompute resource provider registration, outbound 443 endpoints, and the retired MMA / classic Update Management vs Azure Monitor Agent / Azure Update Manager distinction get skipped because they are prerequisites, not exam-question nouns.
What to do instead
Treat Azure Arc-enabled servers as a separate onboarding path: install and connect the Azure Connected Machine agent on each machine, confirm outbound 443 to the required endpoints, register the resource providers, then assign guest configuration policies or update schedules. Remember Azure Monitor Agent has replaced the legacy MMA, and Azure Update Manager has replaced the Log Analytics-based Update Management solution. If a scenario asks how to manage a machine that is not in Azure, Arc is almost always part of the answer.
Placing a multi-tier application on a single virtual machine with an availability set (or scale set) when the requirement says 'survive a datacenter failure', or resizing a running VM to an entirely different hardware family and assuming it just works.
Availability sets and availability zones both sound like 'high availability', so candidates pick whichever appears first. Similarly, candidates see the size dropdown in the portal and forget that family changes may need deallocation, and that the temporary D: drive is not persistent storage.
What to do instead
Map the requirement to the construct: availability sets give 99.95% with fault domains and update domains within one datacenter; availability zones give 99.99% across datacenters but only exist in supported regions. Deallocate a VM before moving it to a size not supported by its current hardware cluster, and never put data on the temporary disk. For two-tier apps, place each tier in its own availability construct and put a load balancer in front.
Deploying a Windows container image whose base OS version does not match the container host (for example, running a Windows Server 2022 base image on a Windows Server 2019 host) and expecting process isolation to work, or mixing Linux and Windows worker nodes inside one AKS node pool.
Candidates reason about container images as portable, which is true on Linux, and carry that assumption to Windows. The Windows container host/image version compatibility matrix and the node pool OS type restriction are rarely encountered in day-to-day work.
What to do instead
Match host and image builds for process isolation; use Hyper-V isolation when an older image must run on a newer host, and never expect a newer image to run on an older host. The Containers feature must be enabled on the host, and Docker/containerd must be installed. In AKS, OS type (Linux or Windows) is fixed per node pool, so plan multiple node pools and remember Windows node pools have additional constraints.
Assigning a static private IP such as 10.0.1.0, 10.0.1.1, or 10.0.1.3 to a VM and then being unable to explain connectivity gaps, or sizing subnets to exactly fit the VM count.
On-premises candidates carry over the convention that a /24 gives 254 usable addresses, and Azure reserves a block of addresses that does not exist in the same form on-premises. The reserved addresses are not listed anywhere in the VM creation blade.
What to do instead
Remember Azure reserves five addresses in every subnet: the first four (network address, default gateway, and two for Azure DNS) and the last (broadcast). Size subnets as required IPs plus five, and choose static addresses outside the reserved range. Also watch for overlapping address spaces before planning VNet peering or site-to-site connectivity.
Designing a hub-and-spoke topology where spokes must reach each other and answering 'enable VNet peering' alone, without adding a transit mechanism or gateway transit.
Peering is presented as the fix for connectivity, and the non-transitive nature of peering is a property, not a named option in the portal, so it is easy to miss. Candidates also forget that a VPN or ExpressRoute gateway requires a dedicated GatewaySubnet.
What to do instead
State explicitly that VNet peering is non-transitive: spoke-to-spoke traffic needs either direct peerings, a firewall/NVA in the hub with user-defined routes, or Azure Route Server. For on-premises traffic through the hub, enable gateway transit on the hub peering and use remote gateways on the spoke. Always allocate a dedicated GatewaySubnet (a /27 or larger is recommended) for the VPN or ExpressRoute gateway.
Explaining a permissions problem by looking only at NTFS permissions, or only at share permissions, and answering 'grant Modify' without checking the other layer and the default share permission.
In real environments teams often grant Full Control at the share and manage everything with NTFS, so candidates learn to look at one layer. The exam deliberately sets one layer restrictive and asks why access fails, and the 'most restrictive wins' rule is rarely stated in the scenario.
What to do instead
Always evaluate both layers and apply the effective-permission rule: when a user reaches a folder over the network, the effective access is the more restrictive of share and NTFS permissions (the exception is that Administrators can bypass share permissions locally with the Backup Operators/SeBackupPrivilege or admin shares). Remember new shares default to Everyone: Read, and standard practice is Full Control or Change at the share with granular control at NTFS.
Treating Azure File Sync as a drop-in replacement for DFS Replication and answering that it provides multi-master, bidirectional replication between branch servers with automatic conflict resolution.
Both products synchronise files across servers, so the names and topologies get conflated. Candidates also assume cloud tiering is on by default and that the sync agent only needs to be installed on one server.
What to do instead
Describe Azure File Sync accurately: a Storage Sync Service with sync groups, one cloud endpoint (an Azure file share) and one or more registered server endpoints, with the Azure file share acting as the hub; the agent must be installed and registered on every server; cloud tiering is an optional policy, not automatic. Use DFS Namespaces for a unified namespace and DFS Replication when you need server-to-server multi-master replication without Azure. Pick the tool from the requirement: cloud tiering and Azure backup integration point to Azure File Sync.