A civic Wi-Fi portal still ships idle Meraki location-API calls “in case we need them later,” and every release must understand and patch that surface. What maintainability action fits?
Select an answer to reveal the explanation.
Short Explanation
Keeping a spare radio that nobody uses still means checking its batteries every release. Idle location-API calls are a maintainability smell—YAGNI. Delete or isolate unused integration surface.
Full Explanation
Idle Meraki location-API calls shipped in case they are needed later are a maintainability tax on a civic Wi-Fi portal. Every release must understand, patch, and not break that surface even though nobody uses it. Delete or isolate unused integration code—feature-flag it out of the production path, or remove it entirely—so the live attack and change surface stays minimal. That is YAGNI applied to platform clients.
Expanding idle calls to more unused Cisco products fails by multiplying dead weight. Leaving dead location calls in production documented as optional forever fails because optional still means tested, secured, and understood every release. Duplicating the idle client in the front-end fails by spreading unused surface to more teams and tiers.
Exam caveat: isolating behind a dark feature flag is acceptable interim hygiene; shipping always-on idle production calls is not.
Operational check: remove or gate the location client, run the release regression suite, and confirm no production traffic hits the unused Meraki location endpoints.
Unused platform surface also widens security review: tokens, scopes, and egress rules linger for idle Meraki location calls. Deleting or isolating them reduces audit load and accidental activation. Prefer resurrecting an integration from source control when a real civic requirement appears over keeping cold code paths forever warm in production releases.