A township board uses Cisco DNA Center–style intent for campus segmentation and wants automation to verify policy state. Which verification approach aligns with intent-based operations?
Select an answer to reveal the explanation.
Short Explanation
Intent controllers already know the policy you asked for—ask them through the API instead of photocopying every closet CLI. You verify the segmentation object and compliance view, not a brittle regex on VLAN names. Spreadsheets and turning policy off are not verification.
Full Explanation
Township boards using Cisco DNA Center–style intent for campus segmentation should verify policy state by querying intent/policy and assurance APIs for segmentation objects and compliance rather than depending on CLI scraping. Intent-based operations validate what the controller believes and assures, not only scattered VLAN names on switches. API verification aligns automation with the intent architecture.
Scraping show commands from every access switch and regexing VLAN names only misses controller intent objects and assurance. Ignoring controllers for monthly spreadsheet attestations from site techs is slow and weak. Disabling segmentation so there is nothing to verify abandons the security goal.
Exam caveat: assurance can lag; combine intent API reads with targeted assurance checks and know freshness SLOs. Operational check: GET segmentation policy objects, compare compliance results after a known change, and fail the pipeline on drift. Keep CLI as break-glass validation, not the primary township automation path. 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.