A city script caches a rarely changing Cisco catalog GET, then performs a PATCH on one of those resources. What is the correct cache behavior afterward?
Select an answer to reveal the explanation.
Short Explanation
Caching the printed menu helps; caching last week’s order after you already changed it does not. Stable catalog GETs are the win—after a write, do not blindly trust the pre-mutation cache.
Full Explanation
Mutations invalidate assumptions about prior GET caches. When a city script caches a rarely changing Cisco catalog GET and then PATCHes one of those resources, it must avoid blind reuse of the pre-write cache for that resource—refetch or revalidate after the mutation. Otherwise the catalog UI or downstream job continues to show pre-PATCH fields as if the write never happened.
Keeping using the pre-write cached catalog entry as authoritative without refetching fails freshness after a known local write. Caching every URL including POST/PUT/PATCH responses as if they were safe GETs fails HTTP caching rules for unsafe methods and can store non-reusable action results. Disabling caching for all catalog GETs forever once any PATCH has ever run fails by abandoning useful caching for unrelated, unchanged entries; scope invalidation to the affected resource (and documented related URLs).
Exam caveat: precise invalidation may include list URLs that embed the patched item, not only the item URL. Prefer explicit invalidation plus conditional revalidation over “never cache again.”
Operational check: after PATCH, assert the next read of that item does not return the pre-PATCH cached body without a revalidate/refetch, while an unrelated catalog entry can remain cached until its own freshness ends.