A city NOC client successfully GETs a Cisco site list with Cache-Control: max-age=300. What is the cache-aware optimization for the next two minutes?
Select an answer to reveal the explanation.
Short Explanation
If the bakery says the loaf stays good for five minutes, you do not buy a new one every second. Honor max-age and reuse the fresh copy—the cache control already paid for that lifetime.
Full Explanation
Cache-Control max-age advertises how long a successful GET representation remains fresh. When the city NOC client successfully GETs a Cisco site list with max-age=300, the cache-aware optimization for the next two minutes is to reuse the fresh cached representation instead of refetching unconditionally. That reduces origin load, respects the platform’s freshness contract, and keeps dashboards responsive without lying about staleness inside the advertised lifetime.
Issuing the identical unconditional GET every second fails by ignoring the freshness window the server already granted and can trigger rate limits. Deleting the response immediately because max-age forbids any local reuse fails: max-age enables reuse for that many seconds; it is not a no-store. Replacing Cache-Control with a custom vendor header before further reads fails because clients must honor standardized cache directives rather than inventing private semantics that Cisco intermediaries will not understand.
Exam caveat: max-age reuse applies to cacheable successful GETs; it does not authorize storing no-store bodies or skipping revalidation when must-revalidate/no-cache apply. Authenticated per-user responses may also be private.
Operational check: with a clock at T+120s after a max-age=300 response, confirm the client serves the stored site list without an origin GET, and that after expiry it revalidates or refetches before use.