11.4 Retake Plan, Score Report, and Weak-Domain Repair

Turning a non-pass into a repair plan

AZ-104 uses a passing score of 700 or greater. Do not translate that into a simple percentage and do not compare yourself to a claimed public pass rate. Microsoft does not publish a public AZ-104 pass-rate percentage. If you do not pass, the useful output is not a label. The useful output is the score report, your memory of difficult scenarios, and the timing pressure you felt during the delivered exam.

Start the same day while the experience is still fresh. Write down the domains that felt hardest, the item types that slowed you down, and the requirements you remember misreading. Do not copy exam content or violate exam rules. Record categories instead: RBAC scope, storage firewall, VM scale, App Service slot, private endpoint DNS, effective routes, backup policy, alert rule, or Bicep dependency.

Official retake timing

Microsoft retake policy is specific. If you do not pass the first time, you must wait 24 hours before retaking. A 14-day waiting period applies between all subsequent attempts, up to five attempts. You may not take a given exam more than five times within a 12-month period from the first attempt. A passed exam cannot be retaken unless the certification has expired. Retake fees apply when applicable.

This timing should shape your plan. A 24-hour minimum does not mean a retake the next day is wise. If your result was barely below 700 and you know the cause was pacing or one domain, a short repair cycle may be enough. If several domains were weak, schedule farther out and use the waiting period productively. A rushed retake often repeats the same failure pattern with a new fee.

The weak-domain repair loop

Use a four-step loop: diagnose, rebuild, prove, and retest. Diagnose with the score report and your notes. Rebuild with hands-on tasks, not only reading. Prove the fix with validation evidence. Retest with mixed timed questions. Repeat until missed questions are mostly edge cases rather than core workflows.

For identity and governance, rebuild from principal to scope. Create a user or group, assign a role at subscription, resource group, and resource scope, then test what changes. Apply a policy and observe deny or audit behavior. Add a lock and confirm that RBAC does not override it. Create budgets and cost alerts so cost management is not just a vocabulary topic.

For storage, rebuild from client to data. Decide whether the client uses account key, SAS, managed identity, Microsoft Entra authentication, or Azure RBAC data roles. Then decide whether the network path uses public access, selected networks, service endpoint, or private endpoint. Finally decide the protection layer: soft delete, versioning, snapshots, lifecycle management, redundancy, or backup where applicable.

For compute, rebuild from deployment to operation. Read a Bicep file, deploy it, inspect dependencies, resize a VM, attach a disk, configure availability, test Bastion, configure an App Service plan, create a deployment slot, swap it, and configure backup. If containers were weak, push to Azure Container Registry and compare Azure Container Instances with Azure Container Apps.

For networking, rebuild from packet path. Name the source, destination, subnet, NIC, NSG, route table, DNS name, endpoint type, and load balancer rule. Use effective security rules and effective routes to prove your answer. If you cannot explain why peering is not automatically transitive or why private endpoint DNS matters, repair that before retesting.

For monitoring and maintenance, rebuild from signal to response. Configure diagnostic settings, send logs to a workspace, write a simple KQL query, create a metric alert, create a log alert, attach an action group, and use alert processing rules when the scenario asks for suppression. Then practice backup policy, restore, vault selection, reports, alerts, and Site Recovery decision points.

Retake schedule examples

For a near pass with one weak domain, use three days: one day of focused rebuild, one day of mixed practice, and one day of light review and exam logistics. For a broad miss, use 10-14 days: two days for identity and governance, two for compute, two for storage and networking, one for monitoring and backup, then timed mixed sets and review. Match the schedule to the failure pattern, not to emotion.

During retake preparation, do not memorize only the same missed practice questions. That creates recognition without transfer. Instead, write variations. If the missed question involved a SAS token, create a version that changes network rules. If it involved an NSG, add a route table. If it involved backup, add soft delete or restore constraints.

A retake is not a restart. It is a targeted maintenance cycle on your own skill set. Respect the official waiting periods, pay attention to the score report, rebuild the weak workflows, and retest under realistic time pressure before scheduling again.