FDST-BDS common mistakes
FDST-BDS · Understand the traps and how to avoid them.
Treating data stewardship as a purely technical role and choosing answers where stewards write ETL code or tune databases, instead of answers where stewards own definitions, quality rules, and issue resolution within a business domain.
Candidates with engineering backgrounds map 'steward' onto roles they know (developer, DBA) and overlook that stewardship is a business accountability paired with a technical custodian.
What to do instead
Before answering, separate the three roles explicitly: owner (accountable for the domain), steward (defines and enforces standards and quality for a subject area), custodian (operates the platform). Eliminate any option that gives the steward hands-on infrastructure duties or gives the custodian decision rights over business definitions.
Selecting 'assign accountability to the CDO' or 'create a council' as the fix for every governance symptom, even when the scenario describes a missing decision-rights process or an unresolved definition conflict that needs an escalation path, not another committee.
Governance questions reward structural answers, so candidates over-apply org-chart solutions and stop reading the actual symptom in the stem.
What to do instead
Classify the symptom first: unclear ownership, conflicting definitions, missing policy, or unenforced policy. Match the remedy to the class (RACI for ownership, glossary arbitration for definitions, policy for missing rules, controls and metrics for enforcement). Only choose a new body when the gap is genuinely cross-functional decision-making.
Normalizing to third normal form by reflex on modeling questions, even when the stem describes high-volume analytical reads, slowly changing dimensions, or repeated denormalization for query performance.
OLTP normalization is taught first and drilled hardest, so it becomes the default answer and the candidate ignores the workload cues in the scenario.
What to do instead
Read for the workload before the model: transactional writes favor normalized structures; analytical and reporting workloads favor dimensional or denormalized designs. For dimensions, identify the change-handling requirement (Type 1 overwrite, Type 2 versioned rows with effective dates, Type 3 prior-value column) and pick the type the stem's history requirement demands.
Confusing a logical model with a physical model, or choosing a physical artifact (indexes, partitions, data types, tablespaces) as the answer to a question about conceptual or logical design.
The three model levels are described similarly in study material, and candidates answer with whatever artifact they associate with 'modeling' rather than the abstraction level asked for.
What to do instead
Anchor each level to its output: conceptual = entities and relationships in business terms; logical = attributes, keys, and relationships independent of any product; physical = types, indexes, partitions, and storage. Reject any option mentioning a vendor feature unless the stem explicitly asks for physical design.
Answering data quality questions with 'cleanse the data' instead of addressing the root cause, or choosing profiling when the stem asks for ongoing measurement against thresholds.
Cleansing feels productive and is the most familiar quality activity, so candidates skip the diagnosis step and the distinction between profiling, monitoring, and remediation.
What to do instead
Map the activity to its purpose: profiling discovers patterns and anomalies in unknown data; rule-based monitoring measures conformance against defined thresholds over time; remediation corrects records; root-cause analysis changes the source process. When a stem reports recurring defects after cleansing, the correct answer is almost always source-process or preventive control, not another cleanse.
Treating data quality dimensions as interchangeable, for example labeling a duplicate-customer problem as 'accuracy' or a stale-address problem as 'completeness', when the stem points to uniqueness or timeliness.
Dimensions overlap in casual speech, and candidates pick the dimension whose name sounds most serious rather than matching the definition to the observed defect.
What to do instead
Write the defect in one sentence, then test it against definitions: accuracy = conforms to the real-world fact; completeness = required values present; uniqueness = no unintended duplicates; timeliness = available and current when needed; consistency = agrees across systems; validity = conforms to format or domain rules. Choose the single dimension the defect violates most directly.
Choosing batch extraction as the integration pattern for scenarios that require near-real-time availability, or choosing real-time for scenarios where latency tolerance and volume make batch the sound choice.
Candidates associate 'modern' with streaming and 'legacy' with batch, and answer by fashion rather than by the stated latency, volume, and cost constraints.
What to do instead
Extract the latency requirement and the volume from the stem before evaluating options. If the business can tolerate hours and volumes are large, batch or micro-batch is correct; if downstream decisions depend on minutes, change data capture or event streaming is correct. Also check whether the question is about pattern (ETL vs ELT), protocol, or topology, and answer only that layer.
Applying encryption as the answer to every security scenario, including cases about who may see a column, about lawful basis for processing, or about detecting unauthorized access after the fact.
Encryption is the most memorable control, so it crowds out access control, minimization, masking, and monitoring, which are the actual answers to authorization and privacy questions.
What to do instead
Classify the control family the stem needs: preventive access control (roles, row- and column-level security), data protection at rest or in transit (encryption, tokenization), privacy limitation (purpose limitation, minimization, retention), or detective control (audit logging, anomaly monitoring). Match the family before choosing a specific mechanism, and prefer least-privilege answers over blanket restriction.
Confusing the star schema grain with the fact table's additive measures, or building a report question around a denormalized flat extract when the stem describes conformed dimensions shared across subject areas.
Grain, measures, and dimensions are taught together, so candidates blur which decision the question is actually testing and pick the option that sounds most like a data warehouse artifact.
What to do instead
State the grain in one sentence ('one row per order line') before evaluating options; measures must be true at that grain. For cross-subject reporting, look for conformed dimensions and a bus matrix rather than a single wide table. If the stem asks about aggregation behavior, check additivity (additive, semi-additive, non-additive) against the measure named.
Treating metadata and master data as the same asset, or choosing a metadata repository as the solution when the problem is duplicated customer records across source systems.
Both are 'data about data' in loose descriptions, and candidates default to the governance-sounding artifact instead of the entity-resolution one.
What to do instead
Separate the assets: metadata describes structure, lineage, and definitions; master data is the shared business entities (customer, product, employee). For duplicate or conflicting entity records, choose matching, survivorship, and golden-record creation. For lineage, impact analysis, or glossary questions, choose the metadata repository or catalog.
Answering analytics questions with a dashboard or visualization choice when the stem is asking about the analytical method, the statistical validity of a conclusion, or the difference between descriptive, diagnostic, predictive, and prescriptive analysis.
Reporting and analytics are taught as one topic, and candidates conflate the delivery mechanism with the analysis type, so they pick the tool instead of the technique.
What to do instead
Identify the question the analysis must answer: what happened (descriptive), why it happened (diagnostic), what will happen (predictive), what should be done (prescriptive). Then check the stem for a validity trap such as correlation presented as causation, a biased sample, or a metric that does not measure the stated goal, and choose the answer that addresses the method rather than the presentation layer.