A team wants to define firewall objects and access rules in a version-controlled repository and have a CI pipeline push them automatically to 50 Cisco Secure Firewall (FTD) devices that share a central manager. Where should the pipeline make its API calls?
Select an answer to reveal the explanation.
Short Explanation
When a choir has a conductor, you hand the sheet music to the conductor, not to each singer. The central manager owns the policy for managed devices, so the pipeline talks to its API and it does the rest. The traps are channels that were never built to carry policy.
Full Explanation
Centralized firewall managers expose REST APIs so that objects, access rules and deployments can be automated. When FTD devices are registered to a central manager, the manager is the source of truth for their policy: a pipeline can create or update network objects and access rules through the manager's API, then trigger a deployment, and the manager pushes consistent configuration to every assigned device. This fits a policy-as-code workflow in which changes are reviewed in version control, tested, and applied by the pipeline with an audit trail. Sending CLI commands to each device's console through a terminal server bypasses the manager, does not scale to 50 devices, and policy on a managed FTD is not maintained that way. A SIEM ingests logs and events for analysis; its ingestion API receives data and does not configure firewalls. SNMP is used for monitoring, and SNMP set requests are not a supported mechanism for writing firewall access control policy. Exam caveat: when a device is managed centrally, its on-box manager and API are not used for policy; the automation target is the manager. Operational check: have the pipeline authenticate to the manager, create a test object, read it back to confirm, deploy to a staging device group, and verify the deployment status before rolling out to all devices.