This post is a part of the DP-700: Implementing Data Engineering Solutions Using Microsoft Fabric Exam Prep Hub.
This topic falls under these sections:
Monitor and optimize an analytics solution (30–35%)
   --> Optimize performance
      --> Optimize a pipeline

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available from the hub's main page below the exam topics section.

Overview

Microsoft Fabric Data Factory pipelines provide orchestration capabilities for moving, transforming, and processing data across Fabric workloads. As data volumes grow and business requirements become more demanding, pipeline performance becomes increasingly important.

Optimizing a pipeline involves reducing execution time, minimizing resource consumption, improving reliability, lowering costs, and ensuring data is delivered within required service-level agreements (SLAs).

For the DP-700 exam, you should understand:

• Pipeline performance bottlenecks
• Activity optimization techniques
• Parallelism and concurrency
• Efficient data movement strategies
• Monitoring and troubleshooting pipeline performance
• Dependency management
• Incremental processing patterns
• Best practices for orchestration design

Why Pipeline Optimization Matters

Poorly optimized pipelines can cause:

• Long execution times
• Delayed reporting
• Increased compute consumption
• Pipeline failures
• Capacity bottlenecks
• Resource contention
• Missed business deadlines

A well-designed pipeline should:

• Complete as quickly as practical
• Scale with increasing data volumes
• Minimize unnecessary processing
• Be easy to monitor and troubleshoot
• Recover gracefully from failures

Common Pipeline Performance Bottlenecks

Excessive Sequential Execution

One of the most common issues is placing activities in a strictly sequential order when they could execute simultaneously.

Inefficient Design

Copy Sales
   ↓
Copy Customers
   ↓
Copy Products
   ↓
Copy Inventory

Each activity waits for the previous one.

Optimized Design

        Copy Sales
       /
Start
       \
        Copy Customers

        Copy Products

        Copy Inventory

Independent activities run in parallel.

Benefits:

• Faster completion times
• Better resource utilization
• Reduced orchestration overhead

Unnecessary Data Movement

Moving large volumes of data multiple times increases execution time.

Example

Poor design:

Source
   ↓
Lakehouse A
   ↓
Lakehouse B
   ↓
Warehouse

Better design:

Source
   ↓
Warehouse

Or use:

• OneLake shortcuts
• Direct access patterns
• Shared storage layers

Processing Full Data Sets Repeatedly

Many pipelines reload all historical data during every execution.

This becomes increasingly inefficient as data grows.

Better Approach

Use incremental processing:

Load only:
ModifiedDate > LastSuccessfulRun

Benefits:

• Smaller data movement
• Faster execution
• Lower resource consumption

Use Parallel Processing

Parallel Activity Execution

Fabric pipelines allow multiple activities to run simultaneously when no dependency exists.

Example

Instead of:

Copy Region1
Copy Region2
Copy Region3
Copy Region4

Run:

Copy Region1
Copy Region2
Copy Region3
Copy Region4

in parallel.

Benefits:

• Significant reduction in overall runtime
• Better throughput

ForEach Parallelism

The ForEach activity can process multiple items simultaneously.

Sequential

File1
File2
File3
File4

One at a time.

Parallel

File1
File2
File3
File4

Processed concurrently.

For large file ingestion scenarios, parallel execution often produces substantial performance gains.

However, excessive parallelism can create:

• Capacity contention
• Source-system throttling
• Network bottlenecks

Balance throughput with available resources.

Optimize Copy Activities

Copy activities are often the most time-consuming component of a pipeline.

Minimize Data Volume

Only copy necessary data.

Avoid:

SELECT *

Prefer:

SELECT
    CustomerID,
    OrderDate,
    Amount

Benefits:

• Reduced network transfer
• Faster execution
• Lower memory usage

Filter at the Source

Push filtering to the source system whenever possible.

Good:

SELECT *
FROM Sales
WHERE OrderDate >= '2026-01-01'

Avoid loading all rows and filtering later.

Use Partitioned Reads

Large datasets can often be read in parallel using partitions.

Example partition key:

• Date
• Customer ID
• Region

Benefits:

• Increased throughput
• Better scalability

Implement Incremental Loads

Full Load

Every execution reloads:

10 million rows

every day.

This wastes resources.

Incremental Load

Only process changed records:

25,000 changed rows

Benefits:

• Faster execution
• Reduced storage consumption
• Lower compute usage

Common Incremental Techniques

Watermark Columns

ModifiedDate
LastUpdated
CreatedDate

Pipeline stores last processed value.

Next run loads only newer records.

Change Data Capture (CDC)

CDC captures:

• Inserts
• Updates
• Deletes

Benefits:

• Near real-time synchronization
• Minimal data movement

Optimize Dataflow and Notebook Execution

Pipelines frequently orchestrate:

• Dataflow Gen2
• Spark notebooks
• SQL scripts

Avoid Unnecessary Notebook Runs

Do not execute notebooks if no new data exists.

Use:

• Metadata checks
• File existence checks
• Conditional logic

Example:

If new files exist
    Run notebook
Else
    Skip notebook

Break Large Transformations into Logical Stages

Instead of:

One notebook
5000 lines

Consider:

Notebook A: Ingest
Notebook B: Clean
Notebook C: Transform

Benefits:

• Easier troubleshooting
• Better maintainability
• More targeted reruns

Use Conditional Logic Efficiently

Pipelines support:

• If Condition
• Switch
• Until
• ForEach

Complex branching can increase execution overhead.

Keep orchestration logic:

• Simple
• Readable
• Maintainable

Avoid deeply nested structures when possible.

Manage Activity Dependencies

Unnecessary Dependencies

Poor design:

Task B depends on Task A

even though no relationship exists.

This creates idle time.

Correct Dependency Design

Only create dependencies when required.

Example:

Copy Sales
Copy Products
Copy Customers

run independently.

Build Semantic Model

runs after all copies complete.

Monitor Pipeline Performance

Optimization requires measurement.

Fabric provides monitoring capabilities that help identify bottlenecks.

Monitor:

• Activity duration
• Pipeline duration
• Failed activities
• Retry counts
• Throughput
• Execution history

Questions to ask:

• Which activity takes longest?
• Which activity fails most often?
• Is runtime increasing over time?
• Is data volume growing?

Use Retry Policies Wisely

Retries improve reliability.

Example:

Retry count: 3
Retry interval: 30 seconds

Useful for:

• Temporary network failures
• Source throttling
• Transient service interruptions

However, excessive retries can:

• Extend execution times
• Mask underlying problems

Use reasonable retry settings.

Capacity-Aware Optimization

Pipeline performance depends on Fabric capacity.

Symptoms of capacity pressure:

• Slow notebook startup
• Long-running activities
• Queued workloads
• Inconsistent execution times

Optimization strategies:

• Schedule workloads appropriately
• Reduce unnecessary parallelism
• Upgrade capacity when justified
• Distribute workloads across execution windows

Optimize Scheduling

Avoid scheduling many heavy pipelines simultaneously.

Poor scheduling:

8:00 AM
Pipeline A
Pipeline B
Pipeline C
Pipeline D

Potential result:

• Resource contention

Better scheduling:

8:00 AM Pipeline A
8:15 AM Pipeline B
8:30 AM Pipeline C
8:45 AM Pipeline D

Benefits:

• More predictable execution
• Reduced capacity pressure

Use Metadata-Driven Pipelines

Rather than creating many similar pipelines:

Pipeline A
Pipeline B
Pipeline C
Pipeline D

Create:

One generic pipeline

driven by metadata.

Benefits:

• Easier maintenance
• Consistent performance tuning
• Reduced development effort

Best Practices for DP-700

Use Parallel Execution

Run independent activities concurrently.

Implement Incremental Loads

Avoid processing unchanged data.

Filter Early

Push filtering to source systems.

Reduce Data Movement

Move data only when necessary.

Monitor Activity Duration

Identify bottlenecks using pipeline monitoring.

Avoid Over-Parallelization

Too much concurrency can hurt performance.

Use Conditional Execution

Skip unnecessary processing.

Design Efficient Dependencies

Only create dependencies that are truly required.

Leverage Partitioning

Improve large-scale data ingestion performance.

Continuously Review Pipeline Performance

As data grows, optimization opportunities change.

DP-700 Exam Tips

For exam questions:

• Parallel execution usually improves performance when activities are independent.
• Incremental loads are preferred over repeated full loads.
• Filtering data at the source is more efficient than filtering after ingestion.
• Monitoring activity duration is a primary method for finding bottlenecks.
• Excessive dependencies can unnecessarily increase runtime.
• Metadata-driven pipelines improve scalability and maintainability.
• Retry policies help with transient failures but should not hide recurring issues.
• Capacity limitations can affect pipeline performance even when the pipeline design is correct.

Practice Exam Questions

Question 1

A pipeline loads four unrelated source systems every night. Each copy activity is currently configured to run after the previous activity completes.

What should you do first to reduce overall execution time?

A. Increase retry count
B. Create a new workspace
C. Run the copy activities in parallel
D. Use a larger semantic model

Correct Answer: C

Explanation:
Because the activities are independent, parallel execution can significantly reduce total runtime. Retry counts, workspace creation, and semantic model changes do not address pipeline execution duration.

Question 2

A pipeline reloads 50 million rows every day, even though only 100,000 records change daily.

Which optimization provides the greatest benefit?

A. Increase notebook timeout settings
B. Use incremental loading
C. Enable additional alerts
D. Add more pipeline activities

Correct Answer: B

Explanation:
Incremental loading dramatically reduces the volume of processed data. The other options do not address the root cause of excessive processing.

Question 3

You need to identify the primary bottleneck in a pipeline.

What should you review first?

A. Workspace name
B. Capacity SKU description
C. Activity execution duration in monitoring views
D. Semantic model relationships

Correct Answer: C

Explanation:
Activity duration metrics help identify which step consumes the most time and is therefore the likely bottleneck.

Question 4

A Copy activity transfers all columns from a source table, but only three columns are needed downstream.

What should you do?

A. Select only required columns
B. Create additional pipelines
C. Add retries
D. Increase parallelism

Correct Answer: A

Explanation:
Reducing transferred data decreases network traffic, processing overhead, and execution time.

Question 5

A pipeline contains multiple activities that depend on one another even though no actual data dependency exists.

What is the likely result?

A. Improved throughput
B. Reduced storage usage
C. Longer execution times
D. Improved fault tolerance

Correct Answer: C

Explanation:
Unnecessary dependencies force sequential execution and create avoidable delays.

Question 6

A pipeline runs a notebook every hour even when no new files arrive.

Which approach is most efficient?

A. Add additional notebooks
B. Execute the notebook twice for validation
C. Increase Spark pool size
D. Use conditional logic to run the notebook only when new data exists

Correct Answer: D

Explanation:
Conditional execution prevents unnecessary compute consumption and reduces overall workload.

Question 7

Which technique is most effective for improving large-scale data ingestion performance?

A. Partitioned reads and parallel processing
B. Increasing semantic model size
C. Adding dashboard alerts
D. Running more validation reports

Correct Answer: A

Explanation:
Partitioning and parallel reads improve throughput and scalability for large datasets.

Question 8

A pipeline occasionally fails because of temporary network interruptions.

What is the best solution?

A. Disable monitoring
B. Configure an appropriate retry policy
C. Convert all activities to notebooks
D. Reduce logging

Correct Answer: B

Explanation:
Retry policies are specifically designed to handle transient failures such as temporary network issues.

Question 9

Several large pipelines start at exactly the same time and frequently experience inconsistent performance.

What is the most likely optimization?

A. Add more dependencies
B. Replace pipelines with reports
C. Stagger pipeline schedules to reduce resource contention
D. Increase alert frequency

Correct Answer: C

Explanation:
Spreading workloads across time reduces competition for Fabric resources and often improves performance consistency.

Question 10

Which design pattern improves maintainability while reducing the need to manage many nearly identical pipelines?

A. Full refresh processing
B. Metadata-driven pipelines
C. Sequential execution chains
D. Duplicate pipeline copies

Correct Answer: B

Explanation:
Metadata-driven pipelines use configuration tables or parameters to process multiple datasets with a single reusable design, improving scalability and maintainability.

Go to the DP-700 Exam Prep Hub main page.

This post is a part of the DP-700: Implementing Data Engineering Solutions Using Microsoft Fabric Exam Prep Hub.
This topic falls under these sections:
Monitor and optimize an analytics solution (30–35%)
   --> Identify and resolve errors
      --> Identify and resolve pipeline errors

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available from the hub's main page below the exam topics section.

Overview

Microsoft Fabric pipelines are orchestration tools that automate data movement, transformation, and processing activities. Pipelines commonly include Copy Data activities, Notebook activities, Dataflow Gen2 activities, Stored Procedure activities, and control flow components such as loops and conditional branches.

In enterprise environments, pipelines are critical components of data engineering solutions. When pipelines fail, data ingestion, transformation, reporting, and downstream analytics processes may be disrupted. For this reason, DP-700 candidates must understand how to identify, troubleshoot, and resolve pipeline errors efficiently.

This article covers the concepts, tools, and best practices required to diagnose and resolve pipeline failures in Microsoft Fabric.

Understanding Pipeline Execution

A pipeline consists of one or more activities executed according to defined dependencies.

During execution, each activity can have one of several statuses:

• Succeeded
• Failed
• In Progress
• Skipped
• Cancelled

When a failure occurs, Fabric records detailed execution information, including:

• Error messages
• Error codes
• Activity duration
• Input and output parameters
• Dependency information
• Retry attempts
• Execution timestamps

This information is available through pipeline monitoring interfaces.

Common Causes of Pipeline Failures

Pipeline errors generally fall into several categories.

1. Connection Errors

These occur when Fabric cannot connect to a source or destination system.

Examples include:

• Invalid credentials
• Expired passwords
• Missing permissions
• Network connectivity issues
• Incorrect server names
• Incorrect database names

Example:

A Copy Data activity attempts to connect to an Azure SQL Database using outdated credentials.

Result:

The activity fails before data transfer begins.

2. Authentication and Authorization Errors

Authentication verifies identity.

Authorization verifies permissions.

Common examples:

• User lacks workspace access.
• Service principal permissions are missing.
• Lakehouse permissions are insufficient.
• SQL account lacks SELECT privileges.

Example error:

“Access denied.”

Resolution:

Verify workspace roles, item permissions, and source-system permissions.

3. Data Mapping Errors

Data mapping errors occur when source and destination schemas do not align.

Examples:

• Source column missing
• Data type mismatch
• Renamed source fields
• Invalid destination structure

Example:

A string value is loaded into an integer column.

Result:

The activity fails during data validation.

4. Schema Drift Issues

Schema drift occurs when source structures change unexpectedly.

Examples:

• New columns added
• Existing columns removed
• Data types changed

Example:

An upstream application adds a new column.

A pipeline using fixed mappings may fail when the schema changes.

Mitigation strategies include:

• Dynamic mapping
• Schema validation
• Metadata-driven pipelines

5. Notebook Failures

Notebook activities can fail because of:

• Python syntax errors
• Spark runtime failures
• Missing packages
• Memory limitations
• Invalid SQL statements
• Data quality issues

Example:

A PySpark notebook references a non-existent table.

Result:

The notebook activity returns a failure status to the pipeline.

6. Dataflow Gen2 Failures

Common causes include:

• Invalid transformations
• Source connection failures
• Refresh timeouts
• Missing columns
• Data conversion problems

Monitoring Dataflow Gen2 execution logs helps identify root causes.

7. Timeout Errors

Long-running operations may exceed configured limits.

Examples:

• Large data copies
• Complex Spark transformations
• Slow source systems

Symptoms:

• Pipeline execution terminates before completion.
• Activity reports timeout-related errors.

Solutions:

• Optimize queries
• Partition data
• Increase timeout settings where supported

8. Capacity and Resource Constraints

Fabric workloads consume compute resources.

Problems may occur when:

• Capacity is overloaded.
• Spark resources are exhausted.
• Concurrent jobs exceed available resources.

Typical symptoms:

• Slow performance
• Queued workloads
• Unexpected failures

Resolution often requires capacity monitoring and workload optimization.

Monitoring Pipeline Executions

Monitoring is the first step in troubleshooting.

Fabric provides monitoring capabilities through:

Pipeline Run History

Pipeline monitoring displays:

• Run status
• Start and end times
• Duration
• Activity-level results
• Error messages

Engineers should begin troubleshooting by reviewing the failed run details.

Activity-Level Monitoring

A pipeline may contain dozens of activities.

Activity monitoring allows you to identify:

• Which activity failed
• When it failed
• Error details
• Execution dependencies

This narrows the troubleshooting scope significantly.

Execution Output Logs

Many activities provide detailed output logs.

Examples:

• Rows copied
• Rows skipped
• Error records
• Source and destination statistics

These outputs often reveal the exact cause of failure.

Using Error Messages Effectively

A common mistake is focusing only on the pipeline status rather than the detailed error message.

Example:

Generic error:

“Copy activity failed.”

Detailed message:

“Column CustomerID cannot be converted from string to integer.”

The detailed message immediately points to a data type issue.

Always investigate:

• Error code
• Error description
• Activity output
• Stack trace (if available)

Retry and Recovery Strategies

Automatic Retries

Many transient failures can be resolved automatically.

Examples:

• Temporary network interruptions
• Brief source-system outages
• Short-term service throttling

Pipeline activities can be configured with retry policies.

Typical settings include:

• Retry count
• Retry interval

Idempotent Design

An idempotent process can be executed repeatedly without causing duplicate results.

Example:

A MERGE operation updates existing records and inserts new ones.

If the pipeline is rerun after failure:

• No duplicate records are created.
• Results remain consistent.

Idempotent design greatly simplifies recovery.

Checkpointing

Checkpointing records processing progress.

Benefits:

• Resume processing from the last successful step.
• Avoid reprocessing large datasets.

This is especially important in large-scale ingestion pipelines.

Troubleshooting Common Pipeline Scenarios

Scenario 1: Copy Activity Failure

Symptoms:

• Copy activity fails.
• No rows transferred.

Investigation:

1. Verify source connectivity.
2. Verify destination connectivity.
3. Check credentials.
4. Review activity logs.

Common resolution:

Correct connection information or permissions.

Scenario 2: Notebook Activity Failure

Symptoms:

• Notebook activity reports failure.
• Spark job terminates.

Investigation:

1. Open notebook execution logs.
2. Review failed cell.
3. Check exception details.
4. Verify table references.

Common resolution:

Fix notebook code or data dependencies.

Scenario 3: Schema Change Failure

Symptoms:

• Previously successful pipeline suddenly fails.

Investigation:

1. Compare source schema.
2. Review mapping definitions.
3. Validate destination schema.

Common resolution:

Update mappings or implement schema-drift handling.

Scenario 4: Timeout During Data Load

Symptoms:

• Activity runs for a long period.
• Eventually fails with timeout.

Investigation:

1. Review query performance.
2. Analyze data volume.
3. Examine source-system performance.

Common resolution:

Optimize source queries and partition processing.

Implementing Error Handling Patterns

Try-Catch Pattern

Fabric pipelines support conditional execution paths.

A failure path can:

• Log errors
• Send notifications
• Trigger recovery actions

Example:

If a notebook fails:

• Send an alert.
• Execute a cleanup activity.
• Record error details.

Logging Pattern

Capture important metadata:

• Pipeline name
• Activity name
• Execution time
• Error message
• Run ID

Centralized logging simplifies troubleshooting.

Notification Pattern

Notify administrators when failures occur.

Methods may include:

• Email notifications
• Teams notifications
• External monitoring integrations

This reduces response time.

Best Practices for Resolving Pipeline Errors

Design for Observability

Include:

• Logging
• Monitoring
• Alerts
• Error handling

Well-observed pipelines are easier to troubleshoot.

Use Meaningful Activity Names

Instead of:

• Copy1
• Notebook1

Use:

• LoadCustomerData
• TransformSalesData

This simplifies failure analysis.

Validate Data Early

Perform:

• Schema validation
• Data quality checks
• Null-value validation

before expensive transformations occur.

Implement Retry Policies

Configure retries for transient failures.

Avoid excessive retries for permanent errors such as schema mismatches.

Build Idempotent Pipelines

Ensure rerunning a failed pipeline does not corrupt data.

This is a critical enterprise data engineering principle.

Monitor Pipeline Health Regularly

Review:

• Failure rates
• Execution durations
• Throughput trends
• Capacity utilization

Proactive monitoring often prevents larger incidents.

DP-700 Exam Tips

For the exam, remember:

• Pipeline monitoring begins with reviewing run history and activity outputs.
• Retry policies help mitigate transient failures.
• Schema drift is a common cause of ingestion failures.
• Notebook activity failures often require reviewing Spark execution logs.
• Activity-level monitoring is critical for isolating root causes.
• Idempotent designs simplify recovery after failures.
• Logging, alerts, and notifications are key operational practices.
• Capacity constraints can indirectly cause pipeline failures.
• Error messages and activity outputs provide the most useful troubleshooting information.
• Understanding how to diagnose failures is as important as building the pipeline itself.

Practice Exam Questions

Question 1

A Fabric pipeline fails during a Copy Data activity. The activity output indicates that a destination column expects an integer, but the source contains text values.

What is the most likely cause?

A. Authentication failure

B. Data mapping error

C. Capacity overload

D. Pipeline timeout

Correct Answer: B

Explanation:

The source and destination data types do not match, causing a mapping failure.

• A is incorrect because authentication succeeded.
• C is incorrect because resource availability is unrelated to data type validation.
• D is incorrect because the error occurred during validation rather than timing out.

Question 2

A data engineer wants a pipeline activity to automatically retry after temporary network interruptions.

Which feature should be configured?

A. Schema drift handling

B. Dynamic content

C. Pipeline parameters

D. Retry policy

Correct Answer: D

Explanation:

Retry policies automatically rerun activities after transient failures.

• A addresses schema changes.
• B is used for dynamic expressions.
• D passes values into activities but does not provide retry behavior.

Question 3

A pipeline that has run successfully for months suddenly begins failing after a source application deployment.

What should be investigated first?

A. Schema changes in the source system

B. Capacity metrics

C. Spark pool size

D. Workspace permissions

Correct Answer: A

Explanation:

Unexpected schema changes are a common cause of sudden pipeline failures.

• B, C, and D may contribute to failures but are less likely immediately after an application deployment.

Question 4

Which monitoring feature helps identify exactly which activity within a pipeline failed?

A. Capacity Metrics App

B. Workspace settings

C. Semantic model refresh history

D. Activity-level monitoring

Correct Answer: D

Explanation:

Activity-level monitoring provides detailed execution results for individual pipeline activities.

• A monitors capacity.
• B manages workspace configuration.
• C relates to semantic models rather than pipelines.

Question 5

A notebook activity fails because a referenced table does not exist.

Which troubleshooting step should be performed first?

A. Increase capacity

B. Review notebook execution logs

C. Modify retry settings

D. Rebuild the pipeline

Correct Answer: B

Explanation:

Notebook logs identify the exact failing statement and exception.

• A and C do not address missing tables.
• D is unnecessary before investigating the root cause.

Question 6

Which design approach helps ensure that rerunning a failed pipeline does not create duplicate records?

A. Retry policy

B. Activity dependencies

C. Idempotent processing

D. Event triggering

Correct Answer: C

Explanation:

Idempotent processes produce the same result regardless of how many times they are executed.

• A handles transient failures.
• B controls execution order.
• D determines when a pipeline starts.

Question 7

A pipeline activity reports a generic failure message. Which information is typically most valuable for identifying the root cause?

A. Workspace description

B. Activity error details and output logs

C. Pipeline author name

D. Dataset refresh schedule

Correct Answer: B

Explanation:

Detailed activity outputs often contain specific error codes and diagnostic information.

• A, C, and D generally provide little troubleshooting value.

Question 8

A pipeline consistently fails after running for several hours because processing exceeds allowed execution limits.

What type of issue is this?

A. Authentication issue

B. Schema drift issue

C. Mapping issue

D. Timeout issue

Correct Answer: D

Explanation:

Activities that exceed execution limits typically generate timeout failures.

• A, B, and C describe different failure categories.

Question 9

Which error-handling pattern is most appropriate for sending notifications when a pipeline activity fails?

A. Failure branch with notification activity

B. Data partitioning

C. Schema evolution

D. Incremental loading

Correct Answer: A

Explanation:

A failure path can execute notification activities when errors occur.

• B, C, and D are unrelated to operational alerting.

Question 10

A data engineer wants to minimize troubleshooting time when pipeline failures occur.

Which practice provides the greatest benefit?

A. Use generic activity names

B. Disable activity logging

C. Use meaningful activity names and centralized logging

D. Increase refresh frequency

Correct Answer: C

Explanation:

Descriptive activity names and centralized logging significantly improve observability and accelerate root-cause analysis.

• A makes troubleshooting harder.
• B removes valuable diagnostic information.
• D does not help identify failures.

Go to the DP-700 Exam Prep Hub main page.