After an overnight emergency change, a county wants to know whether the web proxy still matches the approved baseline. Which configuration-management capability should they use first?
Select an answer to reveal the explanation.
Short Explanation
Drift detection is the 'before and after' photo for municipal proxies—set the approved snapshot next to what is live. That shows whether the emergency change stuck or wandered. Verbal notes alone are not a comparison.
Full Explanation
After an overnight emergency change, the first configuration-management capability a county should use is drift detection: compare live web proxy configuration to the declared baseline and report differences. That comparison answers whether the emergency change still matches policy, partially diverged, or left residual edits. Without a systematic diff, teams argue from memory instead of from inventory.
Deleting every proxy host and rebuilding from vendor defaults without comparison destroys evidence and may reintroduce the outage that prompted the emergency change. Disabling baseline checks so emergency changes are never audited institutionalizes unreviewed production state. Relying solely on verbal handoff notes from the on-call engineer is not reproducible, not complete, and not auditable for municipal compliance reviews.
Exam caveat: drift detection reports differences; it does not by itself decide remediation. Some emergency changes are intentional and must be promoted into the baseline via review. Others must be reverted on the next converge. Ordering matters: detect and classify before mass rebuild. Also ensure the baseline itself is the approved post-change desired state, not an outdated golden file.
Operational check: run the proxy drift/compliance job against production (or a read-only check mode), triage each finding as keep-and-codify versus revert, update IaC for intentional deltas, apply or converge, and re-run detection until the county proxy reports clean against the updated baseline.