Design a scalable data governance framework balancing autonomy and control

WHAT THIS TESTS: This question evaluates whether you understand how to scale data governance beyond a monolithic data lake by applying data mesh principles. The interviewer wants to see if you can balance decentralized domain ownership with centralized interoperability through automated policy enforcement rather than manual gatekeeping.

A GOOD ANSWER COVERS: First, domain-oriented ownership where each team owns its data products end-to-end, including operational and analytical data, rather than handing data off to a central platform team. Second, data as a product thinking, meaning each domain publishes datasets with clear SLAs, documentation, and schema contracts that consumers can discover and trust. Third, a self-serve data platform that provides shared infrastructure for cataloging, schema registry, and access control so domains do not build redundant tooling. Fourth, federated computational governance where policies are defined centrally but executed automatically via policy-as-code in CI/CD pipelines, such as schema compatibility checks, PII tagging, and role-based access controls that run before deployment. Fifth, a multi-plane platform architecture that separates the data infrastructure plane from the data product plane and the mesh experience plane.

COMMON WRONG ANSWERS: Proposing a central data platform team that manually approves every schema change or access request. Suggesting a single monolithic schema registry without domain-level autonomy. Ignoring the difference between operational and analytical data. Recommending heavy manual data stewardship instead of automated computational policies. Failing to mention data product SLAs or consumer contracts.

LIKELY FOLLOW-UPS: How would you handle breaking schema changes across multiple downstream consumers? What is your strategy for discovering and classifying sensitive data at scale? How do you measure the health of a data product? How would you migrate an existing monolithic data lake to this architecture over twelve months? What specific tools would you use for the schema registry and catalog, and why?

ONE CONCRETE EXAMPLE: Imagine a retail company with fifty engineering teams. The inventory domain publishes an events stream as a data product with an Avro schema registered in a centralized but federated schema registry. When inventory pushes a new schema version, automated CI/CD checks validate backward compatibility against all registered consumers. The data catalog auto-ingests metadata, tags PII fields via automated classification, and enforces access policies so only the analytics and finance domains can query pricing data. Governance is federated: a central council defines tagging and access standards, but each domain applies them through code, not tickets.

Source: martinfowler.com