After a civic script POSTs and DELETEs FDM network objects, traffic still matches the previous policy set. Which follow-up activates the model changes?
Select an answer to reveal the explanation.
Short Explanation
Object edits sit in the staging area until you hit deploy—like printing permits that are not active until stamped. Watch the deploy job until state is deployed.
Full Explanation
FDM REST create and delete of network objects update the staged configuration model; they do not by themselves push a new policy set onto the threat-defense data plane. After civic automation POSTs and DELETEs objects, the follow-up that activates changes is POST /operational/deploy, then GET the deploy job resource until its state indicates deployed. That deploy job is the stamp that moves pending object and policy edits into enforcement so traffic matches the new model.
Issuing RESTCONF edit-config on a YANG datastore fails this FDM-centric task: RESTCONF may exist in other Cisco automation stories, but it is not the substitute for FDM’s operational deploy workflow here. Assuming POST and DELETE take effect immediately fails the staged-vs-deployed distinction that FDM teaches explicitly—object calls can succeed while the live policy set remains unchanged. Rebooting the appliance to “flush” pending objects fails as an automation strategy: reboot is disruptive, not an API deploy, and does not correctly express pending-job semantics.
Exam caveat: deploy can fail or remain in progress; polling job state matters more than treating the deploy POST’s HTTP 2xx as final data-plane proof.
Operational check: after object mutations, POST /operational/deploy, record the job id, poll GET until state is deployed (or failed), and only then validate with a policy-looking traffic test or UI/API read of the running configuration markers your lab uses.