After a city change ticket is approved, ServiceNow writes a member into an NSX-T group through the Policy API. How should that be classified?
Select an answer to reveal the explanation.
Short Explanation
The ticket is the hall pass; the API is the door lock changing. Approval plus Policy API is still automation—it is just gated, not clicked in the UI.
Full Explanation
After a city change ticket is approved, ServiceNow writing a member into an NSX-T group through the Policy API is orchestrated Policy API automation with a human approval gate. Treat ServiceNow as the civic clerk that stamps the permit before the Policy API adds the desk to the NSX group—approval gates the change; the API still performs automated membership. Calling it a manual UI-only process that is not automation fails by concept because the membership write is machine-executed through the Policy API after approval; human approval does not erase the automation classification. Classifying it as vSphere HA admission control fails because HA admission decides cluster restart capacity, not NSX group membership. Classifying it as Carbon Black Cloud live response fails because live response is interactive endpoint investigation, not NSX Policy API group updates. Exam caveat: ITSM-orchestrated Policy API changes after approval are identified automation mechanisms for security policy; HA and Carbon Black live response are different operational planes. Operational check: approve a test ticket, confirm ServiceNow calls the Policy API, verify the NSX group member appears and Distributed Firewall intent applies, and document the approval-to-API path in the city change runbook.