Home labs & practical projects

Stop a faulty release before it reaches everyone

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

Cloud sandbox Suggested time: 3–4 hoursYour own authorised environment

What you could create

A service release passes unit checks but raises errors under real traffic. The delivery system needs a measured promotion decision and a reliable rollback.

Example evidence format

Project evidence map (example)

Pipeline definition and release timelineScope and inputs

Rollback results and monitoring evidenceDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Pipeline definition and release timeline	Show the inputs, scope and decisions behind this record. The unhealthy version cannot be promoted after the gate fails.
Rollback results and monitoring evidence	Include the evidence supporting your conclusion. Rollback restores the known working version and passes the health request.

What you'll need

Cloud sandbox

Prepare a minimal test service, a delivery pipeline and a previous working version. Define a synthetic health request and an intentionally unhealthy release.

Project record

Keep the working files for pipeline definition and release timeline 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

A cloud account may incur charges. Check current service prices and quotas before creating resources; a budget alert is not a spending cap.

Use a separate learning account or subscription and synthetic data. Keep credentials and administrative endpoints private.

Suggested milestones

1
Plan and investigate
Add build validation, a staged deployment and an approval or health gate.
2
Develop your approach
Connect deployment health to an observable threshold over a stated window.
3
Verify and explain
Trigger the bad release, exercise rollback and preserve the release audit trail.

Evidence worth keeping

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

1
Pipeline definition and release timeline
Show the inputs, scope and decisions behind this record. The unhealthy version cannot be promoted after the gate fails.
2
Rollback results and monitoring evidence
Include the evidence supporting your conclusion. Rollback restores the known working version and passes the health request.

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 definition and release timeline 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

Prepare a minimal test service, a delivery pipeline and a previous working version. Define a synthetic health request and an intentionally unhealthy release.

What a good result looks like

The unhealthy version cannot be promoted after the gate fails.
Rollback restores the known working version and passes the health request.
The record identifies which commit was deployed and why it was reverted.

Finish the project

Remove the exercise resources, including retained storage, snapshots and public IPs. Check the billing view for anything still running.

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.