An emergency-management office automation job must read intent objects from Catalyst Center without changing them, then later create an update when operators approve. Which HTTP verb pairing is appropriate?
Select an answer to reveal the explanation.
Short Explanation
GET is looking through the glass; POST/PUT is filling out the change form after the EM director signs. DELETE-as-read or TRACE-as-write is how you break the glass and the process.
Full Explanation
Emergency-management automation that reads intent objects without changing them, then later creates an update when operators approve, should use GET to retrieve intent and POST or PUT (as the API defines) when creating or updating after approval. HTTP verb discipline separates read paths from mutating paths and supports civic change control.
Using DELETE for every read so caches refresh, then GET to write changes, inverts safe verb semantics. Using TRACE exclusively for read and write because it bypasses AAA is wrong and unsafe. Using CONNECT to rewrite intent directly in underlay TCAM is not how intent APIs work.
Exam caveat: some resources are PATCH-oriented; always follow the controller’s OpenAPI rather than assuming PUT vs POST. Operational check: dry-run GET in read-only credentials, require approval recorded in the ticket, then mutate with a write-scoped service account. Log request IDs for both read and write in the emergency-management automation audit trail. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that counters, logs, and failover behavior still match the documented design intent.