Diagnostics — DWB11-052–068
DWB11-052 — D
Why D: lineage traces origin/movement relationships; impact analysis asks which components would be affected by a proposed change.
A/B/C: substitute performance/visualization or falsely equate the concepts.
Source: p. 382. · Confusion: impact analysis vs lineage.
DWB11-053 — A
Why A: production integration tooling must support operational controls such as audit, restart/recovery, scheduling/orchestration and monitoring—not only transformation.
B/C/D: dashboard, glossary and cube design are different tool families.
Source: p. 382. · Confusion: integration operations vs BI/Metadata modeling.
DWB11-054 — B
Why B: operational reporting supports operational/tactical activity, sometimes directly from transactions and sometimes enriched by ODS/DW.
A: long-range executive scorecards are strategic/BPM.
C: OLAP is interactive multidimensional analysis.
D: data mining is a separate advanced analytical technique.
Source: pp. 383–384. · Confusion: operational reporting vs strategic/OLAP/mining.
DWB11-055 — C
Why C: BPM integrates processes/applications for measuring and managing performance against strategy, including budgeting/planning.
A: CDC is change capture.
B: staging is data preparation.
D: mapping is integration Metadata.
Source: p. 384. · Confusion: BPM vs data engineering.
DWB11-056 — D
Why D: user-created dashboards/ad hoc work inside governed access/shared-content/support guardrails are self-service BI.
A: unmanaged analytics lacks those controls.
B: ODS is a data store.
C: transaction-log CDC is ingestion.
Source: pp. 386–387. · Confusion: self-service vs unmanaged analytics.
DWB11-057 — A
Why A: queryable audit data lets users/support verify arrival, condition and processing at useful grain, improving troubleshooting and trust.
B: audit does not replace production data.
C: it complements rather than removes lineage.
D: its purpose is broader than license audits.
Source: p. 387. · Confusion: queryable audit vs lineage replacement/licensing.
DWB11-058 — B
Why B: a representative-data prototype tests architecture/requirements and exposes DQ/integration problems before large commitment.
A: tool-first skips discovery.
C: final build first increases risk.
D: a charter does not test technical/data reality.
Source: p. 386. · Confusion: prototype vs big-bang/tool-first.
DWB11-059 — C
Why C: readiness includes business support, architecture, source/ingestion capability, resources/tools and security/sensitivity constraints.
A: perfect sources are unrealistic.
B: sponsorship cannot disappear after funding.
D: incremental delivery is encouraged when aligned to architecture.
Source: pp. 387–388. · Confusion: readiness vs unrealistic prerequisites.
DWB11-060 — D
Why D: a release roadmap connects long-term target architecture with dated/prioritized incremental capabilities.
A: one-time cutover does not manage continuing evolution.
B: source ERD is modeling input.
C: license inventory does not sequence business capability.
Source: p. 388. · Confusion: roadmap vs one-time plan/technical inventory.
DWB11-061 — A
Why A: configuration management protects controlled versions/transport of models, code, semantic layers and environment configuration across releases.
B/C/D: each reduces configuration management to one narrow unrelated item.
Source: p. 388. · Confusion: configuration management vs access/report/data content.
DWB11-062 — B
Why B: committed business SMEs are a critical success/readiness condition; lack of commitment can justify stopping until resolved.
A: DW/BI is not an IT-only project.
C: profiling cannot replace semantic/business decisions.
D: source definitions alone do not supply enterprise requirements.
Source: p. 389. · Confusion: business commitment vs IT-only delivery.
DWB11-063 — C
Why C: governance should identify/mitigate risk and define/monitor controls while remaining business-driven.
A: per-query approval is arbitrary micromanagement.
B: governance does not replace operations.
D: sandbox experimentation can exist under proportional controls.
Source: pp. 389–390. · Confusion: governance vs execution blockage.
DWB11-064 — D
Why D: acceptance requires understandable definitions, verifiable DQ, demonstrable lineage and business UAT/source comparisons.
A/B: infrastructure/load counts alone do not prove trust.
C: presentation styling is not acceptance evidence.
Source: pp. 390–391. · Confusion: business acceptance vs technical/output-only signoff.
DWB11-065 — A
Why A: SLA formalizes business/technical service expectations such as response, availability, freshness/load windows or retention appropriate to the environment.
B/C/D: model, training and CDC terminology are not the service commitment itself.
Source: p. 391. · Confusion: SLA vs model/training/CDC.
DWB11-066 — B
Why B: reporting strategy governs access, user/tool fit, report type/frequency/distribution/storage, visualization, support and timeliness/performance trade-offs.
A: vendor list is only tool inventory.
C: dimensional model is one data design artifact.
D: response target is one metric/SLA component.
Source: pp. 391–392. · Confusion: reporting strategy vs tool inventory/technical artifact.
DWB11-067 — C
Why C: connected/concurrent users and query activity are observed use, stronger adoption evidence than licenses.
A: storage measures capacity.
B: source-table count measures technical scope.
D: report colors have no adoption meaning.
Source: p. 392. · Confusion: usage metrics vs entitlement/capacity.
DWB11-068 — D
Why D: balanced effectiveness evidence includes actual usage, subject coverage, load support, query/refresh performance and satisfaction.
A: registration alone is entitlement.
B: terabytes measure capacity.
C: dashboard count measures output volume, not adoption/trust/service.
Source: pp. 392–393. · Confusion: output counts vs balanced DW/BI metrics.