5 exercises — Practice data mesh vocabulary in English: domain ownership, data-as-a-product, federated governance, data contracts, output ports, and self-serve infrastructure.
Core data mesh vocabulary clusters
Four principles: domain ownership, data-as-a-product, self-serve infrastructure, federated computational governance
Data product: output port, SLA, data product spec, discovery, trust, addressability
Domain: source-aligned domain, aggregate domain, consumer-aligned domain, domain team
Governance: federated governance, global policies, interoperability, data catalog, standards
Data contract: schema, semantics, SLA, quality guarantees, producer-consumer agreement
0 / 10 completed
1 / 10
A data architect introduces data mesh at an all-hands meeting: "Data mesh is an architectural approach to scaling analytical data. It addresses the centralised data platform bottleneck: one data team owning all pipelines becomes a constant constraint. The core idea: decentralise data ownership to domain teams. The team that produces the Orders service also owns the Orders data product. They're accountable for its quality, availability, and freshness. The central platform team shifts from data ownership to providing the infrastructure domains use to publish data products." What is the data-as-a-product principle in data mesh?
Data-as-a-product: the second principle of data mesh. Domain teams apply product thinking to data — treating data consumers as customers. Quality attributes a data product must have: Discoverable: findable in the data catalog. Consumers can search and find it. Addressable: has a stable, unique address (URI). Consumers can programmatically access it. Trustworthy: quality guarantees. SLA for freshness, completeness, accuracy. Consumers can rely on it. Self-describing: schema, semantics, sample data, documentation. Consumers can understand it without asking the producer. Interoperable: uses shared standards so cross-domain joins and pipelines work without transformation. Governed: complies with global policies (access control, PII handling, retention). Data mesh principles: 1) Domain ownership — domain teams own their data. 2) Data-as-a-product — product quality applied to data. 3) Self-serve infrastructure — platform providing tools to produce/consume data without central team help. 4) Federated computational governance — global standards, local enforcement. In conversation: 'The "product" in data-as-a-product is the key shift. It's not just publishing a CSV somewhere — it means an SLA, a schema registry entry, documented semantics, and an on-call rotation for data quality incidents.'
2 / 10
A platform engineer explains the output port concept at a data mesh workshop: "In data mesh, a data product exposes its data through output ports. An output port is the interface through which consumers access the data — it could be a BigQuery table, a Kafka topic, a REST API, or a file in S3. Each output port has a declared schema, SLA, and access policy. The key principle: the data product team controls how the data is exposed. Consumers don't get direct access to operational databases — they go through the output port. This decouples the internal implementation from the external contract." What is a data contract in the context of data mesh?
Data contract: a formal agreement between a data producer and its consumers. Contents: Schema: field names, types, nullable constraints. Semantics: what each field means (business definition, not just technical type). Quality SLA: freshness (updated every 1h), completeness (no_missing_orders_id < 0.1%), accuracy guarantees. Breaking change policy: how and when schemas can change. Notice periods, backward-compatible vs. breaking changes. Access method: which output port to use, authentication. Formats: YAML (most common), JSON Schema, Protobuf. Tools: OpenDataContract standard, Soda, Great Expectations, dbt contracts. Output port vocabulary: Output port: the mechanism through which a data product exposes data. Types: batch (files, BigQuery tables), streaming (Kafka topics), API (REST, GraphQL). Input port: how the data product ingests data from operational systems or other data products. Transformation code: the logic that produces the output from the inputs. Owned by the domain team. Data product spec: metadata describing the data product — owner, consumers, output ports, SLA, tags. Stored in a data catalog. In conversation: 'Before data contracts, every consumer had a hidden dependency on our internal schema. When we changed a column name, three pipelines broke silently. Contracts make those dependencies explicit.'
3 / 10
A data governance lead explains federated governance at a cross-domain meeting: "Federated governance is the fourth data mesh principle. The central platform team defines global policies — encryption standards, PII classification, retention policies, interoperability standards. But enforcement happens locally, within each domain. We can't have a central team auditing every data product — it doesn't scale. Instead, the platform encodes the policies as automated checks that run when a domain publishes a data product. Computational governance means the governance rules are code, not documents." What is computational governance in data mesh?
Computational governance: policies as code. Examples: a pipeline check that automatically rejects a data product registration if PII fields aren't tagged, an automated schema evolution check that fails if a breaking change wasn't versioned, a row-level security policy automatically applied when a consumer accesses a field tagged as GDPR-sensitive. Benefits: scales across many domains without manual central review, consistent enforcement, auditable. Federated governance vocabulary: Global policy: set by the central governance body. Applies to all domains. Examples: all fields containing email must be tagged as PII, all data products must have a schema in the registry, data older than 7 years must be deleted. Local policy: domain-specific governance. Set by the domain team within global constraints. Interoperability standard: shared vocabulary (common date formats, currency units, customer ID format) that allows joining data products across domains. Data catalog: the searchable registry of all data products — discovery, lineage, documentation. Examples: DataHub, Atlan, Collibra. Data lineage: the provenance of data — where it came from, what transformed it. Helps with debugging and impact analysis. Policy engine: the software that evaluates and enforces governance rules (Apache Ranger, OPA). In conversation: 'If your governance is a PDF document with rules, you don't have governance — you have aspirational documentation. Computational governance makes it impossible to skip.'
4 / 10
A domain engineer explains domain types at a data mesh adoption workshop: "Data mesh domains come in three flavours. Source-aligned domains are closest to operational systems — the Orders domain publishes raw and cleaned orders data. Aggregate domains combine data from multiple source domains — Customer360 joins Orders, Payments, Support. Consumer-aligned domains optimise data for specific consumers — the Finance domain gets pre-aggregated revenue reports. Most domains start as source-aligned; aggregate domains add value on top. Consumer-aligned domains are controversial — they can create tight coupling." What distinguishes a source-aligned domain from an aggregate domain?
Source-aligned domain: owns data close to the operational system. Responsibility: expose the operational data accurately. Minimal business transformation. Example: Orders domain publishes raw orders, cleaned orders, cancelled orders — all reflecting what happened in the Orders system. Aggregate domain: consumes from multiple source domains. Adds value by combining or deriving new insights. Example: Customer 360 — joins Orders, Payments, Support, Marketing data to create a unified customer view. No single source domain could produce this. Consumer-aligned domain: optimised for a specific consumer. Example: Finance reporting domain — pre-aggregated and formatted for the Finance BI tool. Debate: tightly coupled to one consumer, may duplicate other domain data. Data mesh organisational vocabulary: Domain team: a cross-functional team (engineers, data engineers, domain experts) responsible for a business domain's data products. Platform team: provides the self-serve infrastructure. Not responsible for domain data quality. Data product owner: the person accountable for a data product's quality, SLA, and roadmap. Data steward: responsible for metadata, documentation, and governance compliance of data products. In conversation: 'We started with all domains as source-aligned. Aggregate domains emerged organically when multiple teams needed the same join — at that point, you either build an aggregate domain or accept duplicated logic.'
5 / 10
A senior data engineer contrasts data mesh with a central data platform: "The traditional approach: one data team, one data warehouse, all ETL pipelines owned centrally. Advantage: consistency. Problem: the central team becomes a bottleneck. Every new dataset request goes into a backlog. Three-month wait times for new pipelines. Data mesh solves this by distributing ownership — but it creates new challenges: how do you prevent 50 domain teams from defining 'customer' in 50 different ways? Interoperability standards and a shared catalog address this. The trade-off is organisational complexity for scalability." What is self-serve data infrastructure in data mesh?
Self-serve infrastructure: the third principle of data mesh. The platform team builds tools that make it easy for domain teams to: Build: scaffolding for data pipelines, schema registration, data product templates. Deploy: CI/CD for data products, automated quality checks, automated catalog registration. Operate: monitoring dashboards, alerting, SLA tracking. Discover and consume: data catalog, access request portal, query interfaces. Goal: a domain team should be able to go from "we need to publish this data" to a production data product in days, not months. Without self-serve infrastructure, data mesh doesn't scale — domain teams are blocked by platform team tickets. Data mesh vs. alternatives: Data warehouse: centralised storage. Good for BI. Bottleneck at scale. Data lake: centralised raw storage. Schema-on-read flexibility. Governance challenges. Data lakehouse: combines lake and warehouse (Delta Lake, Apache Iceberg). Still centralised. Data mesh: decentralised ownership with federated governance. Solves ownership and quality bottlenecks. Requires strong platform tooling. Semantic layer: a consistent business metric definition layer (dbt Semantic Layer, Cube) that can complement any architecture. In conversation: 'Data mesh without self-serve infrastructure is just bureaucracy. Domains are accountable for quality, but if they need a ticket to publish anything, you haven't solved the bottleneck — you've just moved it.'
6 / 10
Review this code review comment from a platform engineer discussing a new data product:
`@john.doe 'The Orders data product's BigQuery table schema doesn't explicitly define the currency field. This is causing inconsistencies in downstream reports. Please add a `currency_code` column with a standard ISO 4217 code.` What does this comment primarily highlight regarding data mesh principles?
This comment focuses on a data contract – specifically, the expected schema and its attributes. Data mesh emphasizes that each domain team is accountable for the quality and definition of their data product. The incorrect options represent either centralized control (option 1), misinterpreting SLAs (option 3), or an inappropriate role for the central platform (option 4).
7 / 10
Sarah (Marketing) sends this Slack message to the data mesh community:
`@data-team 'We're building a new customer segmentation model. We'll be using raw website clickstream data from our analytics platform and merging it with our CRM data via a SQL join. It's going to be *huge*! Can someone help us optimize the query performance?' What concept does Sarah implicitly raise as a potential challenge within a data mesh environment?
Sarah's message highlights the potential for inconsistent schemas and duplicated data when different domains use raw data and perform their own transformations. This is a core challenge in data mesh – managing interoperability across domain-specific datasets. The other options misrepresent the central tenets of data mesh regarding self-serve infrastructure and domain ownership.
8 / 10
Here's a PR description from a domain engineer deploying a new Orders data product:
`This PR introduces a new output port exposing the `orders` table in BigQuery. The schema is defined as follows: `order_id`, `customer_id`, `product_id`, `quantity`, `price`, and `timestamp`. Access is governed by IAM roles. Consumers can query this data directly via SQL. We've added documentation on the expected SLA for freshness (within 5 minutes).` What does the inclusion of 'IAM roles' in this description primarily reflect within a data mesh architecture?
IAM roles (Identity and Access Management) represent the domain's control over who can access their data product. This aligns with the core principle of data mesh – that each domain owns its data and is responsible for managing access controls. The other options misrepresent the role of domains or the central platform regarding security governance.
9 / 10
During a daily stand-up, David (the Orders domain engineer) says: 'I've been working on improving the freshness of our `orders` data product. I'm now using Kafka to stream changes directly from our operational system into BigQuery and updating the output port schema whenever there are any changes.' What aspect of a data mesh architecture is David actively implementing?
David's description highlights a decentralized approach – streaming changes directly from the source system into BigQuery. This reflects a shift away from traditional ETL pipelines and towards real-time data product updates. The other options represent centralized approaches that are antithetical to the principles of data mesh.
10 / 10
A junior developer asks: 'What's the difference between a domain model and a data product?'
While both terms are related to the concept of data products, they represent distinct things. A domain model is an internal representation used within the domain team, while a data product represents the externally-facing interface for that data – how it's made available and consumed by others. The other options present inaccurate or overly technical distinctions.
What does the "Data Mesh Architecture Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to data mesh architecture 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 — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
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.