A regional hospital runs 250 CLI-managed switches with per-device configs, slow changes, and audit drift. Leadership wants centralized intent, automated provisioning, and continuous compliance checks. Which operational difference defines controller-based networking for intent enforcement?

The correct approach captures the defining operational role of a controller: it interprets centrally expressed business intent, translates that intent into device configurations, and checks whether the deployed network continues to conform. That unifies provisioning and ongoing enforcement rather than treating configuration delivery and audit as separate, largely manual tasks. A central automation platform that provisions from intent-based configurations but checks only in scheduled audits lacks continuous compliance; drift can arise between audit runs and remain undetected. A controller that continuously flags drift but leaves engineers to apply every approved change manually provides centralized visibility and intent, but not automated provisioning or reconciliation. A configuration-management system that automates deployment and continuously checks drift can still fall short when policy intent is maintained separately per device: it lacks a shared, centralized intent model, making consistent network-wide enforcement harder. Exam caveat: centralized management alone does not establish intent-based control; distinguish a system that merely stores or pushes configurations from one that translates policy into device state and monitors conformance. Practical check: trace a change from a business-level policy through generated device configuration, then introduce a controlled deviation and verify that the system detects it and reports or reconciles it continuously.