A housing authority drifts from IaC when helpdesk manually opens RDP; automation must catch it. What control focus is that?
Select an answer to reveal the explanation.
Short Explanation
Helpdesk opens RDP 'just this once,' and suddenly the housing tenant no longer matches the Bicep blueprint—that's drift. Automation should yell when portal edits leave the civic baseline. Enforcing drift controls with civic IaC baselines through pre-deployment deny policies is good prevention, but you won't catch the rule that's already live outside your baseline.
Full Explanation
When a housing authority helpdesk manually opens RDP and the live Azure tenant no longer matches the IaC baseline, the control focus is detecting configuration drift against civic IaC after unauthorized portal changes. Drift detection compares deployed resource properties (NSG rules, diagnostic settings, public IPs, SKUs) to the last-applied Bicep/Terraform state or to policy-compliant desired state, then alerts or remediates. For housing systems that may hold resident PII and payment integrations, an 'emergency' RDP rule left open is a lasting exposure; automation must notice the NSG delta quickly rather than waiting for the next annual audit.
Auditing Azure configuration drift against Defender posture baselines after scheduled compliance scans fails because it checks generic Defender posture best practices on a compliance scan schedule, not the live tenant against the civic IaC baseline, so it does not detect unauthorized portal drift quickly. Enforcing Azure configuration drift controls with civic IaC baselines through pre-deployment deny policies fails as a drift answer because it is a preventative guardrail on future deployments; it will not detect or reconcile an RDP rule that was already opened manually outside IaC. Validating Azure configuration drift risks against civic IaC baselines during release repository checks fails because it validates pre-release repository code, not live tenant state; it does not identify that the deployed network security configuration diverges from the approved IaC baseline after portal edits.
Exam caveat: Drift detection is complementary to preventative controls (policy deny, locked IaC pipelines). Detection alone does not stop the first bad change—it shortens mean time to awareness. Distinguish drift tools (what-if, terraform plan, Azure Resource Graph queries, policy compliance) from scheduled compliance scans that check Defender posture baselines without comparing live state to the civic IaC baseline.
Operational check: After a controlled portal NSG edit in a non-prod housing subscription, confirm automation raises a drift alert or failed compliance; measure time-to-detect; prefer auto-remediate for known-bad patterns (e.g., 0.0.0.0/0 RDP) with change tickets; and train helpdesk to request IaC PRs or break-glass procedures that still leave an auditable trail.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.