Free DP-700 practice test

Deployment pipeline rules (D) allow administrators to define stage-specific overrides for data source connections and parameters, so when an item is deployed to a new stage, the correct connection is applied automatically. Creating separate dataflows per stage (B) defeats the purpose of deployment pipelines and introduces maintenance overhead. Fabric does not currently offer a first-class 'environment variable' concept for dataflows that is natively referenced as described in option C. Hard-coding the production connection (A) is a security and configuration anti-pattern and does not solve the automatic override requirement.

Option F is correct: the 'Promoted' endorsement is a self-service option that can be applied by workspace contributors (or above) to signal that an item is ready for broader use. Option C is correct: endorsement labels (Promoted, Certified) are surfaced across the Fabric portal and OneLake data hub to help consumers discover and trust content. Option E is partially incorrect in phrasing: Certification requires either a Fabric/Power BI admin OR a user granted the ability to certify via tenant settings — it is not automatically tied to a 'Certification delegated permission' role in the way described. Option B is incorrect: endorsement labels are metadata badges and do not automatically change security permissions or grant additional access. Option D is incorrect: 'Promoted' and 'Certified' are mutually exclusive endorsement levels; an item holds one endorsement state at a time. Option A is incorrect: endorsement can be applied to a wide range of Fabric items including Lakehouses, Notebooks, Dataflows, and more, not just semantic models and reports.

Deployment rules in Fabric deployment pipelines allow administrators to configure stage-specific overrides—such as substituting different data source connection references or parameter values—so that when content is promoted between stages, these values are updated automatically for the target environment. Git branch policies manage code merging rules in a repository and do not affect deployment pipeline configurations. Workspace sensitivity labels are a data governance feature. Item endorsement marks items as Promoted or Certified for discoverability, but does not configure environment-specific connection overrides.

Deployment pipeline rules must be configured on the target stage item. If the rule was accidentally configured on the Test stage item instead of the Production stage item, it will not execute during a Test-to-Production promotion. Rules apply when an item is deployed INTO the stage where the rule is defined. Rules do apply across all stage transitions (A is incorrect). Both Lakehouse and dataset connections can be parameterized with rules (C is incorrect). Using 'Deploy all' does not bypass pipeline rules (D is incorrect); rules apply regardless of whether you deploy all items or selected items.

Enabling 'Secure Input' and 'Secure Output' on Fabric Data Pipeline activities is the correct mechanism to prevent sensitive parameter values from being logged in activity run inputs and outputs, which are visible in monitoring views. Azure Key Vault integration is a best practice for storing secrets but does not by itself control what appears in activity run logs within Fabric. The expression-based replacement approach would alter the value being used, potentially breaking the activity that needs the real value. SecureString as a pipeline parameter type is not a native Fabric Data Pipeline parameter type in the same way as Azure Data Factory; even if it were, it doesn't automatically redact values from all log surfaces without enabling Secure Input/Output.

Microsoft Fabric exposes OneLake through an ADLS Gen2-compatible API, but this functionality must be enabled via the 'OneLake ADLS Gen2 compatible API' tenant setting in the Fabric Admin portal. Once enabled, tools like Azure Storage Explorer and services that speak the ADLS Gen2 API can connect to OneLake directly. Option A (OneLake data access roles) controls what data users can read but does not enable the ADLS Gen2 API compatibility itself. Option C (private endpoint) is related to network security but does not control whether the ADLS Gen2 API is exposed. Option D relates to workspace-level networking for Fabric items, not the ADLS Gen2 API compatibility for OneLake.

Fabric domains allow administrators to group workspaces together and apply domain-level governance settings, including default sensitivity labels and OneLake policies that are inherited by all workspaces assigned to that domain. Workspace roles (C) control user access within a single workspace but do not propagate policies across workspaces. Deployment pipelines (A) manage lifecycle promotion of items between environments but do not govern data access policies. Tenant-level admin settings (B) apply broadly to the entire tenant but lack the granular grouping and inheritance model that domains provide for subsets of workspaces.

Watermarking in Spark Structured Streaming tells the engine the maximum expected lateness of data. Setting a 15-minute watermark means the engine retains state for each window for 15 minutes beyond the window's end time, allowing late events to be included in the correct window, after which old state is safely dropped. Option C (reducing shuffle partitions) affects parallelism but has no bearing on late-data handling or state management. Option B (trigger(once=True)) processes available data in a batch-like fashion but does not handle lateness logic — late records would simply be missed if they arrive after the trigger fires. Option D (Delta merge-on-read) is a storage-level concept unrelated to streaming late-data handling. Option E (checkpoint + failOnDataLoss=false) only prevents stream failure when source offsets are missing; it does not implement any late-data buffering.

Writing invalid records to a quarantine (or 'reject') Delta table satisfies both requirements: the bad records are preserved for investigation without being propagated to the Gold layer. This is the standard pattern for handling missing required keys in medallion architectures. Option A is wrong because dropping records and only logging a count permanently discards data needed for investigation, violating the preservation requirement. Option C is wrong because loading records with a sentinel key into the Gold layer violates the business rule that these records must not reach that layer, and it pollutes the fact data for downstream consumers. Option D is wrong because halting the entire pipeline on any NULL would block valid records from loading and is operationally impractical for a 3% error rate; isolation and quarantine is preferred over a full stop.

Option B is correct because dynamic schema inference with conditional logic based on file metadata requires programmatic control that PySpark handles naturally through schema inference APIs and conditional branching; Dataflow Gen2's Power Query engine has limited support for fully dynamic schema handling across varying file structures. Option A is correct because PySpark's Delta Lake API supports OPTIMIZE with Z-order (ZORDER BY) as a post-write operation directly in the notebook, which is not natively available as a Dataflow Gen2 output option. Option C is wrong because simple column renaming and type casting is a scenario that strongly favors Dataflow Gen2, since its Power Query interface allows non-developer team members to make changes without code. Option D is wrong because Dataflow Gen2 activities can be orchestrated within Fabric Data Pipelines without custom code, making this a point in favor of Dataflow Gen2, not against it. Option E is wrong because small file sizes and a team with strong Power Query skills but limited Python experience clearly favors Dataflow Gen2, not a PySpark notebook.

Option D is correct because dropDuplicates(['OrderId', 'LineItemId']) deduplicates the DataFrame based specifically on the business key columns, keeping one representative row per unique (OrderId, LineItemId) combination even if non-key columns differ slightly between duplicate copies — which is the right behavior for upstream retry-caused duplicates. Option A is incorrect because distinct() removes only rows where ALL columns are identical; if retry-caused duplicates have any minor difference in a non-key column (e.g., slightly different timestamps), they will not be removed, leaving duplicates in the output. Option B is incorrect because df.filter() with a NOT IN subquery addresses deduplication against the target table (idempotency for reloads), not deduplication within the staging batch itself; it also does not handle intra-batch duplicates and is inefficient at scale. Option C is incorrect because dropna removes rows with null key values, which addresses a data quality issue (missing keys) but has no effect on duplicate rows that both have valid, non-null key values.

The correct approach uses where Timestamp > ago(24h) to filter by the event timestamp (not ingestion time), then summarize avg(Temperature) by DeviceId, bin(Timestamp, 10m) to produce per-device, 10-minute tumbling window averages. bin() is the KQL function that creates fixed-size time buckets, equivalent to tumbling windows. Option A uses ingestion_time() instead of the actual event Timestamp column, which would produce incorrect windows if there is any ingestion lag. Option C omits the bin() function, so it produces a single aggregate per device over 24 hours rather than 10-minute windows; the order by also has no effect after a summarize that removed the Timestamp column. Option D introduces an unnecessary self-join that would create a Cartesian product and produce incorrect results.

Option C is correct. A OneLake shortcut creates a logical pointer to the ADLS Gen2 location, making the data queryable inside Fabric without physically copying it — perfectly matching the no-duplication and separate-ownership requirements. Option A is wrong because OneLake mirroring continuously replicates data into OneLake storage, which does duplicate the data and removes the catalog team's sole ownership of the authoritative copy. Option B is wrong because a Dataflow Gen2 copy duplicates the data and adds a weekly ETL dependency rather than providing a live, non-duplicated reference. Option D is wrong because a Copy activity physically moves data into the Lakehouse, violating the no-duplication requirement.

OPTIMIZE is the Delta Lake command that compacts many small files into larger, optimally sized files (typically targeting ~1 GB each), directly addressing the small-file problem and improving query performance. — Option A (VACUUM) removes old, unreferenced data files based on a retention period; it does not compact files and running it with RETAIN 0 HOURS is dangerous as it can break time travel. Option C (ALTER TABLE … COMPACT FILES) is not a valid Delta Lake or Fabric SQL syntax. Option D (REORG TABLE … APPLY PURGE) is a SQL Server/Azure Synapse Dedicated Pool command that purges deleted rows in columnstore indexes; it does not apply to Delta tables in a Lakehouse.

OPTIMIZE orders consolidates small Parquet files into larger, optimally-sized files, directly addressing the small-file problem that causes slow reads. VACUUM orders RETAIN 168 HOURS removes Delta log files and old data files older than 168 hours (7 days), reclaiming storage while respecting the default safety threshold. ALTER TABLE orders COMPACT FILES is not a valid Delta Lake or Fabric Lakehouse command. VACUUM orders RETAIN 0 HOURS would bypass the default 7-day retention safety check; while technically possible with a flag override, it is not the safe recommended approach and does not match the 7-day requirement stated. REBUILD INDEX ON orders is a T-SQL construct for Fabric Warehouse columnstore indexes, not applicable to Lakehouse Delta tables.

Creating a materialized view that pre-aggregates hourly readings is the best balance of cost and performance for range queries. It dramatically reduces the data volume that must be scanned for 90-day range queries without requiring 90 days of raw data in expensive hot (SSD) cache. — Option B would work but setting the hot cache to 90 days significantly increases storage cost because hot cache in Eventhouse is premium SSD-backed storage; the question specifically asks to avoid significantly increasing cost. Option C (adding Eventstream partitions) affects ingestion throughput, not query performance on already-ingested historical data. Option D is wrong because V-Order is a Delta Lake/Parquet optimization for Lakehouse/Warehouse scenarios; it does not apply to KQL/Kusto tables in an Eventhouse.

Running OPTIMIZE … ZORDER BY again (B) consolidates the 300 new small files and re-applies Z-ordering so the multi-dimensional clustering is restored for the new data, fixing slow queries. Running VACUUM … RETAIN 168 HOURS (C) removes old Parquet files that are no longer referenced by any Delta log version and are older than 7 days (168 hours), which resolves the issue of too many old file versions accumulating and causing time-travel query confusion (note: the default retention is 7 days; using 168 hours meets the default minimum). — Option E (setting log retention duration) only affects how long the Delta transaction log is kept, not the physical data files; it does not remove old files. Option A (ANALYZE TABLE) updates statistics used by some engines but does not compact files or remove old versions. Option F (TRUNCATE TABLE) deletes all data and is destructive. Option D (DESCRIBE HISTORY) only displays the history; it does not modify any files.

VACUUM removes Parquet files no longer referenced by the Delta log, and the default safe retention is 168 hours (7 days) to ensure that any long-running Spark jobs still referencing old snapshots do not encounter missing files. Option B is incorrect because RETAIN 0 HOURS deletes all files not in the current snapshot immediately and can break concurrent readers or time-travel queries—it is explicitly unsafe in production. Option A is incorrect because OPTIMIZE with ZORDER compacts and reorders files for query performance but does not remove orphaned old files; it is a separate concern from VACUUM. Option C is incorrect because altering logRetentionDuration controls how long the Delta transaction log itself is retained, not the underlying data files that VACUUM cleans up.

A materialized view in Eventhouse (KQL) pre-computes and stores aggregated or filtered results, meaning queries that target the view scan only the materialized result set rather than the entire 3-billion-row base table. This directly reduces scan cost without altering the base table schema. Row-level security restricts which rows a user can see but does not reduce the underlying scan cost for the query engine. Enabling streaming ingestion affects ingestion latency, not the scan behavior of historical data already in the table. Increasing instance count adds compute but does not reduce the volume of data scanned — the query still reads all 3 billion rows.

Eventstream KQL database destinations default to buffered (batched) ingestion, which optimizes for throughput by accumulating events before writing — this introduces the 10–20 minute latency observed. Switching to direct ingestion mode sends events to the KQL database with near-real-time latency, which is appropriate for real-time dashboard scenarios. Increasing partition count improves horizontal throughput scaling but does not address the buffering delay that is inherent to the destination's ingestion mode setting. Adding a filter reduces volume but does not change the ingestion latency mode — buffering delays would remain. The KQL hot cache policy controls how much data is kept in memory for fast queries; it affects query performance, not ingestion latency.