DP-700 sample questions — 25 answered and explained

Fabric domains support delegated administration: tenant admins create domains and can appoint domain admins (and domain contributors) so business areas govern themselves.

Appointing domain admins gives Finance exactly the scoped authority requested: manage the Finance domain's settings and which workspaces it contains, while leaving tenant settings untouched. The Fabric administrator role is tenant-wide overreach. Domain contributors are the near-twin, but they can only attach workspaces they administer and cannot change domain settings. Per-workspace Admin roles operate below the domain layer.

1. Distinguish the scopes: Fabric admin, domain admin, domain contributor, workspace admin.
2. Match the requirement: manage the domain's workspaces AND its settings, nothing tenant-wide.
3. Rule out domain contributors: they assign only their own workspaces and can't change domain settings.
4. Add the Finance leads as domain admins of the Finance domain.

Exam tip: Domain admin = manage the domain's settings and workspaces; domain contributor = attach your own workspaces only.

A default domain applies to specified users or security groups: workspaces they administer that have no domain are assigned to it, workspaces they create afterwards join it, and workspaces already assigned elsewhere keep their domain.

Two behaviours decide it: the default domain picks up new and unassigned workspaces of the specified admins, and it never overrides an existing assignment. So the Sales workspaces stay in Sales. Domains don't restrict what users can see, and a default-domain list grants contributor-style assignment, not domain admin rights.

1. Recall what the default domain targets: workspaces whose admin is a specified user or group member.
2. Apply it to unassigned workspaces and to workspaces created later.
3. Check how existing assignments are treated: they are preserved.
4. Reject options that change visibility or grant domain admin rights.

Exam tip: A default domain catches new and unassigned workspaces of the listed admins and leaves existing assignments alone.

An Apache Airflow job is Fabric's managed Apache Airflow: a workspace item that runs Python DAGs on a Fabric-managed runtime, so teams keep their DAG code without managing Airflow infrastructure.

The constraints are 'keep the DAGs largely unchanged' and 'no infrastructure to patch'. Only the Apache Airflow job runs existing DAG code as is on a managed runtime. Pipelines and notebooks would mean rewriting each DAG, and running a scheduler from a Spark job definition is still self-managed.

1. List the constraints: existing Python DAGs, minimal change, no VMs to maintain.
2. Recall Fabric's managed Airflow item: the Apache Airflow job.
3. Reject options that require rewriting the DAGs.
4. Reject options that keep the team running Airflow infrastructure itself.

Exam tip: Existing Airflow DAGs + no infrastructure = a Fabric Apache Airflow job.

An Apache Airflow job has its own runtime. Extra Python packages are declared under Settings > Environment configuration > Apache Airflow requirements; Spark environments and notebook installs don't reach it.

The DAG is parsed and run by the Airflow runtime, so the package must be installed there, via the job's Apache Airflow requirements. The tempting answer reuses the Fabric environment that serves notebooks, but environments apply to Spark sessions only. Notebook %pip installs and Spark pools are also Spark-side.

1. Locate where the failing code runs: the Airflow runtime, not Spark.
2. Recall how that runtime gets extra packages: the job's Apache Airflow requirements.
3. Reject Spark-side mechanisms: environments, %pip in notebooks, Spark pools.
4. Save the requirement so the runtime installs it.

Exam tip: Airflow DAG packages go in the Airflow job's requirements; Fabric environments are for Spark only.

The Spark runtime version is selected per workspace in the workspace Spark settings: through the workspace default environment, or directly from the runtime list when no default environment is set. Individual items can override it by attaching another environment.

The scope is one workspace: all its items, but no other workspace. The workspace default environment sets the runtime at exactly that scope. Capacity settings would be too broad and don't hold a runtime; pools in Fabric don't carry a runtime; %%configure can't change it.

1. Identify the scope: every item in one workspace, not the capacity.
2. Recall where Fabric sets the runtime: environments and workspace Spark settings.
3. Choose the workspace default environment so items inherit it.
4. Reject capacity-wide, pool-level and per-cell options.

Exam tip: One runtime for a whole workspace = set it in the workspace default environment.

A Fabric custom Spark pool defines compute only: node family, node size, autoscale minimum/maximum nodes and dynamic executor allocation. Libraries and runtime are in environments; session timeout is a workspace Jobs setting.

Node family/size and autoscale bounds are the pool's own properties. The distractors are real settings that sit elsewhere: libraries and runtime in environments, session timeout in the workspace Jobs settings. Candidates coming from Synapse often expect libraries and the Spark version on the pool.

1. Recall the custom pool form: name, node family, node size, autoscale, dynamic allocation.
2. Place each distractor in its real home: environment or Jobs tab.
3. Select the two compute properties.

Exam tip: Pools = nodes and scaling; environments = libraries and runtime; Jobs tab = session timeout.

Domains provide business-area grouping for discovery (catalog filtering) and federated governance (delegated tenant settings per domain). They do not change access, compute or workspace roles.

Assignment tags items with a domain so consumers can filter by it, and domain admins can override the tenant settings that have been delegated, such as certification. The distractors are the common overreach: domains as an access boundary, a compute boundary or a replacement for workspace roles.

1. Recall the two purposes of domains: discovery and federated governance.
2. Match catalog filtering to discovery, and delegated certification to governance.
3. Reject claims about access, compute or roles, which domains don't change.

Exam tip: Domains organize and delegate governance; they don't grant or block access.

Notebooks share a high concurrency session only when they are run by the same user and have the same default lakehouse, Spark compute configuration and library packages. Inline installs in cells don't block sharing.

The documented conditions are a single user, matching default lakehouse, matching compute configuration and matching library packages. The inline %pip distractor is the subtle one: Fabric explicitly allows different inline installations in a shared session. Folders and pipelines play no part.

1. Recall the user boundary of high concurrency sessions.
2. Recall that the configuration must match: default lakehouse, compute settings, library packages.
3. Note the exception: inline installs in cells are allowed.
4. Reject folder and pipeline conditions.

Exam tip: Shared session = same user + same default lakehouse, compute and libraries; inline %pip is fine.

Airflow jobs run on a workspace Airflow runtime pool. The starter pool (default) is a Large node that starts instantly and shuts down after 20 minutes of inactivity. A custom pool is always on until paused, with Small/Large nodes, autoscale and extra nodes for more concurrent workers.

The starter pool's idle shutdown and the custom pool's always-on behaviour with extra nodes are the documented properties. The distractors swap them (idle shutdown on a custom pool, node-size choice on the starter pool) or misstate what extra nodes add.

1. Recall the starter pool: default, fixed Large node, idle shutdown after 20 minutes.
2. Recall the custom pool: always on until paused, configurable size, autoscale, extra nodes.
3. Check each statement for a swapped property.
4. Select the two that match.

Exam tip: Airflow starter pool = idles off after 20 minutes (dev); custom pool = always on with extra nodes (production).

The grain of a fact table is a precise statement of what one row represents. It must be declared before load logic, because every measure and dimension key has to be consistent with it.

Choosing the lowest useful grain, one order line, supports both kinds of report: monthly totals are aggregations of order lines. Storing only summaries loses detail, mixing grains causes double counting, and partitioning is a physical decision that does not define the rows.

1. List the most detailed question the reports must answer: revenue per order line.
2. Declare the grain at that level: one row per order line.
3. Derive coarser views such as monthly totals by aggregation, not by mixing rows of different grain.

Exam tip: Declare the grain first, at the most detailed level the reports need, and never mix grains in one fact table.

A surrogate key is a key generated by the warehouse or lakehouse that identifies one dimension row. It is required when business keys from several sources collide and when one business key must map to several historical rows.

Two facts in the scenario force the design: customer 1001 exists in both CRMs, and history requires several rows per customer. Neither can be handled with the CRM IDs as the row key. Compression is a side benefit, privacy is not what surrogate keys are for, and Fabric Warehouse does let you declare a non-enforced primary key on a business key.

1. Check for collisions: two sources share ID values, so the source ID is not unique.
2. Check for history: several rows per customer are needed, so the source ID repeats.
3. Generate a surrogate key per dimension row and keep the source IDs as attributes.

Exam tip: Overlapping sources or SCD Type 2 history = generated surrogate keys; keep business keys as attributes.

SCD Type 1 handles attribute changes by overwriting the value in the existing dimension row. No history is kept, which makes it the standard treatment for error corrections and for attributes where only the current value matters.

The choice between SCD types is a business question about whether the previous value matters. Here it does not: the old phone number is simply wrong, and every period should show the fix. Overwriting in place corrects past and future reports at once. Type 2 would preserve the error as history, Type 3 keeps it in a previous-value column, and Type 0 never applies the correction at all.

1. Ask the business whether the prior value has analytical meaning; for an error correction, it does not.
2. Rule out Type 0, which never applies changes, and Types 2 and 3, which keep the old value.
3. Apply an UPDATE to the existing dimension row, setting the corrected phone number.
4. Leave the row's surrogate key untouched so all existing fact references remain valid.

Exam tip: SCD Type 1 overwrites in place with no history: the right choice for corrections and analytically insignificant changes.

SCD Type 2 preserves full history by adding a new dimension row, with its own surrogate key and effective dates, every time a tracked attribute changes.

The requirement is "region at the time of sale" for changes that happen repeatedly. Type 2 records every version, and facts store the surrogate key that was current when they were loaded. Type 1 rewrites history, Type 3 keeps only one prior value, and yearly snapshots are too coarse for several changes a year.

1. Spot the trigger phrase: the value on the date of the sale must be reported.
2. Check how often the attribute changes: several times, so one prior-value column is not enough.
3. Choose Type 2 and have the fact load pick up the current surrogate key at load time.

Exam tip: "As it was at the time of the event" = SCD Type 2.

An SCD Type 2 change is applied as expire-then-insert: the current version row is closed (end date set, current flag cleared) and a new version row is inserted with its own surrogate key, start date and current flag.

Both halves are needed. Expiring keeps one current row per business key, which the fact load relies on for surrogate-key lookups. Inserting a row with a new surrogate key creates the new version without changing the old one, so facts recorded during the 'Standard' period still join to the 'Standard' row. Overwriting is Type 1, skipping the expire step leaves two current rows, and reusing the key joins every fact to both versions.

1. Detect the change by comparing the extract with the customer's current row.
2. Update the current row: EffectiveEndDate = load date, IsCurrent = false.
3. Insert the new version with a new surrogate key, EffectiveStartDate = load date and IsCurrent = true.
4. Leave existing facts pointing at the old surrogate key.

Exam tip: SCD Type 2 = expire the current row, then insert a new row with a new surrogate key.

A streaming loading pattern lands immutable events by appending them. Bronze keeps events as received; there is no truncate-and-reload and no merge at the landing edge.

Events never change after they occur, so there is nothing to update. Appending keeps the full history at the lowest write cost and meets the one-minute latency. A per-sensor MERGE and an overwrite both destroy history, and a daily batch fails the latency requirement.

1. Note that the data is immutable events arriving continuously.
2. Note the latency requirement: about one minute.
3. Choose append-only micro-batch writes into bronze.

Exam tip: Streaming into bronze = append-only; no merge or overwrite at the landing edge.

In the medallion architecture, bronze holds raw data as received, silver holds cleansed, deduplicated, validated and conformed data, and gold holds business-level aggregates and dimensional models.

Deduplication, validation and conformance are the silver step. Doing them once there gives every gold table and consumer the same clean base while bronze keeps the raw events for reprocessing. Cleaning in bronze loses the raw record, cleaning in gold or in the semantic model repeats the work per consumer.

1. Recall the job of each layer: raw, refined, business.
2. Match deduplication, validation and conformance to the refined layer.
3. Keep bronze append-only as the raw record.

Exam tip: Bronze = raw as received; silver = cleaned and conformed; gold = business aggregates.

In dimensional loading, fact rows carry surrogate keys obtained by looking up each business key in its dimension, so dimensions must be loaded and current before the facts that reference them.

Tonight's sales include customers that only exist after tonight's dimension load. Only after DimCustomer and the other dimensions are updated do those business keys map to correct surrogate keys. Loading facts first or in parallel causes lookup failures, and Fabric Warehouse does not enforce foreign keys, so integrity is the loading pattern's job. The dimension loads can run in parallel with each other; the fact load waits for all of them.

1. Run the dimension loads (inserts, Type 1 updates, Type 2 versions), in parallel with each other if needed.
2. When every dimension load has completed, start the fact load.
3. Resolve each business key to the current surrogate key during the fact load.
4. Handle any key that still does not resolve with the late-arriving-member policy.

Exam tip: Load dimensions before facts: surrogate-key lookups only resolve against dimensions that are already current.

Pipeline run details list every activity run. A Copy activity's output and details view report data read and written (rows and bytes), throughput, and the duration of each stage, such as queuing and transfer.

The engineer needs read-versus-written counts and stage timings for one Copy activity, and those live in that activity's run details. Delta history is the closest near-twin: it shows rows written by the commit but nothing about the source side. The Monitoring hub and the Capacity Metrics app work at run and capacity level.

1. Open the pipeline run from the Monitoring hub or the pipeline's run history.
2. Find the Copy activity in the activity list.
3. Open its details or output to compare rows read with rows written and check throughput.
4. Use the duration breakdown to see whether the time went to queuing, reading or writing.

Exam tip: For Copy activity read/write counts and throughput, open the Copy activity's details in the pipeline run.

Semantic model refresh history shows one entry per refresh, with its type (how it was started, such as Scheduled, On demand or an API call), start time, duration, status and details. Automatic retry attempts and the Data and Query cache operations appear inside an entry's details.

The extra rows carry the types On demand and Via API, and the type tells you who or what started the refresh: a person using Refresh now and a programmatic caller. The tempting alternative is retries, but the service records retry attempts inside the details of one entry, not as new rows. The same applies to the Query cache operation. Partitions are processed within one refresh.

1. Read the type column. It records how each refresh was started.
2. Map On demand to a manual refresh and Via API to a programmatic caller, such as a pipeline, script or flow.
3. Remember that retries and query cache operations appear inside an entry, not as extra rows.
4. Ask who owns the manual and API refreshes before changing the schedule.

Exam tip: The refresh history type column records how each refresh started. Retries and cache steps sit inside an entry, so extra rows mean extra triggers.

When a notebook runs as a job (from a pipeline or a schedule), Fabric keeps a snapshot of the notebook as executed, with its cell outputs and errors. You open it from the run details.

Two facts rule out the shortcuts. The notebook has changed since the run, so the current code or a rerun is not evidence. Version history restores code but not outputs. Only the run snapshot preserves both the code as executed and its outputs, including the failing cell's exception.

1. Note that the notebook changed after the failed run.
2. Find the failed run from the pipeline activity output or the Monitoring hub.
3. Open the notebook snapshot for that run.
4. Read the error under the failing cell before deciding on a fix.

Exam tip: To see a failed scheduled notebook as it actually ran, open the run snapshot, not the current notebook.

Eventstreams run continuously, so you monitor them in the eventstream editor: data preview for the latest events, data insights for incoming and outgoing event metrics per node, and runtime logs for errors.

The question is about live throughput at the source. That is answered on the eventstream's own nodes through data preview and data insights. The Monitoring hub covers jobs, not continuous streams. The Eventhouse command reports downstream ingestion errors. The Capacity Metrics app measures compute, not event counts.

1. Recognise that an eventstream runs continuously rather than as a job.
2. Open the eventstream and select its source node.
3. Use data preview to confirm events are arriving.
4. Use data insights to read incoming event counts over the last hour.

Exam tip: Monitor eventstreams inside the eventstream: data preview, data insights and runtime logs. They do not appear as runs in the Monitoring hub.

A Dataflow Gen2 refresh runs in phases, and its run details list them as activities: queries are evaluated (optionally into staging), then results are loaded to the output destination. The activity that failed tells you which side to investigate.

Use the phase boundary. The first activity covers the source connection, its credentials, the Power Query steps and the write to staging, and it succeeded. The second activity is the load from staging into the output destination, so only a destination-side cause fits: here, a column type that the existing Warehouse table cannot accept. The other options are all exercised by the activity that succeeded.

1. Open the failed refresh's details and read the activities listed for the query.
2. Recall the phases: evaluation (with the write to staging) first, then the load to the output destination.
3. Rule out every cause that the successful evaluation and staging activity already exercised.
4. Read the failed load activity's error and check the destination table's schema, connection and permissions.

Exam tip: In Dataflow Gen2 run details, the failing activity locates the problem. If staging succeeded and the load failed, look at the destination.

Fabric lets operations burst above the SKU and then smooths their compute usage over future 30-second timepoints: interactive operations over a minimum of 5 minutes (up to 64), and background operations over 24 hours. Throttling stages are based on how much future capacity smoothed usage has consumed: overage protection up to 10 minutes, then interactive delay, interactive rejection beyond 60 minutes, and background rejection beyond 24 hours.

Spark work is background, so its compute is smoothed over the next 24 hours and a short burst barely moves any single timepoint. Throttling is driven by accumulated smoothed usage against future capacity, which is why days of sustained heavy load eventually delayed interactive queries. The tempting distractors each misstate one number: the five-minute window belongs to interactive operations, and overage protection is 10 minutes, not 24 hours.

1. Classify the operation. A Spark job is a background operation.
2. Recall the smoothing window for background operations: 24 hours.
3. Recall that throttling stages follow smoothed usage over future capacity (10 minutes, 60 minutes, 24 hours).
4. Conclude that sustained load, not a single spike, produces interactive delays.

Exam tip: Spikes rarely throttle on their own. Smoothing (24 hours for background work) means sustained load is what fills the throttling windows.

Activator rule definitions combine a condition (state conditions such as Is greater than, or change conditions such as Increases above) with an occurrence setting: Every time the condition is met, When it has been true for n times, or When it has been true for a duration.

The requirement is "continuously for five minutes". Only the duration-based occurrence, When it has been true for 5 minutes, demands an unbroken stretch. A crossing condition (Increases above) still fires on a one-minute blip. A count of five occurrences can be met by scattered spikes. Every time fires on each high minute.

1. Separate what to detect (count above 50) from how persistent it must be (5 continuous minutes).
2. Choose the state condition Is greater than 50.
3. Set occurrence to When it has been true for 5 minutes.
4. Test the rule with Send me a test alert before starting it.

Exam tip: To suppress noise from brief spikes in Activator, use a "When it has been true for" duration, not a count of times or a crossing condition.

The Monitoring hub is Fabric's cross-workspace triage surface for job runs: what ran, when, and with what status, with drill-through into each item's run details. Capacity analysis, editing and continuous-item metrics live elsewhere.

The hub does two things: list runs across item types and workspaces, and drill into a run's item-specific details. Throttling analysis belongs to the Capacity Metrics app. Editing belongs to the item's editor. Eventstream throughput belongs to the eventstream's data insights, because a continuous stream is not a job run.

1. Recall what the hub lists: runs of jobs across workspaces you can access.
2. Recall what it links to: each run's item-specific details.
3. Map capacity, editing and stream metrics to their own surfaces.

Exam tip: The Monitoring hub lists job runs across workspaces and drills into each run's details. It does not analyse capacity, edit items or monitor streams.