A city automation DELETE of an FDM network object returns 4xx. The object shows isSystemDefined or is still referenced by an access rule. What should the client do first?
Select an answer to reveal the explanation.
Short Explanation
System objects and in-use objects are locked doors—retrying the same DELETE just rattles the handle. Unlink the access-rule references first, or leave system-defined objects alone.
Full Explanation
When an FDM network-object DELETE returns 4xx and the object is system-defined or still referenced by an access rule, the client must fix the precondition rather than hammer the same call. The correct first move is to unlink references from access rules (or other dependents) and to skip system-defined objects that the platform will not allow you to remove. In-use and system objects are intentionally protected so automation cannot orphan policy or delete built-ins that the threat-defense model requires.
Retrying the identical DELETE in a tight loop fails because the rejection is semantic, not a transient race you can overwhelm; loops amplify error noise and risk rate limiting without changing references. Switching to an IPS signature update and ignoring the object reference fails by changing problem domains—signature maintenance does not remove a locked network object or clear access-rule bindings. Running a packet-trace on the data plane fails because tracing observes forwarding behavior; it does not delete configuration objects from the FDM model or traffic counters.
Exam caveat: distinguish “object not found,” “in use,” and “system-defined” in the error body—each drives a different remediation path on DEVCOR-style tasks.
Operational check: GET the object and inspect isSystemDefined and reference metadata (or examine access policies for the object id); if system-defined, abort delete; if referenced, PATCH/update rules to remove the binding, then retry DELETE once and deploy.