LEARN. PRACTICE. GROW.Define the outcome of each control
A baseline should say what it aims to prevent, detect, or correct. Deny can block applicable future requests without making existing resources compliant. DeployIfNotExists can support installing missing configuration, but evaluating historical resources does not equal running a remediation task. For each requirement, identify population, effect, executing identity, and outcome evidence. The committee can then distinguish assigned policy, corrected resource, and operational capability actually available. A dashboard percentage needs context about scope and evaluation time.
Prepare the identity executing correction
An API-created assignment can have a managed identity while still lacking roles needed for deployment. roleDefinitionIds describes required permissions, but do not treat the list as evidence of existing grants. Confirm principal, scope, and action before the task. If the definition starts creating another resource type, also review grants for the existing identity. Use a representative pilot to observe AuthorizationFailed or unintended effects. Broadening dashboard-viewer access does not resolve a missing permission for the executing identity.
Manage exceptions with deadlines and ownership
A bounded exemption can represent a temporary risk decision for a legacy resource. Record justification, scope, owner, compensating controls, and closure deadline. On expiry, the resource is not magically reconfigured; check compliance and required correction. Renewal should be an explicit decision with evidence of what prevented closure. Avoid removing an entire assignment to accommodate a local exception. That would remove protection from resources outside risk acceptance and make actual state harder to explain.
Distinguish ARM protection and data protection
A CanNotDelete lock can protect management-plane resource deletion while authorized data operations remain functional. If the requirement prevents report deletion during retention, assess appropriate data controls rather than only the account lock. The same reasoning applies to RBAC and Policy: a role allowing an action is not an exemption from an applicable deny. In the design, state which API and object are protected. That precision avoids promising protection the chosen mechanism does not provide.
Show that logs arrive and can be used
Created diagnostic settings are configuration evidence. To demonstrate observability, produce an allowed synthetic event, allow the appropriate window, and verify category, destination, required content, and query access. Use the RUN identity or an approved equivalent. An empty query can reflect the wrong category, scope, time window, ingestion, or permissions; avoid changing everything at once. Include the diagnostic query, collection owner, and response to observability failure during an incident in handover.
Connect FINOPS to the continuity commitment
An automatic cost action should distinguish production, reserve, and recovery resources. An unloaded standby can be intentional. If rebuilding it takes thirty-five minutes and RTO is twenty, stopping it changes an essential plan assumption. The PM should present cost, risk, alternatives, and rehearsal evidence for an informed decision. A budget alert is not an instantaneous spending cap and does not itself decide what can stop. Define operational exceptions and recovery from the automation itself before broad activation.
The assignment exists, but its managed identity lacks the deployment grant. After correcting it in a pilot, RUN confirms a synthetic destination event using its own identity.
Common pitfalls
Treating roleDefinitionIds as a grant; considering expiry remediation; using a lock as WORM; accepting configured logs without ingestion; stopping an unloaded standby.
Related topics: Governance and least privilege · FINOPS and continuity
A control meets its objective only when scope, identity, execution, and outcome can be demonstrated.
Reference: Policy remediation · AZ-305 objectives 2026-04-17