Practice federated governance vocabulary: global vs. local governance, computational policies, governance by design, federated data catalog, and platform vs. domain team roles.
0 / 18 completed
1 / 18
What does 'computational governance policies' mean in a data mesh context?
Computational governance policies are governance rules expressed as code and automatically enforced — for example, a policy that every data product must have a declared schema and owner, checked programmatically rather than manually.
2 / 18
A team says 'The platform team sets standards; domain teams execute.' What governance model does this describe?
This describes federated governance — the platform or central team defines global interoperability standards and policies, while individual domain teams are responsible for implementing those standards within their data products.
3 / 18
What is a 'federated data catalog' in data mesh?
A federated data catalog combines domain-owned metadata (each team publishes their own data product descriptions) with a unified discovery interface, so consumers can find data products across all domains without central control.
4 / 18
What is the difference between 'global governance' and 'local governance' in data mesh?
Global governance covers standards that enable interoperability across the mesh — like schema formats, security classifications, and SLA definitions. Local governance is each domain's responsibility — their data quality rules, transformation logic, and product-specific policies.
5 / 18
What does 'governance by design' mean?
'Governance by design' means governance is built into the platform and product standards from the start — rather than applied retroactively — so data products are compliant by default through the infrastructure and tooling they use.
6 / 18
PR Description
Subject: Refactor User Profile Service - Adding Data Validation
This PR introduces data validation for user profile fields to prevent incorrect data from entering the system. We've implemented checks on name length, email format, and phone number structure. Note: This is a foundational change impacting multiple services.
@john.doe, please review and confirm this aligns with our current governance strategy regarding data quality.
This question tests understanding of how governance is discussed *within* a development workflow. The PR description highlights a technical change (data validation) but crucially asks for review regarding 'governance strategy.' Option A misinterprets 'insufficient' as a purely technical criticism; the core issue here is about aligning the work with broader policies. Options C and D are too extreme – while data quality *is* important, the PR's focus on immediate implementation is reasonable, demanding further discussion about its governance context. Selecting option 2 acknowledges this need for contextualization.
7 / 18
@john.doe's comment in the PR description, 'Please review and confirm this aligns with our current governance strategy regarding data quality,' suggests what key aspect of federated governance? Consider the broader context: multiple teams contribute to a single service, each with some autonomy but also bound by shared standards.
This question tests understanding of *distributed* governance within a federated model. Option A is incorrect because it describes centralized control, which contradicts the core idea of autonomy for domain teams. Option B misinterprets 'governance strategy' - it's not about enforcing uniform rules; rather, it's about aligning efforts towards quality. Option C correctly identifies collaborative governance – teams own their data but operate within defined boundaries, and option D is a reactive approach that doesn't address the proactive nature of establishing standards in the first place.
8 / 18
PR Description
Subject: Refactor User Profile Service - Adding Data Validation
This PR introduces data validation for user profile fields to prevent incorrect data from entering the system. We've implemented checks on name length, email format, and phone number structure. Note: This is a foundational change impacting multiple services.
@john.doe, please review and confirm this aligns with our current governance strategy regarding data quality.
This question tests understanding of how governance is discussed *within* a development workflow. The PR description highlights a technical change (data validation) but crucially asks for review regarding 'governance strategy.' Option A misinterprets 'insufficient' as a purely technical criticism; the core issue here is about aligning the work with broader policies. Options C and D are too extreme – while data quality *is* important, the PR's focus on immediate implementation is reasonable, demanding further discussion about its governance context. Selecting option 2 acknowledges this need for contextualization.
9 / 18
@john.doe's comment in the PR description, 'Please review and confirm this aligns with our current governance strategy regarding data quality,' suggests what key aspect of federated governance? Consider the broader context: multiple teams contribute to a single service, each with some autonomy but also bound by shared standards.
This question tests understanding of *distributed* governance within a federated model. Option A is incorrect because it describes centralized control, which contradicts the core idea of autonomy for domain teams. Option B misinterprets 'governance strategy' - it's not about enforcing uniform rules; rather, it's about aligning efforts towards quality. Option C correctly identifies collaborative governance – teams own their data but operate within defined boundaries, and option D is a reactive approach that doesn't address the proactive nature of establishing standards in the first place.
10 / 18
PR Description
Subject: Refactor User Profile Service - Adding Data Validation
This PR introduces data validation for user profile fields to prevent incorrect data from entering the system. We've implemented checks on name length, email format, and phone number structure. Note: This is a foundational change impacting multiple services.
@john.doe, please review and confirm this aligns with our current governance strategy regarding data quality.
This question tests understanding of how governance is discussed *within* a development workflow. The PR description highlights a technical change (data validation) but crucially asks for review regarding 'governance strategy.' Option A misinterprets 'insufficient' as a purely technical criticism; the core issue here is about aligning the work with broader policies. Options C and D are too extreme – while data quality *is* important, the PR's focus on immediate implementation is reasonable, demanding further discussion about its governance context. Selecting option 2 acknowledges this need for contextualization.
11 / 18
@john.doe's comment in the PR description, 'Please review and confirm this aligns with our current governance strategy regarding data quality,' suggests what key aspect of federated governance? Consider the broader context: multiple teams contribute to a single service, each with some autonomy but also bound by shared standards.
This question tests understanding of *distributed* governance within a federated model. Option A is incorrect because it describes centralized control, which contradicts the core idea of autonomy for domain teams. Option B misinterprets 'governance strategy' - it's not about enforcing uniform rules; rather, it's about aligning efforts towards quality. Option C correctly identifies collaborative governance – teams own their data but operate within defined boundaries, and option D is a reactive approach that doesn't address the proactive nature of establishing standards in the first place.
12 / 18
PR Description
Subject: Refactor User Profile Service - Adding Data Validation
This PR introduces data validation for user profile fields to prevent incorrect data from entering the system. We've implemented checks on name length, email format, and phone number structure. Note: This is a foundational change impacting multiple services.
@john.doe, please review and confirm this aligns with our current governance strategy regarding data quality.
This question tests understanding of how governance is discussed *within* a development workflow. The PR description highlights a technical change (data validation) but crucially asks for review regarding 'governance strategy.' Option A misinterprets 'insufficient' as a purely technical criticism; the core issue here is about aligning the work with broader policies. Options C and D are too extreme – while data quality *is* important, the PR's focus on immediate implementation is reasonable, demanding further discussion about its governance context. Selecting option 2 acknowledges this need for contextualization.
13 / 18
@john.doe's comment in the PR description, 'Please review and confirm this aligns with our current governance strategy regarding data quality,' suggests what key aspect of federated governance? Consider the broader context: multiple teams contribute to a single service, each with some autonomy but also bound by shared standards.
This question tests understanding of *distributed* governance within a federated model. Option A is incorrect because it describes centralized control, which contradicts the core idea of autonomy for domain teams. Option B misinterprets 'governance strategy' - it's not about enforcing uniform rules; rather, it's about aligning efforts towards quality. Option C correctly identifies collaborative governance – teams own their data but operate within defined boundaries, and option D is a reactive approach that doesn't address the proactive nature of establishing standards in the first place.
14 / 18
A developer is reviewing a PR that adds a new API endpoint. The PR description includes the following line: 'This endpoint will be secured with OAuth 2.0.' Which of the following best describes a key governance consideration for this change?
Ensuring the security protocols are properly implemented and documented
This scenario tests understanding of API security governance. The PR mentions OAuth 2.0, indicating a need to ensure proper implementation and documentation for authentication and authorization – a core governance principle in securing APIs.
15 / 18
A team is using a microservices architecture. The team lead sends the following message to the development team: 'Each service should have its own dedicated database.' What governance aspect does this primarily address?
Data ownership and consistency
This question focuses on data governance in a microservices context. The team lead's statement highlights the need for clear ownership and consistency across independent services – a fundamental aspect of governing distributed systems.
16 / 18
During a standup meeting, a developer says: 'I've deployed the latest version of the payment processing service to production.' What type of governance is implicitly being addressed?
Operational Governance – ensuring deployments align with established processes
This tests understanding of operational governance. The developer's action – deploying to production – needs oversight to ensure it meets defined processes and doesn't introduce unintended risks or conflicts with other systems.
17 / 18
A Slack message reads: 'Please update the documentation for the new API endpoint to include rate limiting details.' What aspect of governance is highlighted in this message?
Operational Governance – ensuring systems meet requirements
This question assesses understanding of governance related to operational aspects. The Slack message emphasizes the importance of documentation for API endpoints, which is a key component of ensuring that systems function correctly and meet defined performance requirements.
18 / 18
A developer receives an API response indicating: 'Request denied - Rate limit exceeded.' What governance principle is this response illustrating?
Resource Management – controlling access to prevent overuse
This question tests knowledge of resource governance. The API response shows a rate limit being enforced, demonstrating control over resources and preventing abuse – a core principle for managing system capacity and stability.
What does the "Federated Governance Vocabulary Quiz" exercise practise?
Practice federated governance vocabulary: global vs. local governance, computational policies, governance by design, federated data catalog, and platform vs. domain team roles.
How many questions are in this exercise?
This exercise has 18 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 "Federated Governance Vocabulary Quiz" 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.