Data Governance Engineer Interview Questions

Option B is the strongest: it reframes evaluation from feature comparison to use case definition (a maturity signal), names three specific evaluation criteria with their rationale (column-level lineage with GDPR erasure example, business glossary with bidirectional linking, API for programmatic access), evaluates four named tools with their strengths, weaknesses, and deployment model, specifies an implementation principle (launch with auto-discovered data, not an empty catalog), names the adoption metrics, and closes with the governance trap anti-pattern. Options C and D name the right tools and criteria but don't explain the rationale for each criterion, the tool trade-offs, or the implementation principles. Structure: use case definition first → criteria with rationale → tool comparison with trade-offs → implementation principles → adoption metrics → governance trap anti-pattern.

Option B is the strongest: it defines both levels with a concrete transformation example (LOWER() on email), explains why the compliance difference is categorical not incremental, gives the specific GDPR use case with the time comparison (weeks of manual audit vs seconds with column-level lineage), cites GDPR Article 30 by name, explains PII propagation discovery as an automated benefit, addresses impact analysis as a non-compliance use case, and names four tools with column-level lineage capability and their specific integration mechanisms. Options C and D correctly state that column-level lineage matters for GDPR erasure but don't explain the mechanism, the time savings, the propagation discovery benefit, or name the tools. Structure: definition of both levels with examples → categorical vs incremental compliance difference → GDPR erasure use case with time comparison → Article 30 → PII propagation discovery → impact analysis → tools with column-level capability.

Option B is the strongest: it defines six quality dimensions with a specific example for each (including timeliness with an 08:00 SLA example and consistency across systems), names three implementation tools with their comparative use cases (dbt for native stacks, Great Expectations for statistical rules, Soda Core for standalone YAML), specifies the enforcement mechanism (CI gate plus RAG dashboard plus automated incident creation), introduces the composite quality score as a catalog integration, and closes with the key principle about consumer-defined rules. Options A and C name the right tools but don't define the quality dimensions, compare the tools, or describe the enforcement architecture. Option D distributes responsibility correctly but gives no implementation detail. Structure: six quality dimensions with examples → three tools with comparative use cases → three enforcement mechanisms → composite quality score → consumer-defined rules principle.

Option B is the strongest: it provides a six-step strategy with specific detail at each step, defines a surrogate canonical customer ID, documents source authority per attribute (not just "CRM owns contact data" but which attributes within each system), describes the matching algorithm with specific techniques (Jaro-Winkler, E.164 normalisation, human review thresholds), names survivorship rules with concrete examples (most recently updated email, billing address preferred for payment-verified data), covers distribution via both Kafka event stream and MDM hub patterns, includes the governance layer with exception workflow, and names tools with a cost-sensitive alternative. Options A and C correctly identify the core problem (matching + authority) but don't provide the algorithmic approach, survivorship rules, or distribution pattern. Option D defers to the tool without demonstrating the strategy knowledge. Structure: six steps: entity definition → source mapping → matching algorithm → golden record + survivorship → distribution pattern → governance + exception handling → tool options.

Option B is the strongest: it defines three roles with named examples for each (VP of Sales, Chief Medical Officer), gives specific accountabilities for each role (not just role names), makes the critical observation that owners must have decision authority (not just accountability), explains why stewardship must be a formal job responsibility (not an add-on), names the design principles with their rationale (single owner for escalation clarity, domain alignment over technical team alignment), identifies the most common failure mode (owner without authority), and gives three health metrics for stewardship. Options A and C correctly name the three roles but don't specify the decision rights, the common failure mode, the health metrics, or the design principles. Option D focuses on adoption without defining the roles or principles. Structure: three roles with named examples → specific accountabilities per role → authority-not-just-accountability insight → design principles with rationale → common failure mode → three health metrics.