Diagnostic Key DS6-001–014
For every miss, record the confusion pair and the deciding clue—not just the topic.
DS6-001 — A · Definition
Correct because Chapter 6 is the design, implementation, and support of stored data across its lifecycle. B is Modeling & Design; C is Governance; D is Integration/Warehousing.
Source: pp. 166–167 · Confusion: Storage & Operations vs adjacent functions.
DS6-002 — B · Business continuity
Continuity is the stated primary driver; monetization, literacy, and Metadata standardization are useful elsewhere but not the source answer.
Source: p. 168 · Confusion: business continuity vs other data goals.
DS6-003 — C · Availability, integrity, transaction performance
These are the three source goals. The other options describe Governance, Modeling, or unrelated governance/Metadata activities.
Source: pp. 167–168 · Confusion: availability vs integrity vs performance.
DS6-004 — D · Best practice with justified exception
Chapter 6 treats standards/best practices as strong requirements but allows acceptable justified deviation rather than letting standards threaten project success. A is too rigid; B abandons standards; C wrongly transfers responsibility.
Source: p. 168 · Confusion: best practice vs rigid compliance.
DS6-005 — A · Instance
The stem says a running execution of DBMS software. Database is the stored collection; schema groups objects; node is a distributed computer.
Source: p. 169 · Confusion: database vs instance vs schema vs node.
DS6-006 — B · Schema
A schema groups database objects and can carry distinct owner/access context. Instance is execution context; node is distributed infrastructure; abstraction is a common access interface.
Source: p. 169 · Confusion: schema vs instance.
DS6-007 — C · Portability with lost product-specific capability
Abstraction/common APIs improve portability but may hide functions not common across products. It does not guarantee ACID, eliminate schemas, or duplicate data.
Source: p. 169 · Confusion: abstraction vs replication.
DS6-008 — D · Controlled, auditable Production change
Approval, tested process/script, auditability, and back-out are required before Production implementation. “Small” does not remove control; documenting afterward is too late; a Sandbox test alone does not authorize Production.
Source: pp. 169–170 · Confusion: controlled change vs emergency shortcut.
DS6-009 — A · Production DBA
Production monitoring, reliability, backup/recovery, failover, and maintenance are the deciding responsibilities. Conceptual modeling, procedural code, and storage arrays point elsewhere.
Source: pp. 170–171 · Confusion: Production DBA vs other administrators.
DS6-010 — B · Application DBA
The defining clue is responsibility for one/more application databases across environments and close application-team membership. Storage arrays point to NSA; production infrastructure alone is too narrow.
Source: p. 171 · Confusion: Application vs Production DBA.
DS6-011 — C · Procedural DBA
Stored procedures, triggers, and UDFs are the procedural-DBA domain. Production and Application DBA have different operational/application scopes; NSA is storage infrastructure.
Source: p. 171 · Confusion: Procedural vs Development DBA.
DS6-012 — D · NSA
NSA focuses on hardware/software supporting storage arrays. The other answers belong to modeling, procedural DB work, or Data Quality.
Source: p. 171 · Confusion: DBA vs NSA.
DS6-013 — A · Centralized access dependency
If the one centralized system is unavailable, there may be no alternate access path. Centralization can still be appropriate for restricted data and does not determine SQL support or require federation.
Source: pp. 171–172 · Confusion: centralized vs distributed.
DS6-014 — B · Federated database
Autonomous sources presented together without duplicating source data is federation. Non-federated components lose autonomy; mirroring creates copies; centralization does not preserve autonomous sources.
Source: pp. 172–173 · Confusion: federated vs non-federated.