Home labs & practical projects

Apply a repeatable server configuration with Ansible

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

Local lab Suggested time: 2–3 hoursYour own authorised environment

What you could create

Two test servers should have the same service configuration. Manual changes have caused drift, and operations wants a repeatable automation approach.

Example evidence format

Project evidence map (example)

Ansible role and inventory exampleScope and inputs

Idempotency and drift-repair resultsDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Ansible role and inventory example	Show the inputs, scope and decisions behind this record. Repeated execution is idempotent for the intended tasks.
Idempotency and drift-repair results	Include the evidence supporting your conclusion. A configuration change triggers the required service action only when needed.

What you'll need

Local lab

Use a control machine and two disposable Linux targets. Define an inventory, a test service and a desired configuration without embedding credentials.

Project record

Keep the working files for ansible role and inventory example 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

Uses your own computer. Confirm hardware capacity, software licences and download terms before setup.

Use disposable VMs, containers or a simulator. Keep the lab separate from your everyday machine and work network.

Suggested milestones

1
Plan and investigate
Write a playbook or role with variables, templates and handlers.
2
Develop your approach
Run it twice and inspect whether the second run makes unnecessary changes.
3
Verify and explain
Introduce controlled drift on one target and restore the intended state.

Evidence worth keeping

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

1
Ansible role and inventory example
Show the inputs, scope and decisions behind this record. Repeated execution is idempotent for the intended tasks.
2
Idempotency and drift-repair results
Include the evidence supporting your conclusion. A configuration change triggers the required service action only when needed.

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 ansible role and inventory example 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.

Red Hat Learning Subscription (all courses + labs)

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

Use a control machine and two disposable Linux targets. Define an inventory, a test service and a desired configuration without embedding credentials.

What a good result looks like

Repeated execution is idempotent for the intended tasks.
A configuration change triggers the required service action only when needed.

Finish the project

Save sanitised evidence, then remove the lab instances or revert to the clean snapshot. Remove temporary accounts and credentials.

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.