Sample questions
Sd Contract TestingDifficulty 1
What is the core idea behind consumer-driven contract testing?
- aThe provider team writes every field a consumer is allowed to send and forces all consumers to match it exactly
- bA tester manually clicks through the consumer application against a live provider to confirm nothing broke, repeating the same manual steps by hand before every single release
- cThe consumer defines the interactions it expects from the provider, and the provider verifies it can satisfy those expectations✓
- dThe provider replays production traffic against a staging environment to measure response latency
Explanation:In consumer-driven contract (CDC) testing, the consumer specifies the requests it will send and the responses it expects; the provider then verifies against that same expectation set, which is (c). Provider-dictated schemas (a) invert the relationship, manual UI walkthroughs (b) are exploratory testing, and traffic replay for latency (d) is performance testing, not contract testing.
Sd Contract TestingDifficulty 1
In contract testing terminology, what is a "pact" (contract)?
- aA signed legal document between two engineering managers about release dates
- bA recorded set of expected request/response interactions between a specific consumer and a specific provider✓
- cA single end-to-end test that exercises the full user journey across every microservice
- dA performance budget that caps how many requests per second a provider may receive, enforced automatically by the provider's load balancer
Explanation:A pact is the artifact (typically a JSON file) that records the interactions a consumer expects from a provider — requests it will send and the responses it expects back — which is (b). It is not a legal document (a), not a full end-to-end test (c), and not a performance budget (d).
Sd Contract TestingDifficulty 1
In the consumer/provider vocabulary used by contract testing, which statement correctly describes the roles?
- aThe consumer is always a frontend UI and the provider is always a database
- bThe consumer is the service that makes a call, and the provider is the service that receives and responds to that call✓
- cThe consumer and provider are two names for the same service, chosen based on which team happens to own the shared repository at any given time
- dThe provider is the service that writes the test code, and the consumer only reads the results
Explanation:A consumer is whatever calls an API (a frontend, another backend service, a mobile app, etc.) and a provider is whatever exposes that API and responds — that is (b). The roles are not tied to UI-vs-database (a), they refer to distinct services, not one service under two names (c), and both sides write their own tests (d).
Sd Contract TestingDifficulty 1
Why does contract testing exist as a distinct practice from full end-to-end integration testing?
- aIt replaces unit testing entirely, since unit tests cannot catch integration problems
- bIt is required by law for any system exposing a public REST API
- cIt guarantees that the provider's business logic produces correct results for every input, eliminating the need for any functional testing
- dIt lets teams verify that a consumer and provider agree on an API's shape without standing up every service together✓
Explanation:Contract testing exists to catch integration mismatches early without needing every real service running together, which is (d). It does not replace unit testing (a), it is an engineering practice, not a legal requirement (b), and it checks the API's request/response shape, not the correctness of business logic (c).
Sd Contract TestingDifficulty 2
A platform has 6 consumer services calling 5 different provider services. If every consumer-provider pair needed its own dedicated full end-to-end integration test suite running against real deployed instances, what problem does this illustrate?
- aThe N+1 query problem, where each request triggers an extra database round trip
- bThe flaky test problem, where tests fail intermittently due to timing issues
- cThe N×M integration test explosion, where the number of test suites grows with every consumer-provider combination✓
- dThe test data pollution problem, where one test's leftover data corrupts another, unrelated test's expected starting state
Explanation:This is the N×M explosion: with N consumers and M providers, a naive approach needs up to N×M dedicated integration suites, and every new service multiplies the cost, which is (c). N+1 queries (a) is a database performance issue, flakiness (b) is about non-deterministic failures, and data pollution (d) is a test isolation issue — none describe the combinatorial growth in suite count.
Sd Contract TestingDifficulty 1
How does contract testing help reduce the N×M integration test explosion described by consumer-driven contracts?
- aEach consumer tests against a lightweight mock built from the contract, and each provider verifies against the same contract independently, so no pair needs a live combined environment✓
- bIt eliminates the need for providers to have any automated tests at all
- cIt merges all consumers and providers into a single monolithic deployable so there is only one thing to test
- dIt requires every consumer and provider to be rewritten in the same programming language
Explanation:Contract testing decouples the two sides: the consumer verifies against a mock generated from the contract, and the provider verifies independently against the same contract, so N×M live integration suites shrink to N+M contract verifications, which is (a). It does not remove the provider's own test responsibility (b), does not require merging services (c), and is language-agnostic (d).