5 exercises — Practice DataOps vocabulary in English: data quality SLAs, data contracts, data observability, lineage, schema drift, and data incidents.
Core DataOps vocabulary clusters
Data quality: data quality SLA, freshness, completeness, accuracy, consistency, validity, data quality score
Data contracts: data contract, schema registry, backward/forward compatibility, breaking change, consumer-driven contract
Observability: data observability, data lineage, column-level lineage, anomaly detection, data freshness, volume spike
Incidents: data incident, silent failure, data downtime, SLA breach, data quality alert, incident classification
Tools: Monte Carlo, Great Expectations, dbt tests, Apache Atlas, OpenLineage, Marquez, Soda Core
0 / 10 completed
1 / 10
A data engineering lead introduces data contracts: "A data contract is a formal agreement between data producers and consumers about the structure and semantics of a dataset. It specifies the schema, data types, expected freshness, null rate, and SLA. If the producer makes a breaking change — like renaming a column or changing a type — they violate the contract. We version our contracts and require producers to get consumer sign-off before breaking changes." What is a data contract and what problem does it solve?
Data contract: a specification (usually YAML or JSON) that defines what a dataset looks like and how it will behave. Elements: schema (column names, types, nullable), semantics (what does this column mean?), freshness SLA (updated every hour), quality rules (null rate <1%, no negative values), versioning policy. Problem solved: Silent breaking changes — without contracts, a producer renames a column, and downstream pipelines break silently. Contracts make the agreement explicit and violations detectable. Schema drift — unintended schema changes (new columns, type changes, removed fields) propagating downstream. Data contract vocabulary: Producer — the team/service that generates the data. Consumer — the team/pipeline that reads the data. Breaking change — a schema change that breaks existing consumers: rename, remove, or type-change of existing fields. Non-breaking change — adding optional new fields with defaults. Contract testing — validating that actual data matches the contract definition. Tools: Soda Core, Great Expectations, dbt tests, Monte Carlo. Formats: OpenDataMesh, Bitol, custom YAML. In conversation: "We caught 3 breaking schema changes in staging because our contract tests ran against the new pipeline output — without contracts, those would have reached production."
2 / 10
A data platform engineer presents data observability to the team: "Data observability is the ability to understand the health of your data at all times. The five pillars are: freshness (is the data current?), volume (is the expected amount of data arriving?), distribution (are the values within expected ranges?), schema (have the columns changed?), and lineage (what upstream data did this come from?). When we get an alert, lineage tells us which source caused the issue." What is data lineage and why is it critical for incident response?
Data lineage: a directed graph showing how data flows from sources through transformations to final consumers. Types: Table-level lineage — which tables feed which tables. Column-level lineage — which source columns map to which output columns (through joins, transformations). More precise but harder to compute. Why it matters: Impact analysis — if source table X changes, which dashboards are affected? Root cause analysis — dashboard shows wrong numbers; lineage traces back to the upstream table with the data quality issue. Compliance — GDPR right to erasure: find all places a user's data was used. Data observability five pillars (Monte Carlo): Freshness — when was the table last updated? Alert if stale. Volume — is the row count within expected range? A 90% drop = likely upstream failure. Distribution — are column values within expected ranges? Null rate spike, unexpected categories. Schema — did columns change? Lineage — upstream/downstream visibility. Tools: Monte Carlo (commercial), OpenLineage (open standard), Marquez (open-source lineage service), Apache Atlas, DataHub. In conversation: "The dashboard was showing wrong revenue figures. With column-level lineage, we traced it back to a currency conversion bug in the exchange_rates table in 10 minutes — without lineage it would have taken hours."
3 / 10
A data quality engineer explains SLA measurement: "We have a data quality SLA for our orders table: freshness within 1 hour, null rate on order_id under 0.01%, row count within ±20% of a 7-day rolling average. When any of these breach, we page the on-call data engineer and open a data incident. Last quarter we had 99.2% data uptime — 3 SLA breaches each lasting under 4 hours." What is data downtime in the context of data observability?
Data downtime: coined by Monte Carlo; the period during which data is unreliable — inaccurate, missing, stale, or duplicated — from the perspective of data consumers. Analogous to service downtime in SRE. Data uptime = (1 - data downtime / total time) × 100%. Data SLA vocabulary: Data quality SLA — agreed thresholds for quality dimensions: freshness, completeness, accuracy, consistency. Data incident — a breach of a data quality SLA that requires investigation and remediation. Silent failure — a data quality issue that goes undetected because no monitoring is in place. The most dangerous type. SLA breach — a quality dimension falls outside the contracted threshold. Data incident severity: P0 (business-critical dashboard wrong), P1 (important data late), P2 (minor quality issue). MTTR for data — mean time to restore data quality. Data freshness SLA — the maximum acceptable delay between source data creation and availability in the warehouse. Typical: hourly for operations, daily for analytics. In conversation: "Our stakeholders treat stale data like a service outage — we track data downtime the same way SRE tracks uptime because the business impact is comparable."
4 / 10
A DataOps engineer introduces automated data quality testing: "We run dbt tests on every pipeline run. We have schema tests — not_null, unique, accepted_values, relationships — and custom data tests written in SQL. Great Expectations lets us define expectations: 'column X should have values between 0 and 1000', 'null rate should be under 5%'. We run these in CI so bad data never reaches production — it breaks the pipeline and alerts the on-call." What is a data test in a DataOps pipeline and why is it important?
Data test: an automated assertion about a data quality property that runs as part of the data pipeline. Fails the pipeline if the assertion is violated. dbt test types: not_null — asserts no null values in a column. unique — asserts all values are unique. accepted_values — asserts values are in a defined list. relationships — asserts referential integrity (foreign key exists in the referenced table). Custom tests — SQL queries that return failing rows; zero rows = test passes. Great Expectations vocabulary: Expectation — a testable assertion: "expect_column_values_to_be_between", "expect_column_mean_to_be_between". Expectation suite — a collection of expectations for a dataset. Checkpoint — a run of an expectation suite against a data batch. Data docs — Great Expectations generates HTML documentation of test results. Soda Core: another open-source data quality testing framework with YAML-defined checks. Data contract testing — validating that actual data matches the published data contract schema and rules. Pipeline vocabulary: Fail fast — break the pipeline immediately on quality issues rather than letting bad data propagate. Quarantine table — rows that failed quality checks go to a quarantine table for investigation rather than being silently dropped. In conversation: "Before DataOps, bad data would silently flow through and surface 3 days later in a stakeholder meeting. Now the pipeline breaks and we know within minutes."
5 / 10
A data architect explains schema management in event streaming: "All our Kafka messages are serialised with Avro and validated against schemas in the Confluent Schema Registry. Producers register a schema before publishing. Consumers look up the schema by ID from the message header. We enforce backward compatibility — you can add optional fields, but you can't remove or rename existing fields. A breaking change requires a new schema version and a migration plan." What is schema drift and how does DataOps tooling detect it?
Schema drift: unintended or unexpected changes to a data schema that propagate through the pipeline. Can be: additive (new columns — usually safe), subtractive (removed columns — breaks consumers), type change (integer → string — breaks consumers), rename (same data, new name — breaks consumers). Detection methods: Schema registry enforcement — Kafka Schema Registry rejects incompatible schema changes. dbt schema tests — dbt can assert that expected columns exist with expected types. Data observability schema monitoring — tools like Monte Carlo alert when the column count, types, or names change between pipeline runs. Contract testing — validating actual data against the published data contract schema. Schema evolution vocabulary: Backward compatible — new schema can be read by old code. Forward compatible — old schema can be read by new code. Schema migration — planned, versioned change to a schema; communicated to all consumers in advance. Blue-green schema deployment — run old and new schema in parallel; migrate consumers; retire old schema. Dead letter queue (DLQ) — in streaming pipelines, messages that fail schema validation are routed to a DLQ for investigation rather than blocking the pipeline. In conversation: "The pipeline broke because someone added a NOT NULL column to the source table without telling us — schema drift, and no contract to catch it."
6 / 10
Sarah, a junior data analyst, is struggling to understand why her dashboard isn't updating correctly. Mark, the DataOps engineer, explains: 'We use a continuous integration pipeline that automatically runs tests on our data transformations whenever changes are pushed to GitHub. If a test fails – for example, a check that ensures the `customer_id` column always contains valid integers – it triggers an alert in OpsGenie and initiates a rollback of the failing change.' What does Mark describe?
The question describes an automated CI/CD pipeline that reacts to failures in a data transformation. The correct answer (B) accurately captures this – it highlights the system's ability to automatically identify and rectify errors before impacting users. Options A, C, and D represent different, unrelated approaches to data quality or alerting.
7 / 10
David, a Senior Data Engineer, is responding to a Slack message from the BI team: 'We're seeing unusually high latency on our daily sales data pipeline. The last three runs took over 6 hours each – this is significantly impacting our reporting!' David replies: 'Let's investigate. I'm checking the lineage of that pipeline in Databand. It shows a dependency on the marketing attribution service, which has been experiencing performance issues.' What does David's response indicate?
This scenario tests understanding of data dependency and impact analysis. The correct answer (B) correctly identifies that the issue likely stems from a dependent service causing delays – checking lineage is key to tracing this kind of problem. Options A, C, and D are plausible but less directly related to the stated symptom of latency.
8 / 10
Maria, a DataOps specialist, is writing a PR description for a change that improves data validation in their streaming pipeline. She writes: 'This commit adds a new schema validation step using Apache Beam. It checks that all incoming messages conform to the Avro schema registered in Confluent Schema Registry and throws an exception if they don't – preventing bad data from entering our downstream systems.' What is Maria describing?
This question focuses on schema validation as a core DataOps practice. The correct answer (B) accurately describes the function of the new Beam step – it's designed to proactively prevent invalid data from entering the system. Options A, C, and D represent different aspects related to data management or pipeline optimization.
9 / 10
During a standup meeting, Ben, a Data Engineer, is updating the team on his progress. He states: 'I've been implementing automated data quality checks using Great Expectations. We define expectations like 'the average order value should be between $50 and $200', and if those expectations are violated – say due to an anomaly in sales – we get alerted.' What is Ben describing?
This scenario tests the understanding of Great Expectations and its role in proactive monitoring. The correct answer (B) correctly describes using expectation-based testing to identify anomalies – this is a key aspect of Ben's work. Options A, C, and D represent different data analysis or reporting activities.
10 / 10
Elena, a Data Architect, is explaining the importance of schema evolution to a team of developers. She says: 'We're using Kafka with Avro serialization and Confluent Schema Registry. Producers register schemas, and consumers look them up. We embrace backward compatibility – adding optional fields is fine; removing or renaming existing ones requires careful consideration.' What does Elena highlight?
This question assesses understanding of schema evolution and its implications in event streaming. The correct answer (B) accurately describes backward compatibility – it emphasizes the crucial aspect of maintaining data processing capabilities while accommodating changes. Options A, C, and D represent alternative approaches or incorrect assumptions.
These modules build the same on-the-job skills as DataOps Vocabulary
— work through them together for a fuller vocabulary set.
Data Engineering— useful for Data pipeline language (Data Science & ML)
Frequently Asked Questions
What does the "DataOps Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to dataops vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.