Practise vocabulary for integrating contract testing into CI/CD: deployment gates, can-i-deploy, cross-team coordination, and verification workflows.
0 / 22 completed
1 / 22
A contract ___ in CI/CD prevents a service from being deployed if its pact verification is failing.
A deployment gate (quality gate) is a CI step that blocks a deployment unless specific conditions are met. For contract testing, the gate checks that all contracts are verified before allowing deployment.
2 / 22
The Pact `can-i-deploy` command is typically run ___ in the pipeline — before the actual deployment step.
can-i-deploy is a pre-deployment gate that queries the Pact Broker to confirm all contract verifications are passing for the version being deployed. If any verification fails, the deployment is blocked.
3 / 22
When a provider CI pipeline detects a failing pact verification, the correct response is to ___.
A failing pact verification should block the provider's deployment — the provider has made a breaking change. The provider team must either fix the change or negotiate an update with the consumer team.
4 / 22
Bi-directional contract testing (available in Pactflow) works by comparing the ___ from both sides rather than running live verifications.
Bi-directional contract testing compares the provider's OpenAPI spec against the consumer's Pact contract statically, without running a live provider. This is faster and works well when providers already have an OpenAPI spec.
5 / 22
'Our pipeline triggered your verification build' in cross-team contract testing means the consumer's pact publication caused the ___ to run a new verification.
The Pact Broker can send webhooks to the provider's CI when a new pact is published, triggering a provider verification build automatically. This creates a feedback loop where consumers instantly know if their new contract is satisfied.
6 / 22
During a sprint retrospective discussing recent deployment issues, David explains: "We've been using Pact to ensure our payment service and its consumer align on event schemas. However, we're still experiencing sporadic verification failures despite consistently publishing events from the provider side. It seems like the consumer isn't always reacting as expected.", What is the *most* crucial next step to investigate this issue, considering the context of contract testing within a CI/CD pipeline?
Hint:** Think about how Pact verifies consistency and potential drift.
The correct answer is option 2. While frequent verification runs can help detect drift, they don't address the root cause of inconsistent behavior. The core principle of Pact is ensuring *consistent* event schemas between provider and consumer. Therefore, investigating changes in the consumer's logic or potential schema drift on the provider side is the most critical step to diagnose why the verification isn't always passing – a frequent check doesn't solve a fundamental misalignment.
7 / 22
During a code review of the new order processing microservice, Mark pointed out a potential issue: 'Our Pact consumer is consistently failing verification after we've updated the event schema. We publish the `OrderCreated` event with a `productId` field, but the consumer now reports it as invalid because the schema has changed to include a `productID` field.' Lisa replies, 'I ran `pact-consumer verify` and it passed locally.' What is the *most* likely explanation for this discrepancy?'
This scenario highlights the critical importance of synchronizing Pact schemas across all environments – especially within CI/CD. Even though `pact-consumer verify` passed locally, it's only testing against the local broker version. The consumer needs to be updated with the latest schema from the provider's Pact broker to pass verification consistently. The other options represent potential issues but don't directly explain why a locally passing verification fails in production.
8 / 22
During a standup meeting, Alex reported: "We've implemented Pact contract testing for our user authentication service. We publish events when a user logs in, and the consumer verifies that these events conform to the expected schema. However, we're seeing intermittent failures in our CI pipeline, even though the provider consistently publishes login events."
Intermittent verification failures often point to transient network issues or flaky infrastructure. While schema drift can cause problems, a stable network connection is usually the first thing to investigate when dealing with sporadic pipeline errors. Options C and D represent potential root causes but are less likely than a temporary connectivity problem in a CI/CD environment.
9 / 22
During a sprint retrospective discussing recent deployment issues, David explains: "We've been using Pact to ensure our payment service and its consumer align on event schemas. However, we're still experiencing sporadic verification failures despite consistently publishing events from the provider side. It seems like the consumer isn't always reacting as expected.", What is the *most* crucial next step to investigate this issue, considering the context of contract testing within a CI/CD pipeline?
Hint:** Think about how Pact verifies consistency and potential drift.
The correct answer is option 2. While frequent verification runs can help detect drift, they don't address the root cause of inconsistent behavior. The core principle of Pact is ensuring *consistent* event schemas between provider and consumer. Therefore, investigating changes in the consumer's logic or potential schema drift on the provider side is the most critical step to diagnose why the verification isn't always passing – a frequent check doesn't solve a fundamental misalignment.
10 / 22
During a code review of the new order processing microservice, Mark pointed out a potential issue: 'Our Pact consumer is consistently failing verification after we've updated the event schema. We publish the `OrderCreated` event with a `productId` field, but the consumer now reports it as invalid because the schema has changed to include a `productID` field.' Lisa replies, 'I ran `pact-consumer verify` and it passed locally.' What is the *most* likely explanation for this discrepancy?'
This scenario highlights the critical importance of synchronizing Pact schemas across all environments – especially within CI/CD. Even though `pact-consumer verify` passed locally, it's only testing against the local broker version. The consumer needs to be updated with the latest schema from the provider's Pact broker to pass verification consistently. The other options represent potential issues but don't directly explain why a locally passing verification fails in production.
11 / 22
During a standup meeting, Alex reported: "We've implemented Pact contract testing for our user authentication service. We publish events when a user logs in, and the consumer verifies that these events conform to the expected schema. However, we're seeing intermittent failures in our CI pipeline, even though the provider consistently publishes login events."
Intermittent verification failures often point to transient network issues or flaky infrastructure. While schema drift can cause problems, a stable network connection is usually the first thing to investigate when dealing with sporadic pipeline errors. Options C and D represent potential root causes but are less likely than a temporary connectivity problem in a CI/CD environment.
12 / 22
During a sprint retrospective discussing recent deployment issues, David explains: "We've been using Pact to ensure our payment service and its consumer align on event schemas. However, we're still experiencing sporadic verification failures despite consistently publishing events from the provider side. It seems like the consumer isn't always reacting as expected.", What is the *most* crucial next step to investigate this issue, considering the context of contract testing within a CI/CD pipeline?
Hint:** Think about how Pact verifies consistency and potential drift.
The correct answer is option 2. While frequent verification runs can help detect drift, they don't address the root cause of inconsistent behavior. The core principle of Pact is ensuring *consistent* event schemas between provider and consumer. Therefore, investigating changes in the consumer's logic or potential schema drift on the provider side is the most critical step to diagnose why the verification isn't always passing – a frequent check doesn't solve a fundamental misalignment.
13 / 22
During a code review of the new order processing microservice, Mark pointed out a potential issue: 'Our Pact consumer is consistently failing verification after we've updated the event schema. We publish the `OrderCreated` event with a `productId` field, but the consumer now reports it as invalid because the schema has changed to include a `productID` field.' Lisa replies, 'I ran `pact-consumer verify` and it passed locally.' What is the *most* likely explanation for this discrepancy?'
This scenario highlights the critical importance of synchronizing Pact schemas across all environments – especially within CI/CD. Even though `pact-consumer verify` passed locally, it's only testing against the local broker version. The consumer needs to be updated with the latest schema from the provider's Pact broker to pass verification consistently. The other options represent potential issues but don't directly explain why a locally passing verification fails in production.
14 / 22
During a standup meeting, Alex reported: "We've implemented Pact contract testing for our user authentication service. We publish events when a user logs in, and the consumer verifies that these events conform to the expected schema. However, we're seeing intermittent failures in our CI pipeline, even though the provider consistently publishes login events."
Intermittent verification failures often point to transient network issues or flaky infrastructure. While schema drift can cause problems, a stable network connection is usually the first thing to investigate when dealing with sporadic pipeline errors. Options C and D represent potential root causes but are less likely than a temporary connectivity problem in a CI/CD environment.
15 / 22
During a sprint retrospective discussing recent deployment issues, David explains: "We've been using Pact to ensure our payment service and its consumer align on event schemas. However, we're still experiencing sporadic verification failures despite consistently publishing events from the provider side. It seems like the consumer isn't always reacting as expected.", What is the *most* crucial next step to investigate this issue, considering the context of contract testing within a CI/CD pipeline?
Hint:** Think about how Pact verifies consistency and potential drift.
The correct answer is option 2. While frequent verification runs can help detect drift, they don't address the root cause of inconsistent behavior. The core principle of Pact is ensuring *consistent* event schemas between provider and consumer. Therefore, investigating changes in the consumer's logic or potential schema drift on the provider side is the most critical step to diagnose why the verification isn't always passing – a frequent check doesn't solve a fundamental misalignment.
16 / 22
During a code review of the new order processing microservice, Mark pointed out a potential issue: 'Our Pact consumer is consistently failing verification after we've updated the event schema. We publish the `OrderCreated` event with a `productId` field, but the consumer now reports it as invalid because the schema has changed to include a `productID` field.' Lisa replies, 'I ran `pact-consumer verify` and it passed locally.' What is the *most* likely explanation for this discrepancy?'
This scenario highlights the critical importance of synchronizing Pact schemas across all environments – especially within CI/CD. Even though `pact-consumer verify` passed locally, it's only testing against the local broker version. The consumer needs to be updated with the latest schema from the provider's Pact broker to pass verification consistently. The other options represent potential issues but don't directly explain why a locally passing verification fails in production.
17 / 22
During a standup meeting, Alex reported: "We've implemented Pact contract testing for our user authentication service. We publish events when a user logs in, and the consumer verifies that these events conform to the expected schema. However, we're seeing intermittent failures in our CI pipeline, even though the provider consistently publishes login events."
Intermittent verification failures often point to transient network issues or flaky infrastructure. While schema drift can cause problems, a stable network connection is usually the first thing to investigate when dealing with sporadic pipeline errors. Options C and D represent potential root causes but are less likely than a temporary connectivity problem in a CI/CD environment.
18 / 22
During a code review of the new payment service, Sarah comments: 'Our Pact consumer is failing verification after we updated the event schema. We've published events, but it's not matching what's expected.' What does she mean by 'not matching what's expected'?
Sarah is referring to the core concept of Pact contract testing: ensuring the data exchanged between services aligns. 'Not matching what's expected' signifies a discrepancy – likely in data types, values, or schemas – between the published consumer contract and the actual events being consumed.
19 / 22
During a Slack discussion about integrating a new microservice with an existing one, John says: 'We need to use Pact to ensure our service's events align with the consumer's expectations.' What is the *primary* benefit of using Pact in this scenario?
The key benefit of Pact is its ability to provide automated contract verification. This ensures that the events published by one service are compatible with the expectations defined in a consumer's contract, reducing integration bugs and improving reliability.
20 / 22
In a PR review for a new Pact implementation, Emily notes: 'We've published our event contracts using Pactflow.' What is the *most* important distinction between Pact and other contract testing approaches when using Pactflow?
The core advantage of Pactflow is its bi-directional nature. Unlike traditional contract testing where one side publishes and the other consumes, Pactflow allows both the provider *and* consumer to independently verify that their contracts remain compatible throughout the CI/CD pipeline.
21 / 22
During a standup meeting, David explains: 'We're using Pact to ensure our order processing service and its payment service align on event schemas. However, we're still experiencing sporadic failures in our verification builds.' What is the *most likely* cause of these sporadic failures?
Pact contracts define the expected structure and behavior of events. Sporadic verification failures often occur when updates to one service's contract are not immediately reflected in the other's contract – leading to a mismatch that triggers a failed verification.
22 / 22
A developer, Liam, is explaining Pact testing to a new team member, Chloe: 'We use Pact to define the agreements between our services'. What does Liam mean by 'agreements' in this context?
When Liam says 'agreements,' he's referring to the formally defined contracts that dictate the expectations for data exchange between services. These contracts specify the structure, types, and validation rules governing the events, ensuring interoperability.
What will I practice in "Contract Testing in CI/CD Pipelines 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.