Drag and Drop Question You have an Azure subscription that contains an Azure SQL database named SQLDb1. SQLDb1 contains a table named Table1. You plan to deploy an Azure web app named webapp1 that wil

Question

Exhibits

Answer Area

Explanation

Azure SQL Change Tracking - Exam Explanation

This question tests your knowledge of SQL Change Tracking (not Change Data Capture). The key constraint is minimize compute and storage, which rules out CDC (Change Data Capture) - CDC stores full row data in system tables, consuming more storage. Change Tracking only stores the fact that a row changed (and its key), making it leaner.

Why CDC items are wrong

• EXEC sys.sp_cdc_enable_db and EXEC sys.sp_cdc_enable_table are CDC commands - they enable Change Data Capture, which stores full before/after row images. This violates "minimize storage."

Correct Sequence Explained

Step 1: ALTER DATABASE SQLDb1 SET CHANGE_TRACKING = ON

You must enable Change Tracking at the database level first. This is a prerequisite - nothing else works without it. You'd also normally follow this with ALTER TABLE Table1 ENABLE CHANGE_TRACKING, but that's not listed as a choice, so Step 1 is the database-level enable.

Step 2: From webapp1, obtain the initial dataset and run CHANGE_TRACKING_CURRENT_VERSION()

Before you can track what changed, you need a baseline snapshot and a version anchor. CHANGE_TRACKING_CURRENT_VERSION() returns the current tracking version number. webapp1 captures all current rows plus this version number and stores it. This is the "sync point" - future queries will ask "what changed since this version?"

Step 3: Run CHANGETABLE()

On subsequent runs, webapp1 calls CHANGETABLE(CHANGES Table1, @last_sync_version) to retrieve only the rows that changed since the last captured version. This is the ongoing change detection step - it's meaningless without Step 2 having established the baseline version.

Common Mistakes

The core mental model: enable -> baseline -> delta queries.

No community discussion yet for this question.