Two municipal teams plan to integrate a license-renewal service with a payments service. They intend to code both implementations first and “document the URLs later.” Which API-first correction should they make?
Select an answer to reveal the explanation.
Short Explanation
API-first is like agreeing on the permit form fields before either office builds its counter workflow. The contract is the integration surface. Coding first and documenting later hides coupling and breaks callers on every release.
Full Explanation
API-first integration for license-renewal and payments means agreeing on the published contract before implementations harden so each municipal team can ship behind a stable interface. Coding both sides first and “documenting URLs later” lets accidental shapes calcify, forces rework when teams finally compare notes, and delays the moment independent deployability becomes real. A shared contract first keeps each implementation replaceable without surprising the other team.
Sharing a single deployable binary so neither team needs an interface abandons service boundaries and recreates a monolith release train. Relying on undocumented private method calls between packages in one process is in-proc coupling, not an integration contract between services. Skipping contracts and discovering endpoints by scanning production traffic each week treats production as a reverse-engineering lab and guarantees brittle consumers.
Exam caveat: API-first is about stabilizing the published interface early; it is not an API Gateway deployment-object quiz (that belongs elsewhere on the exam).
Operational check: publish the request/response or event schema, generate or stub consumers against it, and only then harden implementations—verify each team can release against the contract without sharing a binary or scraping production.