A permits service cannot be exercised without a live Meraki controller, so every change is expensive. Which maintainability property should the design add?
Select an answer to reveal the explanation.
Short Explanation
If you can only practice fire drills during a real fire, drills get rare and pricey. Inject the platform client so tests can fake a 429 or 500. That test seam is a maintainability property of the design—not a CI-pipeline topic.
Full Explanation
A permits service that cannot run without a live Meraki controller is expensive to change and fragile to test. Maintainability needs a substitutable platform client injected behind an interface so automated tests can fake 429, 500, timeouts, and payload shapes without lab gear. That seam lets developers prove error handling and business logic on every commit.
Requiring production controller access on every developer laptop fails on security, cost, and reproducibility. Hard-wiring a Meraki client singleton so tests always hit the real API fails by making CI dependent on lab availability and quota. Skipping automated checks for weekly manual lab clicks fails by slowing feedback and missing regressions.
Exam caveat: fakes must model realistic platform errors; a mock that only returns 200 teaches little about resilience.
Operational check: run the unit or integration suite with a fake Meraki client injecting 429 and 500 and confirm assertions pass with no network calls to a real controller.
Dependency injection of the Meraki client is the maintainability property; CI wiring is how you exercise it. With a fake, you can assert that a 429 surfaces a retry-friendly error to the permits UI and that a 500 does not leak stack traces. Without that seam, every change waits on lab controllers and flaky networks.