Home labs & practical projects

Investigate a noisy alarm without hiding the fault

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

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

What you could create

A small service repeatedly alerts during a scheduled job. Operations needs to distinguish expected load from a real loss of service.

Example evidence format

Project evidence map (example)

Before-and-after alarm rationaleScope and inputs

Incident timeline with service validationDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Before-and-after alarm rationale	Show the inputs, scope and decisions behind this record. Normal scheduled activity has a documented explanation.
Incident timeline with service validation	Include the evidence supporting your conclusion. The changed alarm still detects the genuine failure.

What you'll need

Cloud sandbox

Create a disposable workload with logs and metrics. Use a controlled load change and a synthetic availability check; choose low-cost resources and record their limits.

Project record

Keep the working files for before-and-after alarm rationale 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
Build a timeline linking the job, resource pressure and user-visible health.
2
Develop your approach
Tune the alarm evaluation window using the observed behaviour.
3
Verify and explain
Introduce a genuine service failure and document escalation, recovery and cleanup.

Evidence worth keeping

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

1
Before-and-after alarm rationale
Show the inputs, scope and decisions behind this record. Normal scheduled activity has a documented explanation.
2
Incident timeline with service validation
Include the evidence supporting your conclusion. The changed alarm still detects the genuine failure.

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 before-and-after alarm rationale 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

Create a disposable workload with logs and metrics. Use a controlled load change and a synthetic availability check; choose low-cost resources and record their limits.

What a good result looks like

Normal scheduled activity has a documented explanation.
The changed alarm still detects the genuine failure.
Recovery is verified independently of the alarm returning to normal.

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.