Existing lock-lab Key Vaults remain Non-compliant for diagnostic settings even after a DeployIfNotExists policy assignment is live. What does the security engineer need so already-deployed vaults become compliant?

DeployIfNotExists and Modify evaluate existing lock-lab Key Vaults against the assignment, but they do not silently rewrite non-compliant resources overnight. Bringing already-deployed vaults into compliance for diagnostic settings requires an assignment managed identity with rights to perform the deployment or modification, plus a remediation task that applies the effect to existing resources. New creates may be steered by Policy going forward; historical Non-compliant vaults need that explicit remediation path.

Relying only on a Deny effect fails by concept because Deny blocks non-compliant create or update operations; it does not retrofit diagnostic settings onto vaults that already exist. A Bicep redeploy of every vault template with no Policy remediation fails as the Policy-native answer: manual redeploy can work operationally but is not what the exam expects when DeployIfNotExists remediation exists. Removing the assignment managed identity so Policy can “evaluate without privileges” fails because evaluation may still occur, yet DeployIfNotExists/Modify remediation cannot deploy without an identity that has the needed permissions.

Exam caveat: distinguish evaluation (compliance state) from remediation (fixing existing resources)—DeployIfNotExists without remediation leaves Non-compliant vaults unchanged. Operational check: confirm the assignment has a system- or user-assigned managed identity with rights on the vaults or resource group, start a remediation task, and verify diagnostic settings appear and compliance moves to Compliant for the previously Non-compliant Key Vaults.