DP-900 Practice Question: Identify considerations for relational data on Azure

Answer analysis

Option-by-option breakdown

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

• ✗

  Change Data Capture (CDC)

  Why it's wrong here

  Change Data Capture (CDC) reads changes from the transaction log and writes them to an internal change table, but it does not provide a built-in way to reconstruct the historical state of a row as of a specific time. You must give the captured changes to a separate destination—like an audit table or an external system—and build custom logic to join or filter those captured changes if you need a temporal point-in-time view. Unlike temporal tables, CDC doesn't automatically maintain a complete before-and-after row version in the same table, so it's an extra layer of plumbing rather than a turnkey history feature.

• ✓

  Temporal tables

  Why this is correct

  System-versioned temporal tables are a built-in Azure SQL Database feature that automatically stores every historical version of a row in a parallel history table, using two datetime2 period columns (ValidFrom/ValidTo) that the engine maintains on every insert, update, and delete. You can query the current fact table for live data and use T-SQL clauses like FOR SYSTEM_TIME AS OF, BETWEEN, or CONTAINED IN to see the rows exactly as they existed at a given point in time. No custom code, triggers, or jobs are required; the database automatically appends the prior versions and lets you query history directly from the base table.

• ✗

  Automatic tuning

  Why it's wrong here

  Automatic tuning in Azure SQL Database is a performance management feature that continuously monitors workload execution and either suggests or automatically applies index adjustments, index creation, and query plan corrections to improve query speed. It operates entirely on execution plans and storage structures, never taking row-level snapshots or capturing the before-image of a data change. Because it's aimed at optimizing how queries run, it provides no audit trail and cannot answer a question like 'what was the order amount on a past date,' which is exactly the kind of historical data the company needs.

• ✗

  Geo-replication

  Why it's wrong here

  Geo-replication creates one or more readable secondary replicas of an Azure SQL Database in a different Azure region, with data synchronized asynchronously so the secondary can take over or serve read traffic in a disaster or load-balancing scenario. Each secondary is a live copy of the current logical database, not a collection of past states, so it retains no record of historical changes to the customer order data. Even if you enable auto-failover or use the secondary for read-only reporting, you get the most recent data, not the ability to query how a row looked weeks ago.

Go deeper

Related to this question