A civic firewall automation job must create network objects on a threat-defense device managed by Firepower Device Manager. What is the correct first hop before any object call?
Select an answer to reveal the explanation.
Short Explanation
FDM hands you a gate pass first—the password-grant token—then every object call shows that Bearer badge. Pasting Basic auth onto /object/networks skips the ticket booth.
Full Explanation
Civic firewall automation against Firepower Device Manager must obtain an API session before mutating network objects. The correct first hop is to POST to /api/fdm/latest/fdm/token (or the versioned /api/fdm/vN/fdm/token) with grant_type password plus username and password, then carry Authorization: Bearer with the returned access token on later object calls. That password-grant token exchange is the documented FDM REST gate; object endpoints expect the Bearer, not a one-shot Basic challenge on every write.
Sending HTTP Basic credentials directly on every POST to /object/networks fails the token workflow: FDM’s REST surface for this task is token-then-Bearer, and treating every object call as Basic login skips the required hop and commonly fails auth. Completing a browser three-legged OAuth grant against Webex and reusing that Bearer on FDM fails by identity and platform—Webex user tokens do not authenticate the on-box FDM API. Calling Meraki Dashboard with X-Cisco-Meraki-API-Key and treating the response as an FDM session fails the same boundary: Meraki org keys never mint FDM access tokens.
Exam caveat: token URLs are versioned under /api/fdm/…; “latest” versus vN matters for lab reproducibility, and tokens expire so clients must refresh rather than cache forever.
Operational check: POST the token endpoint, confirm a JSON access_token, immediately GET a harmless read (or GET /object/networks) with Authorization: Bearer, and only then run create/delete automation.