📄 Data Contract Vocabulary
0 / 22 completed
1 / 22
Scenario: "The pipeline broke because the producer changed the schema without notifying consumers." What is a data contract designed to prevent?
Data contract defines: schema, semantics, quality expectations, SLA, and breaking change policy. Born from data engineering reliability needs — tables breaking downstream pipelines silently.
Systems: Soda, Great Expectations.
Key vocab: data producer, data consumer, schema definition, freshness SLA, breaking change notification.
Systems: Soda, Great Expectations.
Key vocab: data producer, data consumer, schema definition, freshness SLA, breaking change notification.
2 / 22
Scenario: "The contract specifies the schema is owned by the producing team." What does schema ownership mean in a data contract context?
Schema ownership: the producer controls the structure but has obligations — advance notice, versioning, migration support. Producer-driven vs. consumer-driven contracts are different models.
Key vocab: schema ownership, producer obligations, advance notice, schema registry.
Key vocab: schema ownership, producer obligations, advance notice, schema registry.
3 / 22
Scenario: "The analyst reports a sudden drop in row count." How does a data contract help in this situation?
Data contracts include: volume (row count ranges), freshness, completeness (null rate), validity. A shared definition of "normal" vs. "anomaly" removes ambiguity during incidents.
Key vocab: quality expectation, volume anomaly, contract violation, escalation path in contract.
Key vocab: quality expectation, volume anomaly, contract violation, escalation path in contract.
4 / 22
Scenario: "The data product team versioned the contract as v2.0.0." What does a MAJOR version bump mean for a data contract?
SemVer for data contracts: MAJOR (breaking: column rename/removal, type change), MINOR (backward-compatible addition), PATCH (doc fix).
Protocol: advance notice (30 days), migration guide, dual-version support period.
Key vocab: breaking data contract change, SemVer for data, migration notice, deprecation period.
Protocol: advance notice (30 days), migration guide, dual-version support period.
Key vocab: breaking data contract change, SemVer for data, migration notice, deprecation period.
5 / 22
Scenario: "The team is implementing contract-first data development." What does contract-first mean?
Contract-first: analogous to API-first. Benefits: catches design disagreements early, documents assumptions, enables parallel development.
Key vocab: contract-first development, design before implementation, schema registry pre-registration.
Key vocab: contract-first development, design before implementation, schema registry pre-registration.
6 / 22
PR Description
Subject: Schema Update - User Profile Service
We've updated the user profile schema to include a `phone_number` field. This aligns with recent GDPR requirements and allows us to better track customer communication preferences.
This change *may* impact downstream services consuming this data; please review carefully.
This scenario presents a typical PR description related to a data schema change. The question tests understanding of what a data contract *actually* governs—specifically, the structure and contents of the data itself. Option A is incorrect because size isn't defined in a contract; Options C and D are also wrong as they describe broader aspects like versioning or compatibility, rather than detailing the precise fields within the object. Choosing option 2 correctly identifies that a data contract primarily focuses on defining what *data* is included.
7 / 22
Review the following Slack message from a team member during code review:
User A: 'I'm seeing some weird data types coming back from the User Profile Service. The `user_id` field is sometimes returning an integer, and sometimes a string! This isn't in the contract.'
What potential issue does User A likely identify related to data contracts?User A's comment highlights a core function of data contracts: ensuring consistent data types are exchanged between services. The correct answer describes the situation where the service isn't adhering to the contract's specification for `user_id`, which could cause significant problems when processing and interpreting the data. Options B, C, and D misinterpret the issue or offer irrelevant solutions – schema updates aren't the problem, outages don't inherently change schema types, and legal review is not directly related to data type mismatches.
8 / 22
Review the following Slack message from a team member during code review:
User C: 'I'm running tests against the new User Profile Service and I'm seeing inconsistent data. The contract specifies that `first_name` should always be a string, but some responses are returning it as an empty string. This is causing failures in my validation logic.'
What does User C *primarily* point out regarding the importance of data contracts?
User C correctly identifies that the data contract should guarantee the *type* and *format* of `first_name`. The contract serves as an agreement on what constitutes a valid response. Options A and D misinterpret the role of the contract – it's not about handling edge cases or accepting arbitrary values, but rather enforcing defined expectations. Option B accurately reflects the core purpose: ensuring consistency by specifying exactly what is allowed.
9 / 22
PR Description
Subject: Schema Update - User Profile Service
We've updated the user profile schema to include a `phone_number` field. This aligns with recent GDPR requirements and allows us to better track customer communication preferences.
This change *may* impact downstream services consuming this data; please review carefully.
This scenario presents a typical PR description related to a data schema change. The question tests understanding of what a data contract *actually* governs—specifically, the structure and contents of the data itself. Option A is incorrect because size isn't defined in a contract; Options C and D are also wrong as they describe broader aspects like versioning or compatibility, rather than detailing the precise fields within the object. Choosing option 2 correctly identifies that a data contract primarily focuses on defining what *data* is included.
10 / 22
Review the following Slack message from a team member during code review:
User A: 'I'm seeing some weird data types coming back from the User Profile Service. The `user_id` field is sometimes returning an integer, and sometimes a string! This isn't in the contract.'
What potential issue does User A likely identify related to data contracts?User A's comment highlights a core function of data contracts: ensuring consistent data types are exchanged between services. The correct answer describes the situation where the service isn't adhering to the contract's specification for `user_id`, which could cause significant problems when processing and interpreting the data. Options B, C, and D misinterpret the issue or offer irrelevant solutions – schema updates aren't the problem, outages don't inherently change schema types, and legal review is not directly related to data type mismatches.
11 / 22
Review the following Slack message from a team member during code review:
User C: 'I'm running tests against the new User Profile Service and I'm seeing inconsistent data. The contract specifies that `first_name` should always be a string, but some responses are returning it as an empty string. This is causing failures in my validation logic.'
What does User C *primarily* point out regarding the importance of data contracts?
User C correctly identifies that the data contract should guarantee the *type* and *format* of `first_name`. The contract serves as an agreement on what constitutes a valid response. Options A and D misinterpret the role of the contract – it's not about handling edge cases or accepting arbitrary values, but rather enforcing defined expectations. Option B accurately reflects the core purpose: ensuring consistency by specifying exactly what is allowed.
12 / 22
PR Description
Subject: Schema Update - User Profile Service
We've updated the user profile schema to include a `phone_number` field. This aligns with recent GDPR requirements and allows us to better track customer communication preferences.
This change *may* impact downstream services consuming this data; please review carefully.
This scenario presents a typical PR description related to a data schema change. The question tests understanding of what a data contract *actually* governs—specifically, the structure and contents of the data itself. Option A is incorrect because size isn't defined in a contract; Options C and D are also wrong as they describe broader aspects like versioning or compatibility, rather than detailing the precise fields within the object. Choosing option 2 correctly identifies that a data contract primarily focuses on defining what *data* is included.
13 / 22
Review the following Slack message from a team member during code review:
User A: 'I'm seeing some weird data types coming back from the User Profile Service. The `user_id` field is sometimes returning an integer, and sometimes a string! This isn't in the contract.'
What potential issue does User A likely identify related to data contracts?User A's comment highlights a core function of data contracts: ensuring consistent data types are exchanged between services. The correct answer describes the situation where the service isn't adhering to the contract's specification for `user_id`, which could cause significant problems when processing and interpreting the data. Options B, C, and D misinterpret the issue or offer irrelevant solutions – schema updates aren't the problem, outages don't inherently change schema types, and legal review is not directly related to data type mismatches.
14 / 22
Review the following Slack message from a team member during code review:
User C: 'I'm running tests against the new User Profile Service and I'm seeing inconsistent data. The contract specifies that `first_name` should always be a string, but some responses are returning it as an empty string. This is causing failures in my validation logic.'
What does User C *primarily* point out regarding the importance of data contracts?
User C correctly identifies that the data contract should guarantee the *type* and *format* of `first_name`. The contract serves as an agreement on what constitutes a valid response. Options A and D misinterpret the role of the contract – it's not about handling edge cases or accepting arbitrary values, but rather enforcing defined expectations. Option B accurately reflects the core purpose: ensuring consistency by specifying exactly what is allowed.
15 / 22
PR Description
Subject: Schema Update - User Profile Service
We've updated the user profile schema to include a `phone_number` field. This aligns with recent GDPR requirements and allows us to better track customer communication preferences.
This change *may* impact downstream services consuming this data; please review carefully.
This scenario presents a typical PR description related to a data schema change. The question tests understanding of what a data contract *actually* governs—specifically, the structure and contents of the data itself. Option A is incorrect because size isn't defined in a contract; Options C and D are also wrong as they describe broader aspects like versioning or compatibility, rather than detailing the precise fields within the object. Choosing option 2 correctly identifies that a data contract primarily focuses on defining what *data* is included.
16 / 22
Review the following Slack message from a team member during code review:
User A: 'I'm seeing some weird data types coming back from the User Profile Service. The `user_id` field is sometimes returning an integer, and sometimes a string! This isn't in the contract.'
What potential issue does User A likely identify related to data contracts?User A's comment highlights a core function of data contracts: ensuring consistent data types are exchanged between services. The correct answer describes the situation where the service isn't adhering to the contract's specification for `user_id`, which could cause significant problems when processing and interpreting the data. Options B, C, and D misinterpret the issue or offer irrelevant solutions – schema updates aren't the problem, outages don't inherently change schema types, and legal review is not directly related to data type mismatches.
17 / 22
Review the following Slack message from a team member during code review:
User C: 'I'm running tests against the new User Profile Service and I'm seeing inconsistent data. The contract specifies that `first_name` should always be a string, but some responses are returning it as an empty string. This is causing failures in my validation logic.'
What does User C *primarily* point out regarding the importance of data contracts?
User C correctly identifies that the data contract should guarantee the *type* and *format* of `first_name`. The contract serves as an agreement on what constitutes a valid response. Options A and D misinterpret the role of the contract – it's not about handling edge cases or accepting arbitrary values, but rather enforcing defined expectations. Option B accurately reflects the core purpose: ensuring consistency by specifying exactly what is allowed.
18 / 22
During a standup meeting, Sarah mentions that the 'Customer Data' contract defines all fields as strings. John asks, 'What does it mean to say a field is *string-typed* in the context of this contract?'
A string-typed field in a data contract signifies that the field is designed to hold textual information. This contrasts with numeric types which are intended for numerical values. Misunderstanding this can lead to errors when attempting to process or validate data against the contract's specifications; it's crucial to remember data contracts define *types*, not just raw data.
19 / 22
You receive this Slack message from a colleague: 'The API response for retrieving user profiles is returning `user_id` as a boolean instead of an integer, despite the contract stating it should be an integer.' What is the *primary* issue highlighted here?
This Slack message points to a critical discrepancy: a violation of the data contract. A data contract defines the *expected* structure and types of data; when the API returns something different (a boolean instead of an integer for `user_id`), it's a breach that needs immediate attention, as it directly impacts data validation and processing.
20 / 22
During a code review, you're examining a PR description for an update to the 'Product Catalog' contract. The description states: 'We've introduced a new field, `product_category`, which is defined as 'enum: Electronics, Clothing, Books'.' What does the term 'enum' signify in this context?
An 'enum' (enumeration) in data contracts represents a list of valid values that a particular field can take. In this case, `product_category` is constrained to only accept one of the specified options – Electronics, Clothing, or Books. This enforces consistency and prevents invalid data from entering the system.
21 / 22
A senior developer comments on a PR: 'I'm seeing inconsistent data in the 'Customer Orders' contract. The contract specifies that `order_status` should be one of 'Pending', 'Shipped', or 'Delivered'. However, some orders are being created with values like 'Processing' and 'Cancelled'.' What is the most likely root cause?
This comment strongly suggests a problem with the code implementing the order creation process. The developer is observing data that doesn't conform to the defined `order_status` enum in the contract – this indicates a failure of validation logic, causing invalid values to be written into the database. It's crucial to check the code for proper enforcement of the contract.
22 / 22
You're reviewing a Slack message from a team member: 'I'm getting a 400 Bad Request error when trying to update the 'User Profiles' contract through the API. The request body includes a `phone_number` field with the value '123-456-7890', but the contract specifies that this field should be an array of phone numbers.' What is the key takeaway from this message?
The 400 Bad Request error indicates that the API received a malformed request – specifically, the `phone_number` field in the request body doesn't match the contract's defined schema (an array of phone numbers). This highlights the importance of adhering to the data contract's specifications when building API integrations.
Frequently Asked Questions
What does the "Data Contract Vocabulary" exercise practise?
Practice core data contract vocabulary: producer-consumer model, schema, SLA, breaking change, data product.
How many questions are in this exercise?
This exercise has 22 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Data Contracts category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Data Contract Vocabulary" part of a larger series?
Yes — it's one exercise in the Data Contracts category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Data Contracts category page for related exercises, or browse the main Exercises hub for other IT English topics.