Home labs & practical projects

Diagnose a private endpoint name-resolution failure

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

Design project Suggested time: 90–120 minutesNo hardware required for the design

What you could create

A private service is reachable from one Azure network but not from a connected office. The teams disagree about whether the fault is routing or DNS.

Example evidence format

Project evidence map (example)

Resolver and route-path diagramScope and inputs

Fault diagnosis with expected test outputsDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Resolver and route-path diagram	Show the inputs, scope and decisions behind this record. The explanation identifies which resolver supplies each answer.
Fault diagnosis with expected test outputs	Include the evidence supporting your conclusion. A correct DNS answer is not treated as proof of network reachability.

What you'll need

Document, spreadsheet or diagram tool

Create a network diagram with an office resolver, a hub, a spoke and a private endpoint. Write sample successful and failing DNS answers and route observations.

Project record

Keep the working files for resolver and route-path diagram 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

No paid platform is needed for the written version. Use a document, spreadsheet or diagram tool you already have.

The organisation and records are fictional. Write down assumptions; do not substitute confidential employer information.

Suggested milestones

1
Plan and investigate
Trace name resolution and packet flow as separate paths.
2
Develop your approach
Locate the missing forwarding or zone-link assumption.
3
Verify and explain
Write tests from both locations, including an expected denied public path.

Evidence worth keeping

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

1
Resolver and route-path diagram
Show the inputs, scope and decisions behind this record. The explanation identifies which resolver supplies each answer.
2
Fault diagnosis with expected test outputs
Include the evidence supporting your conclusion. A correct DNS answer is not treated as proof of network reachability.

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 resolver and route-path diagram 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.

Microsoft Official Practice Assessment (AZ-700)

Check relevance, platform versions and current access terms.

Explore external learning resources

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

A useful starting point

Create a network diagram with an office resolver, a hub, a spoke and a private endpoint. Write sample successful and failing DNS answers and route observations.

What a good result looks like

The explanation identifies which resolver supplies each answer.
A correct DNS answer is not treated as proof of network reachability.
The validation plan checks access boundaries as well as successful connectivity.

Finish the project

Keep the decision record and note unanswered questions. A written design is not evidence that a technical control has been tested.

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.