Azure AZ-720 common mistakes
Azure AZ-720 · Understand the traps and how to avoid them.
Treating Azure Backup failures as a storage problem and re-running the job without checking whether the Recovery Services vault's soft-delete or the VM agent is the actual cause.
Candidates memorize backup policy settings but forget that most failed backups trace to the guest agent being unresponsive, a locked resource group, or the storage account being firewalled off from the vault.
What to do instead
Before retrying, verify VM agent status, confirm the vault has network line of sight to the storage account, and check for delete locks on the resource group. Then re-run and confirm the recovery point appears rather than assuming success.
Diagnosing a failed Site Recovery replication by checking only the replication policy, ignoring the mobility service and the cache storage account.
The portal shows a generic 'critical' health state, and candidates jump to policy thresholds when the real fault is the mobility agent not being installed or the cache account throttling.
What to do instead
Inspect the replicated item's health errors, confirm the mobility service extension is installed and running on the source VM, and verify the cache storage account is in the same region and not throttled.
Assuming a VPN gateway is misconfigured when an on-premises connection drops, without first checking the gateway subnet size and the local network gateway address space.
Tunnel-down errors look identical whether the cause is a policy mismatch, an undersized GatewaySubnet, or overlapping address spaces, so candidates pick one cause and stop.
What to do instead
Work through the checklist in order: GatewaySubnet has adequate free IPs, local network gateway prefixes exactly match on-premises subnets, no address space overlap with the VNet, then shared key and IKE policy.
Troubleshooting ExpressRoute circuit peering by verifying the circuit status but not the Azure private peering route table and the connection's authorization state.
The circuit can show 'Enabled' while private peering is down or the ExpressRoute connection to the gateway is provisioning, and candidates stop at the circuit-level status.
What to do instead
Check private peering state, then the ExpressRoute connection status to the virtual network gateway, then the effective routes on a subnet to confirm on-premises prefixes are learned.
Blaming the App Service plan for an app that returns 500 errors, instead of pulling the container or platform logs and checking app settings and connection strings first.
Scale and plan metrics are prominent in the portal, so candidates reach for scaling when the actual fault is a missing app setting, a bad connection string, or a startup timeout.
What to do instead
Enable and read App Service logs and the log stream, verify app settings and Key Vault references resolve, and confirm the startup command completes within the configured timeout before touching scale.
Treating a SQL Database connection failure as a credentials problem without checking the server firewall, private endpoint, and whether the client resolves the public or private FQDN.
Login failed errors surface the same way for firewall blocks, private endpoint DNS gaps, and wrong passwords, and candidates reset credentials instead of tracing connectivity.
What to do instead
Test with the fully qualified server name, confirm the client IP is allowed or the private endpoint DNS resolves, and check whether public network access is disabled. Only then validate credentials.
Debugging a Conditional Access block by disabling the policy entirely rather than reading the sign-in log's failure reason and the applied policy list.
The user-facing error is generic, and disabling the policy appears to 'fix' it, but candidates then cannot explain which condition was unmet or propose a targeted remedy.
What to do instead
Open the sign-in log entry, read the Conditional Access tab for the specific policy and result, and check device compliance, location, and client app conditions before recommending a scoped exclusion or policy change.
Assuming a managed identity failure is a permissions issue without confirming the identity is assigned and the token endpoint is reachable from the workload.
Access denied responses from downstream services look like RBAC gaps, but the identity may not be enabled, or the workload may be outside the resource that hosts the identity.
What to do instead
Confirm the identity type is assigned to the correct resource, verify the role assignment scope, and test token acquisition from the workload itself before adjusting RBAC.
Diagnosing an unreachable VM by checking NSG rules only, while ignoring effective routes, the guest OS firewall, and whether the NIC has a valid IP configuration.
The NSG blade is the most familiar control, so candidates stop once it looks permissive and miss user-defined routes sending traffic to an appliance or a failed guest firewall.
What to do instead
Use network watcher to test IP flow and next hop, review effective routes and effective security rules on the NIC, then check the guest firewall and the NIC's IP configuration state.
Troubleshooting a VM connectivity failure by restarting the VM before verifying boot diagnostics and the serial console output.
Restarting feels productive, but it destroys the evidence of a boot failure, a failed extension, or a disk attachment problem that diagnostics would have shown.
What to do instead
Capture boot diagnostics and serial console output first, check extension provisioning status, and confirm the OS disk is attached and the VM agent is reporting before any restart.