A facilities inventory poller GETs a Cisco resource and receives HTTP 410 Gone. What should the consumer do with that identifier?
Select an answer to reveal the explanation.
Short Explanation
A demolished building keeps the same street number on an old map, but driving there again will not rebuild it. HTTP 410 means the resource is gone for good—remove that ID from the poll and retry loops.
Full Explanation
HTTP 410 Gone communicates permanent removal of the target resource. When a facilities inventory poller GETs a Cisco resource and receives 410, that identifier should be dropped from further GET, pagination, and retry loops. Continuing to poll a demolished or decommissioned object wastes municipal API budget and clutters error dashboards with noise that will never resolve to a 200.
Keeping the identifier in the GET and retry queue as if a temporary 404 might reverse soon fails by concept: 410 is explicitly stronger than a maybe-temporary 404—the server asserts permanence. Applying 503-style backoff fails because Gone is not overload; waiting does not resurrect the resource. Rewriting the identifier and POSTing it again without removing it from the poll list fails the cleanup duty: you may create a new object, but the old ID must still leave the poll set or the 410 path repeats forever.
Exam caveat: not every platform uses 410; some only ever return 404—treat documented permanent-delete signals the same way. Do not auto-recreate on 410 unless a separate provisioning workflow explicitly decides to.
Operational check: confirm the poller’s datastore marks the ID retired on 410, removes it from the active queue, and that subsequent cycles no longer issue GET for that identifier.