Courseiva
Describe core data conceptseasyMultiple ChoiceObjective-mapped

DP-900 Describe core data concepts Practice Question

A financial company needs to store transactional records where each record has a fixed set of attributes (TransactionID, Amount, Date, AccountID). The data must support complex queries and enforce referential integrity. Which type of data store is most appropriate?

⚠ Common exam trap

It's easy for candidates to confuse 'fixed schema' with 'document databases,' assuming JSON documents can enforce structure, but document databases do not enforce schema or referential integrity at the database level, which is a key requirement for transactional records.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Relational database

A relational database (option C) is the most appropriate choice because transactional records with a fixed schema and the need for referential integrity (e.g., ensuring AccountID references a valid account) are best handled by a structured, ACID-compliant system like Azure SQL Database or SQL Server. Relational databases enforce constraints such as foreign keys and support complex queries using JOINs and aggregations, which are essential for financial reporting and auditing.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Key-value store

    Why it's wrong here

    Key-value stores such as Redis or DynamoDB provide extremely fast, O(1) lookups by a single primary key, but they lack secondary indexes, joins, and multi-key transaction support. Financial transactional records often require atomic updates spanning multiple rows and strict integrity constraints, which key-value pairs cannot enforce because each value is treated as an opaque entity. Consequently, complex queries and referential integrity are impossible or must be handled at the application layer, making this choice unsuitable for transactional consistency.

  • Document database

    Why it's wrong here

    Document databases like MongoDB or Azure Cosmos DB store semi-structured JSON documents with no predefined schema, providing flexibility for evolving data models. However, they do not enforce referential integrity through foreign keys, and cross-document ACID transactions are either unsupported or costly to implement. For a financial company, a loss or change of a linked record (e.g., customer and transaction) would not be automatically detected, risking orphaned entries and unreliable audit trails. This loose consistency model contradicts the rigorous atomicity required by transactional record systems.

  • Relational database

    Why this is correct

    Relational databases such as SQL Server or PostgreSQL store transactional records in normalized tables with defined schemas, enforcing referential integrity through primary and foreign keys. They guarantee ACID transactions—atomicity, consistency, isolation, durability—so a financial posting either fully commits or fully rolls back, protecting against partial writes. Additionally, SQL's powerful join and aggregate capabilities enable complex reporting and audit queries, while mature built-in security, logging, and backup features align with regulatory compliance. This combination of structured schema, transactional integrity, and strong querying makes the relational model the gold standard for financial records.

  • Graph database

    Why it's wrong here

    Graph databases like Neo4j excel at traversing highly interconnected relationships, making them ideal for fraud detection or organizational hierarchy analysis where path queries across many hops are core. In contrast, financial transactional records are typically simple, high-volume inserts that do not need relationship traversal, and the graph model's emphasis on relationships over rows can complicate basic CRUD operations. Furthermore, graph databases often provide weaker consistency guarantees or lack full SQL support, which is a liability for auditing and regulated reporting. Therefore, they satisfy a different analytical use case but fail to meet the reliability and query simplicity required for transactional storage.

About these practice questions

One of 820 original DP-900 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DP-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-900 exam.