Data Governance Interview Questions – Practice Quiz for All Levels

A data governance framework is the organizing structure of policies, processes, roles, standards, and metrics that ensures data is managed as a trusted asset. It is not itself a technology stack, a regulation, or a database type — those are tools, external mandates, and infrastructure that the framework governs or operates alongside.

The catalog is the discoverability layer of a governance program: policies and stewardship only pay off if people can actually find and trust the data they govern. Without one, tribal knowledge ('ask Priya, she knows which orders table is real') becomes the de facto catalog, which doesn't scale and doesn't survive Priya changing teams.

A governance operating model is the organizational framework that translates governance strategy into execution by defining roles, responsibilities, decision rights, and processes for managing data assets.

Governance is about setting policies, standards, and accountability — deciding what should be done and who is responsible. Configuring ETL pipeline schedules is an operational, day-to-day execution task owned by Data Management / data engineering teams. Lines 2–4 and 6 are all governance-level activities (policy definition, ownership roles, architecture principles, compliance oversight). Line 5 — 'configure ETL pipeline schedules for daily loads' — is the management task that does not belong on the governance board's responsibility list.

DAMA-DMBOK frames data governance as the function that exercises authority and control — planning, monitoring, and enforcement — over the rest of data management: it decides who owns a domain, what 'active customer' means, and what the retention policy is. Data management is the broader umbrella of functions (architecture, quality, integration, security, and so on) that actually deliver, protect, and operate on data day to day, guided by what governance decided. Option (c) inverts the relationship, and neither role is optional just because a company happens to be unregulated — even an internal analytics team benefits from someone deciding what a metric means and who's accountable when it's wrong.

Accuracy, completeness, timeliness, and consistency are core data quality dimensions (alongside others like validity and uniqueness) — they describe properties of the data's fitness for use. Encryption strength is a data security control, not a quality dimension: a perfectly encrypted column of wrong customer addresses is still low-quality data, and a plaintext column of correct ones is still high-quality data from a quality standpoint, even though it's a security problem. Interviewers use this distinction to check whether a candidate conflates 'protecting data' with 'the data being right,' which are separate governance concerns handled by different controls.

False. A data owner is typically the accountable, business-side role for a data domain — usually a senior stakeholder who answers for the domain's quality, risk, and policy decisions, even though they rarely touch the data directly. A data steward is typically the responsible, operational role: maintaining definitions, chasing down quality issues, and enforcing the owner's policy day to day, usually without final decision authority of their own. The distinction matters in practice — when a definition conflict needs a ruling, the steward escalates to the owner rather than deciding it unilaterally, which is exactly the separation a RACI model is meant to preserve.

Without a golden record, 'the customer's phone number' has a different answer depending on which system you ask, and every downstream report quietly inherits whichever source it happens to read from. MDM's whole value proposition is collapsing that ambiguity into one number everyone can agree is authoritative.

The DAMA-DMBOK framework treats data quality management, metadata management, and data architecture/modeling as core knowledge areas within data governance. Predictive model deployment pipelines fall under MLOps / advanced analytics operations, not data governance components.

The DAMA Wheel places data governance at the hub, with the ten other knowledge areas (data architecture, modeling, storage & operations, security, integration, document/content management, reference & master data, data warehousing/BI, metadata management, and data quality) arranged as spokes around it. That layout is the diagram's whole argument: governance isn't itself a data-management activity like modeling a schema or running an ETL job — it's the oversight function that sets policy and accountability for every spoke. Data architecture, quality, and metadata are each just one spoke, not the hub, which is why picking any of them mistakes a discipline governance oversees for the oversight function itself.

Classification tiers exist to attach handling rules to data based on sensitivity: what access/encryption controls apply (a), what approval external sharing needs (b), and how long it can be retained before disposal (d) all follow directly from which tier a dataset sits in. Classification says nothing about whether the values themselves are technically correct (c) — that's a data quality concern, not a sensitivity label, and tagging a column 'Restricted' doesn't fix a typo in it. And an internal sensitivity label has no relationship to public search-engine ranking (e), which depends on entirely different, external signals.

False. Article 17(1) does give data subjects a right to erasure on specific grounds — the data is no longer necessary for its original purpose, consent is withdrawn, the subject objects and no overriding legitimate ground exists, or the processing was unlawful. But Article 17(3) then carves out exceptions where a controller does not have to erase: exercising the right to freedom of expression and information, complying with a legal obligation or a task carried out in the public interest, public-health reasons, archiving/research/statistical purposes, or the establishment/exercise/defense of legal claims. A data governance program that treats every erasure request as an automatic, unconditional delete misses that these exceptions exist and are exactly why 'right to erasure' requests go through a review step rather than a blind delete script.

Lineage is fundamentally a graph: nodes are datasets/transformations, edges are 'flows into.' Its practical payoff shows up exactly when something breaks or someone asks a scope question — an incident ('which upstream table caused this') or a compliance request ('where does this person's data live') both reduce to walking that graph instead of interviewing engineers about pipelines they may not fully remember. Without lineage, both tasks devolve into tribal knowledge and grep-ing through dbt models or Airflow DAGs by hand, which doesn't scale past a handful of pipelines.

Ingestion has to happen before anything else can run. Standardization has to come before matching because fuzzy/probabilistic matching on raw, inconsistently formatted data (one system storing 'St.' and another 'Street') produces unreliable scores — cleansing first is what makes the match step trustworthy. Matching has to identify candidate duplicates before merge logic has anything to act on, and survivorship rules only make sense once you already know which records are being merged together. Publishing is necessarily last, since there's no golden record to hand downstream systems until the merge step has produced one.

The issue starts at tier "Operational" and resolved is False, so the loop enters. Iteration 1: appends "Data Steward", sets current to "Tactical". Iteration 2: appends "Data Domain Owner", sets current to "Strategic". Iteration 3: appends "Data Governance Council", sets current to None. The loop then exits because current is falsy. Joining with " -> " yields: Data Steward -> Data Domain Owner -> Data Governance Council.

covered includes every domain with stewards[d] > 0: Customer (2), Finance (1), and Supply Chain (3) → 3 domains. gaps includes every domain with stewards[d] == 0: Product (0) → 1 domain. The f-string formats as Covered: 3/4, Gaps: 1, where len(domains) is 4.

The DAMA-DMBOK positions data governance as the oversight function that establishes decision rights and accountability for data, while data management comprises the operational disciplines (data modeling, data quality, data security, etc.) that carry out the decisions governance sets. The blank asks for the concept governance defines: accountability for data assets.

Governance is the authority that defines who decides what (decision rights), while management is the execution layer that carries out those decisions. The blank is filled by 'decision rights,' the core artifact governance produces to separate itself from operational management.

The pipeline proceeds as follows: (1) The crawler must first establish and authenticate a connection to the data source. (2) Once connected, it extracts schema-level technical metadata — tables, columns, data types, constraints — by reading the source's system catalog. (3) With the schema known, a profiling job samples or scans the data to compute statistical metadata such as null rates, distinct counts, and min/max values. (4) Classification and tagging (e.g., automated PII detection) logically follows profiling because classification rules depend on the data-content statistics and patterns revealed during profiling. (5) Finally, the consolidated technical, statistical, and classification metadata is indexed and published into the catalog so users can search and discover assets. Each step has a strict dependency on its predecessor: you cannot extract schema without a connection, you cannot profile without knowing the schema, you cannot classify content without profiling results, and you cannot publish what has not yet been collected.

The policy's anchor date is account closure, but the query filters on account_created_at — when the account was first created, not when it was closed. A ten-year-old account closed yesterday would already be past the '400 days' filter on creation date and get purged immediately, while a two-year-old account created recently but closed last month wouldn't age out for well over a year. This is a common, easy-to-miss retention bug: the policy's English description and the query's actual anchor column silently drift apart, and nothing about the SQL fails loudly — it just quietly purges (or retains) data on the wrong schedule, which is exactly the kind of gap a data governance/compliance audit is designed to catch before a regulator does.

The RACI split matters because authority and bandwidth rarely sit in the same person: an owner senior enough to arbitrate a cross-team definition dispute is rarely the person with the day-to-day time to chase down a broken pipeline, and vice versa. A steward with no accountable owner behind them has no leverage when a peer team's system owner says no; an owner with no steward has no one actually doing the stewardship work. Interviewers probe this distinction because a candidate who can only say 'someone owns the data' hasn't thought about who has the standing to force a resolution versus who does the grinding work of maintaining it.

The steward, doing day-to-day operational work, is typically the first to notice the conflict, but resolving a cross-domain definition dispute usually exceeds a steward's own decision authority, so it goes to the accountable owner(s) next. When even the owners can't agree — which is common when the disagreement crosses business units with competing incentives — the governance council exists precisely as the escalation body with the standing to issue a binding ruling. That ruling only has lasting effect once it's codified into an actual policy/standard (otherwise it's just a meeting outcome nobody can point back to), and the whole exercise is pointless unless the resolved definition is then communicated back out to the teams who were using the old, conflicting one.

The DAMA-DMBOK2 defines 11 Knowledge Areas in total. On the DAMA Wheel, Data Governance sits at the center (hub) while the remaining ten knowledge areas (Data Architecture, Data Modeling & Design, Data Storage & Operations, Data Security, Data Integration & Interoperability, Document & Content Management, Reference & Master Data Management, Data Warehousing & Business Intelligence, Metadata Management, and Data Quality) are arranged around the rim. This structural choice reflects DMBOK2's definition of Data Governance as 'the exercise of authority, control, and shared decision making over the management of data assets,' positioning it as the oversight function that coordinates and constrains all other data management activities.

Least privilege is about scope, not just read-vs-write — option (d)'s reasoning is the exact misconception this question is testing for. A schema-wide SELECT on raw customer_pii, granted to a role used by 'every BI dashboard and every ad-hoc SQL user,' means every analyst who can run a query anywhere in the org can pull unmasked SSNs, dates of birth, or whatever else lives in that schema, whether or not their actual job requires it. That's a large blast radius for a single compromised credential or a single careless analyst, and it's precisely the finding a least-privilege / data-classification audit exists to surface: sensitive-tier data should be reachable through a narrower role, row/column-level security, or masked views, not a broad shared grant sized for convenience rather than need.

The DMBOK's central architectural decision is to make Governance the hub of the wheel, not a sibling function. A correct answer must identify (a) the stewardship program as the embedding mechanism, (b) the policy-setting / oversight role that elevates governance above the other areas, and (c) the distinction between governance authority and operational execution within the other knowledge areas.