AZ-500 Case Studies | NetForge Cloud Learning

Case 1 · Identity & Access

The Break-Glass Account That Wasn't

A break-glass account was locked out during a P1 identity incident — at the worst possible time.

Scenario

Contoso's Identity team configured a Conditional Access policy requiring MFA for all users and all cloud apps. A P1 identity incident triggered — the Entra ID MFA service was degraded. Administrators attempted to use the break-glass account to restore access. The break-glass account was blocked by the same MFA CA policy and could not sign in.

The break-glass account had previously been excluded from the MFA policy, but a colleague had recently removed the exclusion "to tighten security."

Root Cause

Break-glass account exclusion was removed from the CA policy — it was subject to the same MFA enforcement as regular users
No process for reviewing break-glass account CA policy exclusions before changes
No second break-glass account as a backup

Fix & Controls

Exclude break-glass accounts from ALL CA policies — especially MFA and sign-in risk policies
Break-glass accounts should be cloud-only Entra ID accounts (not hybrid — not dependent on on-premises AD)
Store break-glass credentials in a physical safe, not in any digital secret store
Configure alerts: alert when break-glass accounts sign in (they should NEVER sign in in normal operations)
Maintain TWO break-glass accounts in separate administrative units

Exam Takeaway

Break-glass accounts MUST be excluded from all CA policies. An excluded user in an Include group is still excluded (CA Exclude > Include). Break-glass accounts should trigger alerts on any sign-in. They are the last line of defence for emergency access.

Case 2 · Identity & Access

The PIM Role That Silently Never Activated

A security engineer thought they had Global Admin — they didn't.

Scenario

A security engineer needed to perform an emergency remediation requiring Global Administrator access. They activated their PIM-eligible Global Admin role via the PIM portal, received a success toast notification, and proceeded to the task — only to find they could not make the required changes. A colleague checked the engineer's role assignments and confirmed Global Admin was not active.

Root Cause

The PIM activation was configured to require approval from another PIM role administrator
The approval request had not been actioned — the activation was in "Pending Approval" state
The "success" toast shown was for submitting the activation request, not for the approval being granted
No alert configured for pending PIM approvals

Fix & Controls

Always verify PIM activation status in the "My roles → Active assignments" view — not just the toast notification
Configure email/Teams alerts for pending PIM approval requests, especially for critical roles
Define SLA for PIM approval responses for emergency scenarios
Consider whether approval is necessary for break-glass scenarios — some organisations use no-approval for break-glass roles with compensating alert controls

Exam Takeaway

PIM activation with approval requirement: the role is NOT active until the approver grants it. Submitting the activation request ≠ having the role. PIM-activated eligible assignments appear in the user's Active roles view — if not there, the activation failed or is pending.

Case 3 · Secure Networking

Private DNS Zone: The Peering Blind Spot

Spoke VNets could not resolve private endpoints after hub-spoke migration.

Scenario

Fabrikam migrated to a hub-spoke network topology. Private Endpoints were created in the hub VNet for Azure Storage and SQL Database. Private DNS Zones (privatelink.blob.core.windows.net and privatelink.database.windows.net) were created and linked to the hub VNet. VMs in the three spoke VNets (peered to hub) continued to resolve the public IP addresses of the storage accounts and databases — they could not reach the private endpoints.

Root Cause

Private DNS Zone VNet links are NOT transitive through VNet peering
The zones were only linked to the hub VNet — spoke VNets had no link
DNS queries from spoke VM → spoke VNet's DNS resolver → no zone link found → public DNS returned → public IP resolved

Fix & Controls

Option A (simple): Link the Private DNS Zones to each spoke VNet explicitly
Option B (enterprise): Deploy Azure Private DNS Resolver in the hub — forward DNS queries from spokes to the hub's resolver which is authoritative for the private zones
Option C (best practice for large orgs): Use Azure DNS Private Resolver with forwarding rules — eliminates per-VNet zone links

# Link zone to each spoke VNet
az network private-dns link vnet create \
  --resource-group rg-dns \
  --zone-name "privatelink.blob.core.windows.net" \
  --name "link-spoke1" \
  --virtual-network spoke1-vnet \
  --registration-enabled false

Exam Takeaway

Private DNS Zone VNet links are NOT transitive through VNet peering. In a hub-spoke topology, each spoke must be explicitly linked to the Private DNS Zone — or use Azure DNS Private Resolver for centralised resolution.

Case 4 · Compute, Storage & Databases

Key Vault Access Mode Migration Outage

A planned migration from Access Policy to RBAC mode caused a 3-hour outage.

Scenario

Woodgrove Bank decided to migrate 12 Key Vaults from Vault Access Policy mode to Azure RBAC mode (best practice for new workloads). The operations team switched each vault to RBAC mode during a maintenance window. Within minutes, 6 application services began reporting 403 Forbidden errors when accessing secrets and keys. The migration had broken all applications that relied on access policies.

Root Cause

When a Key Vault is switched to RBAC mode, all existing access policies are immediately and silently ignored
The team had not created equivalent RBAC role assignments before switching
No pre-migration testing was performed in a non-production environment

Fix & Controls

Before switching: create all necessary RBAC role assignments (Key Vault Secrets User, Key Vault Crypto User, etc.) on the vault for all identities that currently have access policies
Test in non-production: switch a non-prod vault first, verify all application access works before switching production
Have a rollback plan: switch back to Access Policy mode and restore policies if RBAC mode causes issues

# Assign Key Vault Secrets User to an app's managed identity
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee-object-id <managed-identity-principal-id> \
  --assignee-principal-type ServicePrincipal \
  --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<vault-name>

Exam Takeaway

Key Vault Access Policy and RBAC mode are mutually exclusive. Switching to RBAC mode IMMEDIATELY ignores all access policies. RBAC role assignments must be created BEFORE the switch. These two models cannot coexist on the same vault.

Case 5 · Security Operations

The Secure Score That Wouldn't Move

A security team spent a week fixing recommendations — the score barely changed.

Scenario

Adventure Works' security team targeted improving their Defender for Cloud Secure Score from 62% to 75%. They identified the "Manage access and permissions" control (worth 8 points) and fixed 9 of the 10 failing recommendations over 5 days. At the end of the week, the Secure Score had not changed for that control. The team were frustrated — they had fixed 90% of the issues.

Root Cause

Defender for Cloud Secure Score uses an all-or-nothing model per security control
ALL recommendations in a control must pass before the control's points are awarded
Fixing 9/10 recommendations earns 0 points for the control — the same as fixing 0/10
The remaining failing recommendation was on a resource that was in a different resource group managed by another team

Fix & Controls

Fix ALL recommendations in a control to earn the points — prioritise completing controls, not partial fixes
For the one remaining recommendation managed by another team: use a Policy Exemption with justification and expiry date, OR engage the other team to fix it
Strategy: choose controls with fewer failing recommendations first for quick wins (all pass easier)
Use the "Potential score increase" column in Defender for Cloud to prioritise controls by impact

Exam Takeaway

Secure Score = all-or-nothing per control. Points = 0 if ANY recommendation is failing in that control. Points = maximum when ALL recommendations pass. No partial credit. Strategy: complete entire controls, not individual recommendations in isolation.

Case 6 · Security Operations

The DeployIfNotExists Policy That Did Nothing

500 VMs stayed non-compliant for weeks after a policy was assigned.

Scenario

Northwind Traders assigned an Azure Policy with DeployIfNotExists effect to install the Azure Monitor Agent on all VMs. The policy assignment was made on a Monday. On Friday, the compliance report showed 500 VMs still non-compliant — none had the AMA installed. New VMs created after Monday were compliant. The 500 pre-existing VMs remained unchanged.

Root Cause

DeployIfNotExists automatically remediates newly created resources going forward from the policy assignment date
EXISTING non-compliant resources are NOT automatically remediated — they require a manually created Remediation Task
No Remediation Task had been created after assigning the policy

Fix & Controls

Create a Remediation Task from the policy assignment — this iterates through all non-compliant resources and triggers the deployment logic
The policy assignment's managed identity must have the appropriate RBAC role (e.g., Contributor or specific role) on the affected resources
Monitor the Remediation Task progress in Azure Policy → Remediation → Remediation Tasks

# Create a remediation task via Azure CLI
az policy remediation create \
  --name "remediate-ama-install" \
  --policy-assignment <assignment-id> \
  --resource-discovery-mode ReEvaluateCompliance \
  --resource-group <rg-name>

Exam Takeaway

DeployIfNotExists auto-remediates NEW resources from the policy assignment date onwards. Existing non-compliant resources require a Remediation Task to be manually created. The policy managed identity needs appropriate RBAC to perform the deployment action on target resources.