Home labs & practical projects

Validate a Fabric ingestion pipeline before refresh

A project to do with your own tools, with guidance on what to create and capture.

Vendor environment Suggested time: 2–3 hoursYour own authorised environment

What you could create

A reporting dataset receives a source file with a renamed column and duplicate rows. The data team must prevent an apparently successful refresh from publishing bad data.

Example evidence format

Project evidence map (example)

Pipeline design and data contractScope and inputs

Refresh validation and recovery resultsDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Pipeline design and data contract	Show the inputs, scope and decisions behind this record. The schema change is surfaced rather than silently dropping a field.
Refresh validation and recovery results	Include the evidence supporting your conclusion. A failed batch has a clear recovery path without duplicate published rows.

What you'll need

Vendor environment

Use a suitable Fabric training workspace and synthetic CSV files. Prepare a normal file, a schema-change file and a duplicate batch; verify capacity and trial conditions.

Project record

Keep the working files for pipeline design and data contract and record assumptions as you go.

Current reference material

Use the linked provider resources to verify the features, access terms and version relevant to your project.

Access & cost

Access may require a licence, trial or training subscription. Confirm availability and permitted use before committing; no free tenant is assumed.

Use an authorised training tenant with test identities and synthetic data. If access is unavailable, document the plan and label it untested.

Suggested milestones

1
Plan and investigate
Define the ingestion contract and destination table expectations.
2
Develop your approach
Add schema and row-quality checks before publishing the transformed data.
3
Verify and explain
Run the three inputs and document failures, recovery and rerun behaviour.

Evidence worth keeping

Keep clear, organised evidence of your design and any testing you carry out.

1
Pipeline design and data contract
Show the inputs, scope and decisions behind this record. The schema change is surfaced rather than silently dropping a field.
2
Refresh validation and recovery results
Include the evidence supporting your conclusion. A failed batch has a clear recovery path without duplicate published rows.

Label design proposals and observed results clearly.

Explain your work

Use these prompts to reflect on your decisions and what you learned.

Which part of your pipeline design and data contract needed the most judgement?
What observation or assumption changed your approach?
What would you improve, and what have you not verified?

Describe this as a personal project in your portfolio.

Useful resources

Use these resources to deepen your understanding and check key details.

Official certification objectives

Review the current provider requirements and relevant subject areas.

Explore external learning resources

Find relevant providers and check features, access requirements and costs.

A useful starting point

Use a suitable Fabric training workspace and synthetic CSV files. Prepare a normal file, a schema-change file and a duplicate batch; verify capacity and trial conditions.

What a good result looks like

The schema change is surfaced rather than silently dropping a field.
A failed batch has a clear recovery path without duplicate published rows.

Finish the project

Remove test identities, policies and data, restore the initial configuration, and check trial expiry or renewal settings.

Independent home-project guidance, not an official vendor lab or a claim of complete exam coverage. Use your own tools and label the work accurately.