CompTIA Data+ common mistakes
CompTIA Data+ · Understand the traps and how to avoid them.
Treating every numeric-looking column as continuous and computing mean and standard deviation without checking whether it is a coded category or an ordinal scale.
Candidates equate integer storage with interval/ratio measurement, but the exam tests schema interpretation and measurement scales; coded values like 1=red, 2=blue are not quantities.
What to do instead
Classify each field by measurement scale and storage type before summarizing: nominal fields get counts/mode, ordinal fields get median/mode, and interval/ratio fields get mean/standard deviation only when appropriate.
Choosing normalization or denormalization based on generic 'reduce redundancy' advice without matching it to the workload, such as normalizing a reporting star schema or denormalizing an OLTP transaction table.
Both techniques reduce or manage redundancy for different goals; candidates memorize definitions but not the performance-versus-integrity tradeoff the scenario is testing.
What to do instead
State the workload first: OLTP favors normalized schemas for integrity; analytical/reporting models often favor denormalized star schemas for query performance. Justify the choice with the scenario's read/write pattern.
Defaulting to simple random sampling when the population has obvious strata or a repeating ordering pattern that calls for stratified or systematic sampling.
Candidates see 'sample' and pick 'random' without reading constraints such as subgroups, proportional representation, or ordered lists.
What to do instead
Inspect the population description for strata, ordering, and cost constraints before selecting a method; choose stratified when subgroups must be represented and systematic when a random start over an ordered frame is appropriate.
Reporting a mining result as 'X causes Y' when the analysis only shows association, and failing to check for confounding variables.
Algorithm output often presents strong patterns, and candidates focus on the finding rather than the study design and alternative explanations.
What to do instead
Phrase results as associations unless a controlled design supports causation; explicitly check confounders, selection bias, and whether the comparison groups were comparable.
Averaging percentages across groups or computing percent change from already-aggregated rates instead of from the underlying numerators and denominators.
Candidates apply arithmetic to rates as if they were counts, which ignores weighting and can produce Simpson's paradox or an incorrect base.
What to do instead
Recompute from raw numerators and denominators, use weighted averages for group rates, and verify the base and denominator before reporting any percent change.
Treating NULL as zero or as an empty string in aggregations, filters, and joins.
SQL NULL semantics are nonintuitive: NULL is not equal to anything, propagates through expressions, and is excluded by many aggregates and inner joins.
What to do instead
Use IS NULL / IS NOT NULL and COALESCE explicitly; decide and document the null policy per metric; test join cardinality and whether outer joins are needed before aggregating.
Selecting a pie chart for many categories or a line chart for unordered categorical data.
Candidates choose a familiar chart type instead of mapping the visualization to the data type and the analytical task being communicated.
What to do instead
Match chart to task: bar charts for category comparison, line charts for trends over an ordered/time dimension, scatter plots for relationships, and pie charts only for a few parts of a whole.
Using red/green as the only encoding or truncating a bar chart's y-axis without disclosure.
Candidates focus on visual appeal and miss accessibility and honest-scale requirements that affect interpretation.
What to do instead
Use colorblind-safe palettes and redundant labels, start bar charts at zero, label axes and units, and disclose any truncated scale or dual axis.
Confusing data governance roles such as data owner, data steward, and data custodian, or labeling a quality issue with the wrong dimension such as calling a missing-value problem 'accuracy' instead of 'completeness'.
The terms overlap in everyday use, and candidates memorize definitions without mapping them to concrete responsibilities and defect symptoms.
What to do instead
Build a role matrix: owner is accountable, steward defines rules and quality, custodian implements storage/security. Build a quality-dimension matrix and classify each defect by symptom before answering.
Treating privacy requirements as generic security and missing retention limits, consent/purpose limitation, and de-identification distinctions such as pseudonymization versus anonymization.
Candidates skim legal/privacy terms in the governance domain and default to 'encrypt it' rather than applying data minimization and lifecycle controls.
What to do instead
Memorize the core privacy principles: purpose limitation, data minimization, retention schedule, consent, and the difference between pseudonymization (reversible with a key) and anonymization (not re-identifiable). Apply them directly to the scenario.