A building permits desk standardizes access switches from templates but suspects engineers applied one-off CLI. How should automation detect that drift?
Select an answer to reveal the explanation.
Short Explanation
Drift is like a stamped permit plan versus what got built on site—you have to measure the walls. Pull state through APIs and diff it to the template. Trusting vibes or burning configs every night does not find the unauthorized VLAN.
Full Explanation
Building-permits standardization from templates still suffers when engineers apply one-off CLI. Automation should retrieve intended and operational/config state via APIs or model-driven protocols and compare them to the template baseline to detect drift. Comparing desired versus actual is the core drift-detection pattern in NetDevOps.
Assuming GUI green checks mean no CLI was ever typed is naive. Only reviewing change tickets without reading device state misses untracked changes. Erasing startup-config nightly so drift cannot accumulate causes outages and is not detection.
Exam caveat: distinguish config drift from oper-state differences (interface down vs missing config). Operational check: pull running config/model state after a known CLI tweak, ensure the drift job flags it, remediate via template re-apply, and alert owners. Keep exceptions explicitly approved in the permits CMDB. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services. Re-validate after the next maintenance window that telemetry, API results, and device state still match the documented design intent. Permits-desk exceptions should expire so temporary CLI snowflakes cannot become permanent untracked state.