Data Mesh — Core Principles Vocabulary
Learn the four principles of Data Mesh: domain ownership, data as a product, self-serve infrastructure, and federated governance.
0 / 22 completed
1 / 22
What are the four principles of Data Mesh (Zhamak Dehghani)?
Data Mesh's four principles are: (1) Domain ownership of data, (2) Data as a product, (3) Self-serve data infrastructure as a platform, and (4) Federated computational governance.
2 / 22
What does 'domain ownership of data' mean in Data Mesh?
Domain ownership means the team that generates the data is responsible for managing, serving, and ensuring the quality of that data — not a central data team.
3 / 22
What does 'federated computational governance' mean in Data Mesh?
Federated computational governance balances autonomy and interoperability: domains agree on global standards (data formats, access policies, SLAs) but implement them independently within their domain.
4 / 22
What is 'self-serve data infrastructure as a platform' in Data Mesh?
Self-serve data infrastructure means a platform team builds internal tools (data mesh platform) that make it easy for domain teams to create and operate data products without deep data engineering expertise.
5 / 22
Which is a key difference between a Data Mesh and a Data Lake architecture?
A Data Lake centralises data storage and ownership in a data team. Data Mesh distributes ownership to the domains that generate data, treating the data lake as just one possible storage technology — not the architecture itself.
6 / 22
PR Description
Subject: Refactor User Profile API - Added Rate Limiting
… This PR implements rate limiting to prevent abuse of the user profile endpoint. We've exposed a new /user/{userId}/rateLimit API endpoint for managing limits, and integrated it into the main profile service.
(Reviewer: John Doe)The correct answer highlights that the PR description effectively communicates the core change – the introduction of a new API endpoint for managing rate limits. A good PR description within a Data Mesh context should also briefly explain the rationale behind this decision (e.g., preventing abuse) and how it aligns with domain-specific data ownership. Options A, C, and D are incorrect because they either miss key details about the architectural change or fail to connect the implementation back to the broader principles of the Data Mesh – specifically, that each domain is responsible for managing its own rate limiting strategy and exposing it through a well-defined API.
7 / 22
John Doe (the reviewer) comments on this PR: 'This is good work adding rate limiting. However, when discussing the data mesh principles, I'm unclear how the team intends to manage the new /user/{userId}/rateLimit API endpoint's data – specifically, who *owns* its lifecycle and governance? It feels like we're creating a siloed domain without considering broader implications. Which of the following best reflects the Data Mesh principle John is implicitly referencing?
The core of Data Mesh revolves around distributed ownership. John's comment highlights this – he's questioning who is responsible for the lifecycle of the rate limit data. Option A incorrectly suggests centralized control, while B misrepresents federated governance as purely central management. Option D describes a different architectural pattern (self-serve infrastructure), and doesn't address the fundamental principle of domain ownership. Therefore, option C accurately reflects that each domain – in this case, the user profile domain – must own its data, including the rate limit API endpoint, ensuring autonomy and accountability.
8 / 22
Reviewer John Doe is raising concerns about the new `/user/{userId}/rateLimit` API endpoint. He's questioning who should be responsible for managing its data – specifically, defining its schema, ensuring quality, and handling updates over time. This aligns with a core Data Mesh principle focused on distributed responsibility. Which of the following best captures John's concern?
John's concern directly relates to 'domain ownership of data,' a fundamental principle of Data Mesh. This means each domain – in this case, likely the team responsible for user profiles – is accountable for *all* aspects of its data, from creation and transformation to quality and lifecycle management. Options A and D represent centralized control which goes against Data Mesh's decentralized approach; option B suggests an inappropriate level of responsibility without a defined governance framework. The correct answer emphasizes that the relevant domain team must own the data within their scope.
9 / 22
PR Description
Subject: Refactor User Profile API - Added Rate Limiting
… This PR implements rate limiting to prevent abuse of the user profile endpoint. We've exposed a new /user/{userId}/rateLimit API endpoint for managing limits, and integrated it into the main profile service.
(Reviewer: John Doe)The correct answer highlights that the PR description effectively communicates the core change – the introduction of a new API endpoint for managing rate limits. A good PR description within a Data Mesh context should also briefly explain the rationale behind this decision (e.g., preventing abuse) and how it aligns with domain-specific data ownership. Options A, C, and D are incorrect because they either miss key details about the architectural change or fail to connect the implementation back to the broader principles of the Data Mesh – specifically, that each domain is responsible for managing its own rate limiting strategy and exposing it through a well-defined API.
10 / 22
John Doe (the reviewer) comments on this PR: 'This is good work adding rate limiting. However, when discussing the data mesh principles, I'm unclear how the team intends to manage the new /user/{userId}/rateLimit API endpoint's data – specifically, who *owns* its lifecycle and governance? It feels like we're creating a siloed domain without considering broader implications. Which of the following best reflects the Data Mesh principle John is implicitly referencing?
The core of Data Mesh revolves around distributed ownership. John's comment highlights this – he's questioning who is responsible for the lifecycle of the rate limit data. Option A incorrectly suggests centralized control, while B misrepresents federated governance as purely central management. Option D describes a different architectural pattern (self-serve infrastructure), and doesn't address the fundamental principle of domain ownership. Therefore, option C accurately reflects that each domain – in this case, the user profile domain – must own its data, including the rate limit API endpoint, ensuring autonomy and accountability.
11 / 22
Reviewer John Doe is raising concerns about the new `/user/{userId}/rateLimit` API endpoint. He's questioning who should be responsible for managing its data – specifically, defining its schema, ensuring quality, and handling updates over time. This aligns with a core Data Mesh principle focused on distributed responsibility. Which of the following best captures John's concern?
John's concern directly relates to 'domain ownership of data,' a fundamental principle of Data Mesh. This means each domain – in this case, likely the team responsible for user profiles – is accountable for *all* aspects of its data, from creation and transformation to quality and lifecycle management. Options A and D represent centralized control which goes against Data Mesh's decentralized approach; option B suggests an inappropriate level of responsibility without a defined governance framework. The correct answer emphasizes that the relevant domain team must own the data within their scope.
12 / 22
PR Description
Subject: Refactor User Profile API - Added Rate Limiting
… This PR implements rate limiting to prevent abuse of the user profile endpoint. We've exposed a new /user/{userId}/rateLimit API endpoint for managing limits, and integrated it into the main profile service.
(Reviewer: John Doe)The correct answer highlights that the PR description effectively communicates the core change – the introduction of a new API endpoint for managing rate limits. A good PR description within a Data Mesh context should also briefly explain the rationale behind this decision (e.g., preventing abuse) and how it aligns with domain-specific data ownership. Options A, C, and D are incorrect because they either miss key details about the architectural change or fail to connect the implementation back to the broader principles of the Data Mesh – specifically, that each domain is responsible for managing its own rate limiting strategy and exposing it through a well-defined API.
13 / 22
John Doe (the reviewer) comments on this PR: 'This is good work adding rate limiting. However, when discussing the data mesh principles, I'm unclear how the team intends to manage the new /user/{userId}/rateLimit API endpoint's data – specifically, who *owns* its lifecycle and governance? It feels like we're creating a siloed domain without considering broader implications. Which of the following best reflects the Data Mesh principle John is implicitly referencing?
The core of Data Mesh revolves around distributed ownership. John's comment highlights this – he's questioning who is responsible for the lifecycle of the rate limit data. Option A incorrectly suggests centralized control, while B misrepresents federated governance as purely central management. Option D describes a different architectural pattern (self-serve infrastructure), and doesn't address the fundamental principle of domain ownership. Therefore, option C accurately reflects that each domain – in this case, the user profile domain – must own its data, including the rate limit API endpoint, ensuring autonomy and accountability.
14 / 22
Reviewer John Doe is raising concerns about the new `/user/{userId}/rateLimit` API endpoint. He's questioning who should be responsible for managing its data – specifically, defining its schema, ensuring quality, and handling updates over time. This aligns with a core Data Mesh principle focused on distributed responsibility. Which of the following best captures John's concern?
John's concern directly relates to 'domain ownership of data,' a fundamental principle of Data Mesh. This means each domain – in this case, likely the team responsible for user profiles – is accountable for *all* aspects of its data, from creation and transformation to quality and lifecycle management. Options A and D represent centralized control which goes against Data Mesh's decentralized approach; option B suggests an inappropriate level of responsibility without a defined governance framework. The correct answer emphasizes that the relevant domain team must own the data within their scope.
15 / 22
PR Description
Subject: Refactor User Profile API - Added Rate Limiting
… This PR implements rate limiting to prevent abuse of the user profile endpoint. We've exposed a new /user/{userId}/rateLimit API endpoint for managing limits, and integrated it into the main profile service.
(Reviewer: John Doe)The correct answer highlights that the PR description effectively communicates the core change – the introduction of a new API endpoint for managing rate limits. A good PR description within a Data Mesh context should also briefly explain the rationale behind this decision (e.g., preventing abuse) and how it aligns with domain-specific data ownership. Options A, C, and D are incorrect because they either miss key details about the architectural change or fail to connect the implementation back to the broader principles of the Data Mesh – specifically, that each domain is responsible for managing its own rate limiting strategy and exposing it through a well-defined API.
16 / 22
John Doe (the reviewer) comments on this PR: 'This is good work adding rate limiting. However, when discussing the data mesh principles, I'm unclear how the team intends to manage the new /user/{userId}/rateLimit API endpoint's data – specifically, who *owns* its lifecycle and governance? It feels like we're creating a siloed domain without considering broader implications. Which of the following best reflects the Data Mesh principle John is implicitly referencing?
The core of Data Mesh revolves around distributed ownership. John's comment highlights this – he's questioning who is responsible for the lifecycle of the rate limit data. Option A incorrectly suggests centralized control, while B misrepresents federated governance as purely central management. Option D describes a different architectural pattern (self-serve infrastructure), and doesn't address the fundamental principle of domain ownership. Therefore, option C accurately reflects that each domain – in this case, the user profile domain – must own its data, including the rate limit API endpoint, ensuring autonomy and accountability.
17 / 22
Reviewer John Doe is raising concerns about the new `/user/{userId}/rateLimit` API endpoint. He's questioning who should be responsible for managing its data – specifically, defining its schema, ensuring quality, and handling updates over time. This aligns with a core Data Mesh principle focused on distributed responsibility. Which of the following best captures John's concern?
John's concern directly relates to 'domain ownership of data,' a fundamental principle of Data Mesh. This means each domain – in this case, likely the team responsible for user profiles – is accountable for *all* aspects of its data, from creation and transformation to quality and lifecycle management. Options A and D represent centralized control which goes against Data Mesh's decentralized approach; option B suggests an inappropriate level of responsibility without a defined governance framework. The correct answer emphasizes that the relevant domain team must own the data within their scope.
18 / 22
During a standup meeting, Sarah mentions the team is adopting a Data Mesh architecture. Mark asks: 'How does this relate to the concept of 'domain ownership'?'. Which of the following best describes that relationship?
Mark needs to ensure everyone understands how data domains align with business capabilities.
The core of Data Mesh is decentralized domain ownership. This means each domain team (e.g., 'User Profiles', 'Orders') is responsible for *their* data – its schema, quality, and access policies. Centralized control isn't the goal; it's about empowering teams to own their data products, not managing a monolithic data lake.
19 / 22
You receive this Slack message from a team member:
'Just finished designing the new user event stream. We're exposing it as a fully governed data product with clear SLAs and versioning. It's completely self-serve – developers can consume it directly without needing to contact the data platform team.'
Which Data Mesh principle is MOST prominently illustrated in this message?
'Self-Serve Data Infrastructure as a Platform' is central to Data Mesh. It emphasizes providing the necessary tools and infrastructure for domain teams to build and manage their data products independently – reducing friction and enabling agility. The other options represent related but distinct principles; this one focuses on the *infrastructure* aspect.
20 / 22
Consider a scenario: The 'Payments' domain team in a Data Mesh environment is responsible for managing transaction data. They've built a new API endpoint to expose this data to the 'Reporting' domain. Which of the following statements BEST describes how federated computational governance would apply?
'Federated computational governance ensures alignment on key metrics and operational standards across domains, enabling interoperability'.
Federated computational governance is about *alignment*, not control. It's a collaborative approach where domain teams work together to define shared standards – like key performance indicators (KPIs), service level agreements (SLAs), and operational policies – that ensure data products can seamlessly interact with each other across the mesh. This avoids silos and promotes interoperability.
21 / 22
A developer, Alex, is reviewing a PR that introduces a new API endpoint for tracking user activity. The PR description states: 'This PR implements rate limiting to prevent abuse of the user profile endpoint.' Which Data Mesh principle does this action MOST directly support?
Rate Limiting helps ensure data products are designed with resilience and security in mind.
'Domain-Oriented Data Management' emphasizes that each domain team is responsible for the quality and resilience of *their* data products. Rate limiting—protecting against abuse—is a crucial aspect of ensuring a specific domain's data product operates effectively and securely within the mesh. While all options are relevant, this scenario directly relates to how a domain manages its data.
22 / 22
You're discussing Data Mesh with a new team member, Ben. He asks: 'What's the benefit of avoiding a centralized data lake?'
Which of the following is the MOST accurate response?
'A central data lake can quickly become a bottleneck and single point of failure, hindering agility and innovation'.
A key problem with traditional data lakes is they often become centralized bottlenecks and single points of failure. This hinders agility and innovation because changes require coordination across the entire lake. Data Mesh's decentralized approach avoids this by empowering domains to manage their own data products independently.
Frequently Asked Questions
What does the "Data Mesh — Core Principles Vocabulary" exercise practise?
Learn the four principles of Data Mesh: domain ownership, data as a product, self-serve infrastructure, and federated governance.
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 Mesh Architecture 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 Mesh — Core Principles Vocabulary" part of a larger series?
Yes — it's one exercise in the Data Mesh Architecture 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 Mesh Architecture category page for related exercises, or browse the main Exercises hub for other IT English topics.