CompTIA Data+ DA0-002 · Free study guide

Objective 4.3 — Validate and troubleshoot reports

A broken report is a symptom, not a diagnosis. A slow page may originate in a source, transformation, model, network, or visual. Use a controlled approach: reproduce the symptom, isolate the layer, compare with an authoritative source, repair the cause, and verify correctness and performance.

Classify the symptom before changing the report

Record the version, user, time, filters, expected and actual results, and repeatability. A known-good period helps separate global failure from one source, role, or filter combination.

Separate load time, refresh rate, and data size

Load time is how long a report takes to open or respond. Measure stages rather than guessing. A query may scan too many rows, a join may multiply records, a model may contain unused high-cardinality fields, or a page may render too many visuals. Remedies include early filtering, required-field selection, correct joins, useful indexes, appropriate pre-aggregation, caching, and fewer visuals.

Optimization must preserve meaning. Monthly aggregation helps only when users do not need transaction detail.

Refresh rate is the update cadence: hourly, daily, or event driven. Refresh latency is the elapsed delay between a source event or source availability and its visibility in the report. A report can load quickly yet miss its scheduled refresh, refresh frequently yet surface late-arriving data, or refresh on time but load slowly for users. Inspect schedules, dependencies, credentials, limits, timeouts, late files, and time zones. Display the last successful data refresh, not the page-open time.

Data size affects scans, transfers, memory, and rendering. Consider rows, columns, field width, cardinality, and history. Restrict data to purpose, partition large histories, use appropriate incremental refresh, and archive by policy. A diagnostic sample must not silently replace complete output.

Trace broken filters, stale values, and corrupt data

A broken filter may reflect a value mismatch or a modeling fault. Check spelling, whitespace, case, nulls, date boundaries, data types, defaults, and parameters. Then inspect join keys, cardinality, filter direction, visual versus page scope, and role-based restrictions.

Reduce the report to one measure and filter, then restore conditions one at a time. Compare the result with an independent source query to isolate control, model, calculation, or data.

For stale data, compare timestamps across the system of record, landing data, transformed table, model, cache, and report. Check late dependencies, expired credentials, cache invalidation, snapshots, and time zones.

For corrupt data, stop publication when risk is material. Profile counts, nulls, keys, ranges, formats, duplicates, and category frequencies. Compare samples with the authoritative source and trace lineage backward. Quarantine invalid records rather than silently coercing them into plausible values.

Review code, calculations, filters, and sources

Different reviews answer different questions:

• Code review examines queries, joins, parameters, error handling, and performance for faults such as row multiplication or unsafe conversion.
• Calculation review confirms formula, grain, numerator, denominator, exclusions, nulls, and aggregation using a known manual sample.
• Peer review gives an independent analyst the requirements, logic, and evidence so assumptions can be challenged.
• Filter review tests default, empty, single-value, multiple-value, boundary-date, and conflicting selections, including authorized user roles.
• Source validation compares counts, control totals, timestamps, and sample records with the authoritative system before downstream transformations.

Test both expected and excluded records. Retain evidence with the report version for regression after schema or calculation changes.

Handle schema changes and monitor what matters

A schema change can rename a column, alter a type or allowed values, add nesting, or change business meaning without changing the name. Loose parsing may finish while converting values to null, which is worse than a clear failure.

Use source contracts and schema checks. Map changes intentionally, update lineage and definitions, test dependencies, and use change control. Renamed keys, types, and semantics require coordinated updates.

Monitoring should detect failure before a consumer does. Useful alerts cover:

• Freshness beyond an agreed threshold.
• Unexpected row-count or file-size changes.
• New, missing, or type-changed fields.
• Null, duplicate, range, or category-frequency anomalies.
• Query, pipeline, and dashboard duration above limits.
• Failed schedules, dependencies, credentials, and delivery jobs.

Alerts need an owner, threshold, severity, runbook, and escalation. Constant alerts are ignored, while wide thresholds miss incidents. “Job succeeded” is insufficient when it produced zero rows.

Worked scenario: repair a slow, incomplete inventory dashboard

After a supplier update, an inventory dashboard takes 45 seconds to open and shows zero stock for the eastern region. The analyst records the failing version, refresh time, region filter, and expected control total. Other regions appear, so the issue is not a complete outage.

The source contains eastern records, but the landing table shows a row-count drop and changed location identifiers. Logs reveal a renamed key and padded codes. A fallback join casts every value, causing a full scan, while an inner join discards unmatched eastern codes.

The analyst and a peer review mapping and grain, normalize keys during ingestion, explicitly map the renamed field, quarantine unknown codes, and restore the relationship. A pre-aggregated table supports dashboard grain while authorized detail remains elsewhere.

Verification reconciles control totals, tests each region and an unknown code, checks nulls and duplicates, and measures load time. Alerts watch schema, unmatched keys, row count, freshness, and duration. The repair fixes the contract and performance cause rather than hiding a region or extending a timeout.

Common exam traps

• Treating a slow report and a stale report as the same problem.
• Adding hardware or a longer timeout before locating the slow layer.
• Clearing every filter without preserving the failing state.
• Assuming a successful pipeline status means the output is complete and correct.
• Fixing corrupt values in the visual instead of validating the source and transformation.
• Comparing only grand totals when duplicated and missing rows can cancel each other out.
• Accepting a schema change because the pipeline did not crash.
• Checking only that expected records appear and not that forbidden records remain excluded.
• Creating alerts without an owner, action, meaningful threshold, or data-quality check.

Readiness checklist

• I can distinguish load-time, refresh-rate, data-size, filter, stale-data, and corruption symptoms.
• I can capture a reproducible failing state before making changes.
• I can trace timestamps and control totals from the source through the report.
• I can test filter values, types, relationships, scope, boundaries, and user roles.
• I can explain the distinct purposes of code, calculation, peer, filter, and source review.
• I can validate formulas at the correct grain with a known sample and reconciled totals.
• I can identify technical and semantic schema changes and test their dependencies.
• I can select actionable monitoring for freshness, volume, schema, quality, failure, and duration.
• I verify a repair with correctness tests, performance measures, regression cases, and monitoring.