Diagnostic Key DS6-015–028
DS6-015 — C · Tight federation
An integrated published federated schema is the deciding clue. Component-built schemas/location knowledge indicate loose coupling; loss of autonomy indicates non-federated; copying updates indicates replication.
Source: p. 173 · Confusion: loose vs tight federation.
DS6-016 — D · DaaS
The provider installs/maintains the database service while the consumer uses/pays for it. A VM leaves DB administration with the owner; managed hosting is related but not the same service framing; federation is unrelated.
Source: pp. 173–174 · Confusion: VM vs DaaS vs managed hosting.
DS6-017 — A · Atomicity
All operations succeed or none do. Consistency = valid state; Isolation = transactions separated; Durability = commit persists.
Source: p. 175 · Confusion: ACID properties.
DS6-018 — B · Basically Available, Soft state, Eventual consistency
The other expansions are invented/mixed terms.
Source: pp. 175–176 · Confusion: ACID vs BASE.
DS6-019 — C · CAP trade-offs
CAP concerns Consistency, Availability, Partition tolerance in distributed systems. ACID covers transaction guarantees; CAP is not backup staging or modeling cardinality.
Source: p. 176 · Confusion: CAP vs ACID / cardinality.
DS6-020 — D · Reject/reconsider technology for POS
A DBMS without required transaction behavior is a bad workload fit. Ownership, license cost, or a one-platform-fits-all assumption do not replace required transaction capability.
Source: p. 189 · Confusion: technology capability vs workload.
DS6-021 — A · In-memory database
Processing occurs in volatile memory for speed, with persistent storage/durability mechanisms around it. Disk, sharding, and key-value organization are different concepts.
Source: p. 177 · Confusion: in-memory vs persistent disk.
DS6-022 — B · Columnar compression
Repeated values within columns compress well and reduce I/O. Cold backup, hierarchy, and abstraction do not answer the storage-layout clue.
Source: p. 177 · Confusion: columnar compression vs row storage.
DS6-023 — C · Flash/SSD
Attractive because it combines low-latency/memory-like speed with persistent storage characteristics. It does not remove backup or guarantee consistency and is not always cheaper.
Source: p. 177 · Confusion: flash vs in-memory vs disk.
DS6-024 — D · SAN
A managed collection of disk arrays where storage-side data movement may occur on the backplane. Federation, schema, and test-environment answers are unrelated.
Source: pp. 176–177 · Confusion: SAN vs database concepts.
DS6-025 — A · Production rule
Production is live/mission-critical, not a development/test area, and database changes require strict control. Urgency, verbal approval, or arbitrary sizing does not change that.
Source: pp. 177–178 · Confusion: Production vs lower environments.
DS6-026 — B · Development
Development is the normal first controlled environment for patches/updates. Production is last; Sandbox is experimental, not the only patch path; recovery site is not normal development.
Source: pp. 178, 204 · Confusion: Development vs Production.
DS6-027 — C · Production-like performance Test
Performance-test results require an environment resembling Production, including resources that affect the test. Synthetic data is not universally required; Test cannot write to Production; deliberate infrastructure mismatch weakens validity.
Source: pp. 178–179, 201 · Confusion: Test vs Development/Sandbox.
DS6-028 — D · Sandbox
Isolated experimentation/POC that may read protected/controlled samples but cannot write back to Production is the Sandbox clue. Live service = Production; formal UAT = Test; disaster restore = recovery.
Source: p. 179 · Confusion: Sandbox vs Test.