Practise vocabulary for the Pact workflow: publishing pacts, provider verification, the Pact Broker, can-i-deploy, and CI integration.
0 / 22 completed
1 / 22
After consumer tests run and generate a pact file, the next step is to ___ the pact to the Pact Broker.
Publishing the pact uploads the contract JSON to the Pact Broker, making it available for the provider to retrieve and verify. The broker stores pacts with version tags and branch information.
2 / 22
Provider verification is the process where the ___ runs the pact interactions against a real instance of the service to confirm it satisfies the contract.
Provider verification runs each interaction from the pact against a real (or realistic) provider instance. The provider sets up the declared provider state, makes the request, and checks the response matches the contract.
3 / 22
The `can-i-deploy` Pact CLI command answers the question: 'Is it safe to deploy ___ to production given the current contract verification status?'
can-i-deploy checks the Pact Broker to see if a specific version of a service has been verified by all its consumers and providers. It acts as a deployment gate, preventing releases that would break dependent services.
4 / 22
A ___ pact in Pact Broker is one that has been published by a consumer but not yet verified by the provider — it's in a provisional state.
A pending pact has been published but not yet verified by the provider. By default, pending pacts don't fail the provider's verification build — they're 'in progress' contracts that won't block the provider's pipeline.
5 / 22
When a pact verification ___, it means the provider's current implementation no longer satisfies the consumer's expected interactions.
A pact verification failure means the provider has made a change that breaks the consumer's expected contract. This should block the provider's deployment and trigger communication with the consumer team.
6 / 22
Sarah from the Consumer Team just submitted a PR to update the `UserProfileService`'s API. The PR description includes a link to a newly generated Pact file, and Mark from the Provider Team is reviewing it in code review. Mark comments: 'I've received this Pact file – it looks good, but I need to ensure our service still adheres to these interactions before we merge. Can you please run a verification against our current implementation?'
This scenario highlights the core workflow. The correct action is to use the pact-consumer verify command – this initiates the automated verification process, ensuring that the provider's implementation actually meets the consumer's expectations as defined in the Pact file. Options A and B are incorrect because they involve manual or premature publishing; Option C is misleading as the Broker doesn't automatically verify, it simply provides a mechanism for automated checks.
7 / 22
During a code review for a new API change, Emily (Consumer Team) shares a Pact file generated from the consumer's perspective. David (Provider Team), after reviewing the code, asks: 'To be absolutely sure this change doesn't break anything downstream, can we automatically verify that our service still matches this Pact?' Which action should David take to address this concern effectively?
The most robust approach is to verify the provider's implementation against the Pact file directly. This confirms that the provider's service continues to satisfy the consumer's expectations as defined in the Pact. Publishing the Pact to the consumer's pipeline (option A) introduces unnecessary duplication and potential inconsistencies – David needs to independently confirm compliance. Manually running the CLI command (option C) is a viable approach but doesn't guarantee automated verification. Requesting an update from Emily (option D) shifts responsibility and could introduce errors if the Pact file isn't accurately reflecting the latest consumer API.
8 / 22
Mark from the Provider Team is reviewing a PR submitted by Sarah (Consumer Team) that includes a new Pact file. He wants to proactively ensure the provider's service continues to meet the contract expectations after Sarah's changes. Which of the following actions would be the MOST appropriate step for Mark to take within his code review workflow?
The MOST effective action is to run a Pact verification. This proactively confirms that the provider's service still satisfies the contract after the consumer's changes. Option A is incorrect because automatic CI/CD doesn't replace manual verification for critical interactions. Option B suggests unnecessary rework and delays; it's better to confirm the existing state. Option D is too high-level – Pact verification focuses on concrete interaction confirmation, not architectural discussions.
9 / 22
Sarah from the Consumer Team just submitted a PR to update the `UserProfileService`'s API. The PR description includes a link to a newly generated Pact file, and Mark from the Provider Team is reviewing it in code review. Mark comments: 'I've received this Pact file – it looks good, but I need to ensure our service still adheres to these interactions before we merge. Can you please run a verification against our current implementation?'
This scenario highlights the core workflow. The correct action is to use the pact-consumer verify command – this initiates the automated verification process, ensuring that the provider's implementation actually meets the consumer's expectations as defined in the Pact file. Options A and B are incorrect because they involve manual or premature publishing; Option C is misleading as the Broker doesn't automatically verify, it simply provides a mechanism for automated checks.
10 / 22
During a code review for a new API change, Emily (Consumer Team) shares a Pact file generated from the consumer's perspective. David (Provider Team), after reviewing the code, asks: 'To be absolutely sure this change doesn't break anything downstream, can we automatically verify that our service still matches this Pact?' Which action should David take to address this concern effectively?
The most robust approach is to verify the provider's implementation against the Pact file directly. This confirms that the provider's service continues to satisfy the consumer's expectations as defined in the Pact. Publishing the Pact to the consumer's pipeline (option A) introduces unnecessary duplication and potential inconsistencies – David needs to independently confirm compliance. Manually running the CLI command (option C) is a viable approach but doesn't guarantee automated verification. Requesting an update from Emily (option D) shifts responsibility and could introduce errors if the Pact file isn't accurately reflecting the latest consumer API.
11 / 22
Mark from the Provider Team is reviewing a PR submitted by Sarah (Consumer Team) that includes a new Pact file. He wants to proactively ensure the provider's service continues to meet the contract expectations after Sarah's changes. Which of the following actions would be the MOST appropriate step for Mark to take within his code review workflow?
The MOST effective action is to run a Pact verification. This proactively confirms that the provider's service still satisfies the contract after the consumer's changes. Option A is incorrect because automatic CI/CD doesn't replace manual verification for critical interactions. Option B suggests unnecessary rework and delays; it's better to confirm the existing state. Option D is too high-level – Pact verification focuses on concrete interaction confirmation, not architectural discussions.
12 / 22
Sarah from the Consumer Team just submitted a PR to update the `UserProfileService`'s API. The PR description includes a link to a newly generated Pact file, and Mark from the Provider Team is reviewing it in code review. Mark comments: 'I've received this Pact file – it looks good, but I need to ensure our service still adheres to these interactions before we merge. Can you please run a verification against our current implementation?'
This scenario highlights the core workflow. The correct action is to use the pact-consumer verify command – this initiates the automated verification process, ensuring that the provider's implementation actually meets the consumer's expectations as defined in the Pact file. Options A and B are incorrect because they involve manual or premature publishing; Option C is misleading as the Broker doesn't automatically verify, it simply provides a mechanism for automated checks.
13 / 22
During a code review for a new API change, Emily (Consumer Team) shares a Pact file generated from the consumer's perspective. David (Provider Team), after reviewing the code, asks: 'To be absolutely sure this change doesn't break anything downstream, can we automatically verify that our service still matches this Pact?' Which action should David take to address this concern effectively?
The most robust approach is to verify the provider's implementation against the Pact file directly. This confirms that the provider's service continues to satisfy the consumer's expectations as defined in the Pact. Publishing the Pact to the consumer's pipeline (option A) introduces unnecessary duplication and potential inconsistencies – David needs to independently confirm compliance. Manually running the CLI command (option C) is a viable approach but doesn't guarantee automated verification. Requesting an update from Emily (option D) shifts responsibility and could introduce errors if the Pact file isn't accurately reflecting the latest consumer API.
14 / 22
Mark from the Provider Team is reviewing a PR submitted by Sarah (Consumer Team) that includes a new Pact file. He wants to proactively ensure the provider's service continues to meet the contract expectations after Sarah's changes. Which of the following actions would be the MOST appropriate step for Mark to take within his code review workflow?
The MOST effective action is to run a Pact verification. This proactively confirms that the provider's service still satisfies the contract after the consumer's changes. Option A is incorrect because automatic CI/CD doesn't replace manual verification for critical interactions. Option B suggests unnecessary rework and delays; it's better to confirm the existing state. Option D is too high-level – Pact verification focuses on concrete interaction confirmation, not architectural discussions.
15 / 22
Sarah from the Consumer Team just submitted a PR to update the `UserProfileService`'s API. The PR description includes a link to a newly generated Pact file, and Mark from the Provider Team is reviewing it in code review. Mark comments: 'I've received this Pact file – it looks good, but I need to ensure our service still adheres to these interactions before we merge. Can you please run a verification against our current implementation?'
This scenario highlights the core workflow. The correct action is to use the pact-consumer verify command – this initiates the automated verification process, ensuring that the provider's implementation actually meets the consumer's expectations as defined in the Pact file. Options A and B are incorrect because they involve manual or premature publishing; Option C is misleading as the Broker doesn't automatically verify, it simply provides a mechanism for automated checks.
16 / 22
During a code review for a new API change, Emily (Consumer Team) shares a Pact file generated from the consumer's perspective. David (Provider Team), after reviewing the code, asks: 'To be absolutely sure this change doesn't break anything downstream, can we automatically verify that our service still matches this Pact?' Which action should David take to address this concern effectively?
The most robust approach is to verify the provider's implementation against the Pact file directly. This confirms that the provider's service continues to satisfy the consumer's expectations as defined in the Pact. Publishing the Pact to the consumer's pipeline (option A) introduces unnecessary duplication and potential inconsistencies – David needs to independently confirm compliance. Manually running the CLI command (option C) is a viable approach but doesn't guarantee automated verification. Requesting an update from Emily (option D) shifts responsibility and could introduce errors if the Pact file isn't accurately reflecting the latest consumer API.
17 / 22
Mark from the Provider Team is reviewing a PR submitted by Sarah (Consumer Team) that includes a new Pact file. He wants to proactively ensure the provider's service continues to meet the contract expectations after Sarah's changes. Which of the following actions would be the MOST appropriate step for Mark to take within his code review workflow?
The MOST effective action is to run a Pact verification. This proactively confirms that the provider's service still satisfies the contract after the consumer's changes. Option A is incorrect because automatic CI/CD doesn't replace manual verification for critical interactions. Option B suggests unnecessary rework and delays; it's better to confirm the existing state. Option D is too high-level – Pact verification focuses on concrete interaction confirmation, not architectural discussions.
18 / 22
During a Slack discussion about the upcoming release of the PaymentService, Liam (Provider) mentions, 'We've just verified a new Pact file covering the CreateTransaction operation. It shows that the provider is now returning a 201 status code for successful transactions, as per the consumer's expectations.' What does Liam primarily mean when he refers to 'verifying a new Pact file'?
Liam is using 'verifying a new Pact file' to convey that the Pact file has been used by a verification tool (like Pact Verifier) to confirm the provider's service adheres to the agreed-upon contract. This process validates the interaction without requiring manual code changes; it's about automated validation, not manual adjustments.
19 / 22
While reviewing a PR update to the UserManagementService, Anya (Consumer) includes a Pact file detailing the expected response for an API call to retrieve user profiles. Ben (Provider), noticing that the generated Pact file contains a negative test case – specifically, a 404 error when searching with a non-existent ID – asks: 'Why did the Pact tool generate this failing test?'
The 404 error in the Pact file signifies a discrepancy between what the consumer *expects* (a successful response) and what the provider's service is actually returning when presented with an invalid ID. This highlights a potential issue with the provider's implementation that needs investigation – it's not a bug of the Pact tool itself, but rather a real difference in behavior.
20 / 22
During a standup meeting, David (Provider) says: 'We're using Pact to ensure our OrderService continues to behave as expected when the consumer updates their API. We've created a Pact file and are regularly running it against our builds.' What is David primarily communicating about in this statement?
David is describing Pact as a mechanism for establishing and maintaining a formal contract between the provider and consumer. The Pact file acts as this documented agreement, ensuring that changes to either side are validated against it before deployment. It's about contract-driven development, not just testing.
21 / 22
A Pact Broker contains a 'published' pact file for the ShippingService. This pact defines the expected API interaction for creating a shipment order. What is the primary purpose of 'publishing' this pact in the Broker?
Publishing a Pact file in the Broker makes it accessible to both the consumer and provider teams. This enables them to independently verify that their services are still compatible with each other – essentially creating a shared understanding and a mechanism for detecting potential breakages before they impact production.
22 / 22
Emily (Consumer Team) is explaining the Pact workflow to a new developer, Mark. She says: 'We generate a Pact file based on our API's expected behavior and then we regularly run it against our builds. This way, if anything changes in the provider's service, we'll automatically see if it's still compatible.' What is Emily highlighting about the automated verification process?
Emily is emphasizing the core benefit of Pact – automated verification. Pact Verifier automatically runs against the generated Pact file to detect any discrepancies between the consumer's expected behavior and the provider's actual implementation. This proactive approach helps catch issues early, reducing the risk of deployment failures.
What will I practice in "Pact Testing Workflow Language"?
This is an API Contract Testing exercise set. It walks through 22 scenario-based multiple-choice questions built around real usage of API Contract Testing terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 22 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the API Contract Testing vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more API Contract Testing exercises?
See the API Contract Testing exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — API Contract Testing vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.