What Is Ansible?

Build a visual field guide and first Ansible playbook in Visual Studio Code.

Introduction

30 Second Summary

Changing the same setting on several computers sounds simple until one machine gets missed. Repetition makes small differences hard to spot.

In this project, you will build a visual field guide that compares repetitive server work with Ansible automation. You will use it to decode your first YAML playbook before practicing a beginner-friendly interview explanation.

What You'll Build

You will open a rendered field guide that turns a messy three-server job into a clear Ansible story you can explain in 60 seconds.

By the end of this project, you'll have:

A rendered before-and-after diagram that makes the cost of repeating one task across three servers visible.
A first Ansible playbook targeting school_servers. A line-by-line translation explains its play, target, task, module, and message.
A completed knowledge check with a classification exercise. You will also have a 60-second explanation covering the control node, inventory, managed nodes, agentless model, and playbook.
Secret Mission: Adapt the school playbook into library-playbook.yml for the library_servers group with a library IT message.

Are there any prerequisites?

You need Windows 10 with Visual Studio Code already installed. You do not need prior Ansible knowledge, RHEL, or a Red Hat account.

Before We Start

Before the hands-on work begins, take a moment to connect Ansible to a repetitive computer-management task you care about. This gives the concepts ahead a clear purpose.

Set Up Your Ansible Classroom Workspace

Repetitive work becomes easier to follow when every lesson starts from a known place. A small workspace keeps your Ansible notes and examples together.

This step creates that home inside Documents. You will finish with a rendered field-guide heading in Visual Studio Code.

In this step, get ready to:

Create the nested classroom folder inside Documents.
Open the lesson folder as a Visual Studio Code workspace.
Render your first field-guide heading from a saved file.

Create the lesson folder

A fixed folder path gives every academy lesson a predictable home. You will build that path one folder at a time with File Explorer.

Press Windows logo key + E to open File Explorer.
Select Documents in the left sidebar.
Stay in the Documents folder Windows already shows if its address includes OneDrive.
Select New folder on the Home ribbon.
Type ansible-academy as the folder name.
Press Enter to create the folder.
Double-click ansible-academy to open it.

The File Explorer address now ends with Documents\ansible-academy.

Select New folder on the Home ribbon.
Type module-01 as the folder name.
Press Enter to create the folder.
Double-click module-01 to open it.
Select New folder on the Home ribbon.
Type lesson-01 as the folder name.
Press Enter to create the folder.
Double-click lesson-01 to open it.

The location now ends with Documents\ansible-academy\module-01\lesson-01. This confirms that your classroom folder is ready.

Open the workspace and create the field guide

Visual Studio Code treats an opened folder as a workspace. The Explorer then keeps every lesson file tied to lesson-01.

Press the Windows key to open the search bar.
Type Visual Studio Code into the search bar.
Press Enter to open Visual Studio Code.

Opening a folder may trigger a workspace trust prompt.

Click File in the top menu.
Click Open Folder....
Choose lesson-01 inside Documents\ansible-academy\module-01.
Confirm the folder selection.
Approve the trust prompt only if it shows the lesson-01 folder you created.

You should see lesson-01 at the top of the Explorer sidebar. The empty workspace is now open.

Markdown stores the field guide as plain text. The preview turns that source into a readable page.

Select the Explorer view in the left Activity Bar.
Select New File... in the Explorer view.
Enter ansible-lesson-1.md as the file name.
Press Enter to create the file.
Add the opening field-guide heading by entering the exact Markdown below:

# Ansible Academy 1.1 Field Guide

What Does This Markdown Do?

The leading # marks this line as the page's main heading.
The text Ansible Academy 1.1 Field Guide gives the lesson a clear title when rendered.

Save ansible-lesson-1.md by pressing Ctrl+S.
Confirm that ansible-lesson-1.md appears under lesson-01 in the Explorer sidebar.

File Missing from the Explorer?

Check that the Explorer heading shows lesson-01.
Confirm that the file name is exactly ansible-lesson-1.md.

Help me find my Markdown file in Visual Studio Code.

✔️ Awesome, I've got everything!

Your saved file contains the field-guide heading and appears inside lesson-01.

ⓧ I'd like to double check the full code

# Ansible Academy 1.1 Field Guide

How to Compare the File

Your complete file contains this single heading followed by a blank line. Matching it now gives the next lesson content a clean starting point.

Render the field guide heading

The preview reads the saved Markdown source and renders its formatting beside the editor. This gives you a quick feedback loop for every change you make later.

Select the ansible-lesson-1.md editor tab.

Before you open the preview, predict whether the hash symbol stays visible.

Open Markdown Preview to the Side by pressing Ctrl+K V.

You'll see the editor on the left. The preview on the right displays Ansible Academy 1.1 Field Guide as a large heading.

Preview Did Not Open?

Select the ansible-lesson-1.md editor tab.
Press Ctrl+Shift+P to open the Command Palette.
Select Markdown: Open Preview to the Side.

Help me open the Markdown preview beside my editor.

You have your first visible result: the field-guide heading now renders beside its source. Next, you'll make manual repetition visible across three fictional servers.

Visualize Manual Server Work

Your field guide heading already renders in Visual Studio Code. The guide now needs a concrete problem that makes automation useful.

The manual diagram gives one administrator the same job on three servers. Those repeated arrows prepare you to understand the Ansible control model.

In this step, get ready to:

Render the school administrator's repeated work across three servers.
Provide a plain-text fallback for the manual-work diagram.
Explain why repeated instructions create opportunities for mistakes.

Add the manual-work scenario

A Mermaid diagram lets Markdown describe a visual using text. Each arrow makes one repeated action visible.

In the editor pane for ansible-lesson-1.md, place your cursor on the blank line below the existing heading.
Paste this scenario block below the heading:

## The problem: one task, three servers

A school has three servers. The IT administrator wants every server to show the same maintenance notice. Without automation, the administrator signs in to each server and repeats the same work.

Illustration: Manual work repeated across three servers

```mermaid
flowchart LR
  A[One IT administrator]
  A -->|Repeat the same task| S1[School server 1]
  A -->|Repeat the same task| S2[School server 2]
  A -->|Repeat the same task| S3[School server 3]
```

How Does This Diagram Work?

The identifier A represents the administrator who starts each repeated action.
The identifiers S1, S2, and S3 keep the three server targets distinct.
The repeated arrow labels expose how one manual task becomes three separate pieces of work.

Save ansible-lesson-1.md.

Before you check the preview, what pattern do you expect the three arrows to create?

Press Ctrl+K V while ansible-lesson-1.md is active.

You should see one administrator connected to three school servers. Each connection carries the label Repeat the same task.

Seeing Raw Mermaid Text?

Use the Markdown preview pane to check the rendered visual.
Check that the opening diagram fence contains mermaid exactly.
Keep the raw diagram in place if your installed version cannot render it. The fallback in the next section preserves the same flow.

Help me troubleshoot a Mermaid diagram that appears as text in Visual Studio Code.

Complete the manual-work section

The plain-text fallback keeps the one-to-three flow readable across preview versions. The risk statement names the human mistakes that repeated work can create.

Back in the editor pane, place your cursor immediately after the closing mermaid fence.
Paste this fallback block after the diagram:



Plain-text fallback:

```text
One IT administrator -> repeat task -> School server 1
One IT administrator -> repeat task -> School server 2
One IT administrator -> repeat task -> School server 3
```

The risk is simple: the administrator can forget a server, type something differently, or lose track of which machines were changed.

What Does This Block Add?

The fallback preserves the same one-to-three structure for a preview that cannot render Mermaid.
The closing sentence connects repeated work to missed servers and inconsistent changes.

Save ansible-lesson-1.md.

Before you refresh the preview, how many repeated arrows do you expect to see?

Press Ctrl+K V while ansible-lesson-1.md is active.

Under the scenario, you should see one administrator connected to three servers by three Repeat the same task arrows. Below the graphic, you should see the fallback flow plus the risk statement.

Fallback Missing?

Check that Plain-text fallback: sits after the closing Mermaid fence.
Confirm that each fallback line remains inside the text fence.
Compare the three server names with the labels in the diagram.

Help me find why the plain-text fallback is missing from my Markdown preview.

✔️ Awesome, I've got everything!

Your field guide now shows the manual scenario. Make sure ansible-lesson-1.md is saved.

ⓧ I'd like to double check the full code

Compare your file with this complete version.

# Ansible Academy 1.1 Field Guide

## The problem: one task, three servers

A school has three servers. The IT administrator wants every server to show the same maintenance notice. Without automation, the administrator signs in to each server and repeats the same work.

Illustration: Manual work repeated across three servers

```mermaid
flowchart LR
  A[One IT administrator]
  A -->|Repeat the same task| S1[School server 1]
  A -->|Repeat the same task| S2[School server 2]
  A -->|Repeat the same task| S3[School server 3]
```

Plain-text fallback:

```text
One IT administrator -> repeat task -> School server 1
One IT administrator -> repeat task -> School server 2
One IT administrator -> repeat task -> School server 3
```

The risk is simple: the administrator can forget a server, type something differently, or lose track of which machines were changed.

Explain the cost of repetition

The finished visual turns repetition into something you can count. Connecting that pattern to a familiar example makes the risk easier to explain.

Point to School server 1 in the preview.
Point to School server 2 in the preview.
Point to School server 3 in the preview.
Say Repeat the same task once for each arrow.
Count the three arrows in the rendered diagram.

That first comparison is now visible: one administrator repeats one job across three servers. Next, you'll turn this wasteful pattern into a centralized control model.

Map Ansible's Control Model

Your manual diagram now makes the risk of repeated server work visible. The next goal is to replace those three repeated arrows with one control model.

Ansible uses a control node as the central point for automation. An inventory tells that control node which managed nodes belong to a group.

The key question is whether each managed node needs its own Ansible agent. Your finished model makes that answer visible.

In this step, get ready to:

Use a restaurant analogy to map each part of the control model.
Add the Ansible control model beside the manual-work diagram.
Explain the agentless request flow from the control node to three managed nodes.

Translate the restaurant analogy

A familiar system makes each technical role easier to remember. A restaurant manager coordinates several kitchen stations from one place.

Switch back to the ansible-lesson-1.md editor from earlier.
Find the final sentence that begins with The risk is simple:.
Place your cursor after that sentence.
Add the restaurant analogy by pasting this content:

## The restaurant analogy

Imagine a restaurant manager coordinating three kitchen stations.

- The manager gives directions from one place.
- The seating chart lists the tables and their groups.
- The kitchen stations receive work and prepare the result.

In Ansible language, the manager is like the control node, the seating chart is like the inventory, and the kitchen stations are like managed nodes.

How does the analogy map to Ansible?

The manager represents the control node because directions start from one place.
The seating chart represents the inventory because it lists targets in groups.
The kitchen stations represent managed nodes because they receive the work.

Save ansible-lesson-1.md with Ctrl+S.
Return to the Markdown Preview from earlier.
Scroll to The restaurant analogy.

You should see the restaurant heading followed by three bullet points. Good progress. Your guide now has a memory aid for the three main roles.

Can't see the restaurant analogy?

Confirm that you pasted the new section after the manual-work content. Save ansible-lesson-1.md again if the preview still shows the older version.

Ask for help checking why the Markdown Preview is not updating.

Draw the Ansible control model

The new diagram gives every role a labeled box. Its arrows show how one control node reads the inventory before sending automation to the managed nodes.

Return to the ansible-lesson-1.md editor.
Place your cursor after the restaurant analogy.
Add the Ansible diagram plus its fallback by pasting this content:

## The Ansible way

Illustration: Ansible control model

```mermaid
flowchart LR
  C[Control node: Ansible runs here]
  I[Inventory: lists and groups targets]
  G[school_servers group]
  S1[Managed node: server 1]
  S2[Managed node: server 2]
  S3[Managed node: server 3]
  C -->|Reads| I
  I -->|Describes| G
  C -->|Sends automation over SSH| S1
  C -->|Sends automation over SSH| S2
  C -->|Sends automation over SSH| S3
```

Plain-text fallback:

```text
Control node -> reads inventory -> selects school_servers
Control node -> SSH -> managed node 1
Control node -> SSH -> managed node 2
Control node -> SSH -> managed node 3
```

Ansible is installed on the control node. It is not normally installed on managed nodes. This is why the usual design is called agentless.

How does the diagram map the system?

The C box shows where Ansible runs.
The I box lists targets before the school_servers group organizes them.
The S1, S2, and S3 boxes represent the three managed nodes.
The outbound arrows label SSH as the transport used to reach each server.
The missing agent boxes visualize the agentless design.

Save ansible-lesson-1.md with Ctrl+S.

Before you check the preview, which box do you expect to send all three automation arrows?

Return to the Markdown Preview from earlier.
Scroll to The Ansible way.

You should see one control node sending automation over SSH to three managed nodes. You should see no agent boxes on those nodes.

Trace a circle around Control node: Ansible runs here with your cursor.
Trace a line beneath Inventory: lists and groups targets with your cursor.
Confirm aloud that managed nodes do not normally have Ansible installed.

Seeing raw Mermaid text?

Confirm that you are checking the Markdown Preview from earlier. The editor itself always shows the diagram source.

Check that the opening fence says mermaid. The plain-text fallback still shows the intended flow when your installed Visual Studio Code version cannot render the diagram.

Help me check why my Mermaid diagram appears as raw text.

Add the glossary and request flow

A glossary gives each diagram box a precise meaning. The numbered flow shows how a request becomes ordered work.

Protect practice credentials

Practice Markdown files are plain text. A real password stored here could be exposed to anyone who can read the file.

Keep every real password out of these practice files.

A later lesson uses Ansible Vault to protect sensitive data.

Return to the ansible-lesson-1.md editor.
Place your cursor after the agentless explanation.
Add the glossary plus the request flow by pasting this content:

## Small glossary

- Control node: The machine from which Ansible command-line tools run.
- Inventory: A list of managed nodes and groups, plus information Ansible needs to identify them.
- Managed node: A target computer or device that Ansible manages. It is also called a host.
- Transport: The connection method used to reach a managed node. Linux systems commonly use SSH.
- Playbook: A YAML automation blueprint containing one or more plays.
- Play: A connection between a target group and an ordered list of tasks.
- Task: One action Ansible should apply.
- Module: The Ansible code that performs the action named by a task.

## From request to result

1. A person starts automation from the control node.
2. Ansible reads the inventory to learn which managed nodes belong to the target group.
3. The playbook maps that target group to ordered tasks.
4. Each task calls a module.
5. Ansible connects to the managed nodes and performs the work.
6. Ansible reports which hosts succeeded, changed, failed, or could not be reached.

What does this section connect?

A playbook is a YAML automation blueprint.
A play connects a target group to ordered work.
A task names one action.
A module performs the action named by a task.
The numbered flow traces the request from the control node to the reported result.

Save ansible-lesson-1.md with Ctrl+S.

Before you check the finished guide, can you predict the order from the control node to the final report?

Return to the Markdown Preview from earlier.
Scroll from the manual-work illustration to the request-to-result flow.

You should see both labeled illustrations in the preview. Below the Ansible diagram, you should see the glossary followed by six numbered stages.

Missing the glossary or numbered flow?

Check that the glossary begins after the agentless paragraph. Confirm that both new headings start with two hash symbols.

Help me find a Markdown structure problem in my field guide.

✔️ Awesome, I've got everything!

Great. Double-check that ansible-lesson-1.md is saved.

ⓧ I'd like to double check the full code

# Ansible Academy 1.1 Field Guide

## The problem: one task, three servers

A school has three servers. The IT administrator wants every server to show the same maintenance notice. Without automation, the administrator signs in to each server and repeats the same work.

Illustration: Manual work repeated across three servers

```mermaid
flowchart LR
  A[One IT administrator]
  A -->|Repeat the same task| S1[School server 1]
  A -->|Repeat the same task| S2[School server 2]
  A -->|Repeat the same task| S3[School server 3]
```

Plain-text fallback:

```text
One IT administrator -> repeat task -> School server 1
One IT administrator -> repeat task -> School server 2
One IT administrator -> repeat task -> School server 3
```

The risk is simple: the administrator can forget a server, type something differently, or lose track of which machines were changed.

## The restaurant analogy

Imagine a restaurant manager coordinating three kitchen stations.

- The manager gives directions from one place.
- The seating chart lists the tables and their groups.
- The kitchen stations receive work and prepare the result.

In Ansible language, the manager is like the control node, the seating chart is like the inventory, and the kitchen stations are like managed nodes.

## The Ansible way

Illustration: Ansible control model

```mermaid
flowchart LR
  C[Control node: Ansible runs here]
  I[Inventory: lists and groups targets]
  G[school_servers group]
  S1[Managed node: server 1]
  S2[Managed node: server 2]
  S3[Managed node: server 3]
  C -->|Reads| I
  I -->|Describes| G
  C -->|Sends automation over SSH| S1
  C -->|Sends automation over SSH| S2
  C -->|Sends automation over SSH| S3
```

Plain-text fallback:

```text
Control node -> reads inventory -> selects school_servers
Control node -> SSH -> managed node 1
Control node -> SSH -> managed node 2
Control node -> SSH -> managed node 3
```

Ansible is installed on the control node. It is not normally installed on managed nodes. This is why the usual design is called agentless.

## Small glossary

- Control node: The machine from which Ansible command-line tools run.
- Inventory: A list of managed nodes and groups, plus information Ansible needs to identify them.
- Managed node: A target computer or device that Ansible manages. It is also called a host.
- Transport: The connection method used to reach a managed node. Linux systems commonly use SSH.
- Playbook: A YAML automation blueprint containing one or more plays.
- Play: A connection between a target group and an ordered list of tasks.
- Task: One action Ansible should apply.
- Module: The Ansible code that performs the action named by a task.

## From request to result

1. A person starts automation from the control node.
2. Ansible reads the inventory to learn which managed nodes belong to the target group.
3. The playbook maps that target group to ordered tasks.
4. Each task calls a module.
5. Ansible connects to the managed nodes and performs the work.
6. Ansible reports which hosts succeeded, changed, failed, or could not be reached.

That's the control model mapped. Next, you'll connect this architecture to the YAML blueprint that gives Ansible ordered work.

Decode Your First Playbook

Your Ansible control model now shows where automation begins. The architecture stays abstract until you connect it to a file that names the targets and ordered work.

This step turns that model into your first YAML playbook. You will translate each line into a plain-language instruction.

In this step, get ready to:

Create a playbook for the fictional school servers.
Translate each playbook line into everyday language.
Add safety principles for future automation work.

Create the playbook blueprint

A playbook connects a target group to an ordered list of tasks. YAML indentation shows which settings belong to the play and which settings belong to its task.

In the Explorer sidebar from earlier, select the file creation icon at the top.
Type first-playbook.yml.
Press Enter.
Paste the playbook into first-playbook.yml exactly as shown:

- name: Show a school IT notice
  hosts: school_servers
  tasks:
    - name: Print the maintenance message
      ansible.builtin.debug:
        msg: "School systems are maintained by the IT team."

What does this playbook describe?

- name: Show a school IT notice gives the play a human-readable label.
hosts: school_servers points the play at the inventory group from your control-model diagram.
tasks: begins the ordered list of work.
ansible.builtin.debug: selects the built-in module that prints information.
msg: "School systems are maintained by the IT team." holds the message for that module.

Save first-playbook.yml.
Check the indentation against the playbook above.
Confirm that first-playbook.yml is listed beside ansible-lesson-1.md in the Explorer.

You should see the play name at the left edge. The target and task list should sit beneath it with consistent indentation.

Does the playbook structure look uneven?

Confirm that hosts and tasks begin with two spaces.
Confirm that the task name begins with four spaces.
Confirm that the file ends with .yml.

Ask for help checking the nesting in my playbook.

Translate the playbook into plain language

A line-by-line table connects the YAML syntax to the control model you already understand. Each row explains one responsibility without requiring a live Ansible environment.

Switch back to ansible-lesson-1.md.
Move to the blank line at the end of the file.
Paste the reading table on that blank line:

## Reading the first playbook

| YAML part | Everyday meaning |
| --- | --- |
| `- name: Show a school IT notice` | Give the play a human-readable label. |
| `hosts: school_servers` | Aim the play at the inventory group named `school_servers`. |
| `tasks:` | Begin the ordered list of work. |
| `- name: Print the maintenance message` | Give the task a clear label. |
| `ansible.builtin.debug:` | Use Ansible's built-in debug module to print information. |
| `msg: "School systems are maintained by the IT team."` | Provide the exact message the module should print. |

The playbook is a blueprint only in this lesson. It will not run until a later lab provides Ansible and an inventory containing `school_servers`.

How does the table decode the playbook?

The first row identifies the play's human-readable name.
The second row connects school_servers to the inventory group from your diagram.
The middle rows show the ordered task and its module.
The final row identifies the exact message held by msg.
The closing note defines the boundary of this lesson.

Save ansible-lesson-1.md.
Return to the Markdown Preview from earlier.
Find the rendered Reading the first playbook section.

You should see a six-row table beneath the new heading. The note below it should identify the playbook as a blueprint for this lesson.

Does the table appear as plain text?

Confirm that every table row begins with a vertical bar.
Confirm that the divider row contains | --- | --- |.
Confirm that a blank line appears above the table.

Help me fix the Markdown table in my field guide.

Add the safety preview

Automation can repeat a mistake as efficiently as a correct change. The safety preview gives you checks to use before future playbooks touch real systems.

Switch back to the editor for ansible-lesson-1.md.
Move to the blank line after the playbook note.
Paste the safety preview on that blank line:

## Safety preview

- Least privilege: Give automation only the access it needs.
- Secrets: Never place real passwords in practice files. A later lesson will use Ansible Vault to protect sensitive data.
- Idempotency: Good automation aims for the same final state when it runs more than once.
- Dry run: Ansible check mode can report potential changes without applying alterations.
- Backups: Protect important data and configuration before high-risk changes.
- Rollback: Decide how to restore the previous working state before making a risky change.

This lesson changes no managed system, so it needs no system backup or rollback.

What do these safety habits protect?

Least privilege limits the access available to automation.
Ansible Vault protects sensitive data such as passwords.
Idempotency aims for the same final state across repeated runs.
Check mode previews potential changes without applying them.
Backups protect important data before high-risk work.
Rollback provides a route back to the previous working state.

Save ansible-lesson-1.md.
Return to the Markdown Preview from earlier.
Find the rendered Safety preview section.

You should see six safety habits as separate bullets. The final sentence should confirm that this lesson changes no managed system.

Are the safety habits running together?

Confirm that a blank line appears below the Safety preview heading.
Confirm that every safety habit begins with a hyphen.
Confirm that the final sentence sits below a blank line.

Help me fix the safety preview formatting.

✔️ Awesome, I've got everything!

Save both files before completing the final comparison.

ⓧ I'd like to double check the full code

These references show the exact finished contents of both files.

# Ansible Academy 1.1 Field Guide

## The problem: one task, three servers

A school has three servers. The IT administrator wants every server to show the same maintenance notice. Without automation, the administrator signs in to each server and repeats the same work.

Illustration: Manual work repeated across three servers

```mermaid
flowchart LR
  A[One IT administrator]
  A -->|Repeat the same task| S1[School server 1]
  A -->|Repeat the same task| S2[School server 2]
  A -->|Repeat the same task| S3[School server 3]
```

Plain-text fallback:

```text
One IT administrator -> repeat task -> School server 1
One IT administrator -> repeat task -> School server 2
One IT administrator -> repeat task -> School server 3
```

The risk is simple: the administrator can forget a server, type something differently, or lose track of which machines were changed.

## The restaurant analogy

Imagine a restaurant manager coordinating three kitchen stations.

- The manager gives directions from one place.
- The seating chart lists the tables and their groups.
- The kitchen stations receive work and prepare the result.

In Ansible language, the manager is like the control node, the seating chart is like the inventory, and the kitchen stations are like managed nodes.

## The Ansible way

Illustration: Ansible control model

```mermaid
flowchart LR
  C[Control node: Ansible runs here]
  I[Inventory: lists and groups targets]
  G[school_servers group]
  S1[Managed node: server 1]
  S2[Managed node: server 2]
  S3[Managed node: server 3]
  C -->|Reads| I
  I -->|Describes| G
  C -->|Sends automation over SSH| S1
  C -->|Sends automation over SSH| S2
  C -->|Sends automation over SSH| S3
```

Plain-text fallback:

```text
Control node -> reads inventory -> selects school_servers
Control node -> SSH -> managed node 1
Control node -> SSH -> managed node 2
Control node -> SSH -> managed node 3
```

Ansible is installed on the control node. It is not normally installed on managed nodes. This is why the usual design is called agentless.

## Small glossary

- Control node: The machine from which Ansible command-line tools run.
- Inventory: A list of managed nodes and groups, plus information Ansible needs to identify them.
- Managed node: A target computer or device that Ansible manages. It is also called a host.
- Transport: The connection method used to reach a managed node. Linux systems commonly use SSH.
- Playbook: A YAML automation blueprint containing one or more plays.
- Play: A connection between a target group and an ordered list of tasks.
- Task: One action Ansible should apply.
- Module: The Ansible code that performs the action named by a task.

## From request to result

1. A person starts automation from the control node.
2. Ansible reads the inventory to learn which managed nodes belong to the target group.
3. The playbook maps that target group to ordered tasks.
4. Each task calls a module.
5. Ansible connects to the managed nodes and performs the work.
6. Ansible reports which hosts succeeded, changed, failed, or could not be reached.

## Reading the first playbook

| YAML part | Everyday meaning |
| --- | --- |
| `- name: Show a school IT notice` | Give the play a human-readable label. |
| `hosts: school_servers` | Aim the play at the inventory group named `school_servers`. |
| `tasks:` | Begin the ordered list of work. |
| `- name: Print the maintenance message` | Give the task a clear label. |
| `ansible.builtin.debug:` | Use Ansible's built-in debug module to print information. |
| `msg: "School systems are maintained by the IT team."` | Provide the exact message the module should print. |

The playbook is a blueprint only in this lesson. It will not run until a later lab provides Ansible and an inventory containing `school_servers`.

## Safety preview

- Least privilege: Give automation only the access it needs.
- Secrets: Never place real passwords in practice files. A later lesson will use Ansible Vault to protect sensitive data.
- Idempotency: Good automation aims for the same final state when it runs more than once.
- Dry run: Ansible check mode can report potential changes without applying alterations.
- Backups: Protect important data and configuration before high-risk changes.
- Rollback: Decide how to restore the previous working state before making a risky change.

This lesson changes no managed system, so it needs no system backup or rollback.

This file combines the control model with the line-by-line playbook reading and safety preview.

- name: Show a school IT notice
  hosts: school_servers
  tasks:
    - name: Print the maintenance message
      ansible.builtin.debug:
        msg: "School systems are maintained by the IT team."

This file contains the complete school playbook blueprint.

Predict which line connects the playbook to the school_servers group.
Drag the first-playbook.yml editor tab until it sits beside the Markdown Preview.
Compare the YAML with the rendered reading table.

You should see one play targeting school_servers. The play should contain one task using ansible.builtin.debug.

The module should contain one msg with the school maintenance notice. No Ansible command has run during this comparison.

You've made the architecture concrete. Your playbook now names every part of the automation blueprint.

Your first playbook is decoded without changing a managed system. Next, you will use the finished guide to test whether the Ansible model is truly yours.

Prove You Understand the Model

The finished field guide now connects Ansible's control model to the YAML blueprint in first-playbook.yml. The playbook stays unchanged because this step tests your mental model.

Reading can create a quick feeling of familiarity. Explaining the pieces reveals whether you can recall the model without prompts.

Classifying unfamiliar examples tests whether the same model transfers to a new situation. A short interview response then tests whether you can explain the agentless design under time pressure.

In this step, get ready to:

Answer five questions before checking the answer key.
Classify examples as a control node, inventory, managed nodes, or playbook.
Practice a 60-second explanation using the five required terms.

Test your recall before checking the key

A knowledge check turns recognition into recall. Answering before the key exposes any gaps that the finished guide can help you close.

Switch back to the ansible-lesson-1.md editor tab from the previous step.
Place your cursor after the line This lesson changes no managed system, so it needs no system backup or rollback..
Add the knowledge check by pasting this section:

## Five-question knowledge check

Answer before reading the key.

1. Which machine runs the Ansible command-line tools?
2. What does an inventory describe?
3. Are managed nodes normally required to have Ansible installed?
4. What is the difference between a playbook, a task, and a module?
5. Why is repeating the same manual change across many servers risky?

What does this section test?

The first three questions test the control-node model.
The fourth question tests how a playbook connects tasks to modules.
The final question reconnects automation to the risk of inconsistent manual work.

Save ansible-lesson-1.md.
Return to the Markdown Preview from earlier.

You should see the heading Five-question knowledge check followed by five numbered questions.

Questions missing from the preview?

Confirm that you pasted the section after the safety preview. Save ansible-lesson-1.md again if the preview still shows the earlier version.

Help me find why the knowledge check is missing from my Markdown Preview.

Read the five questions without returning to the glossary.
Say each answer aloud before revealing the key.
Switch back to the ansible-lesson-1.md editor tab.
Place your cursor after question five.
Add the answer key by pasting this section:

## Answer key

1. The control node.
2. The managed nodes, their groups, and information used to identify or organize them.
3. No. Ansible is not normally installed on managed nodes.
4. A playbook is the YAML blueprint, a task names one action, and a module performs that action.
5. A person can miss a server, enter inconsistent values, or lose track of what changed.

How does the key help?

Each answer maps back to a definition or diagram in your field guide.
Question four checks whether you can distinguish the blueprint from its ordered actions.
Question five checks whether you can explain the practical reason for automation.

Save ansible-lesson-1.md.
Return to the Markdown Preview from earlier.
Compare your spoken answers with the answer key.
Count how many answers you got right.
Reread the relevant field-guide section if your score is below four.
Answer the missed questions again until you score at least four out of five.

You should now see the answer key beneath the questions. Each correct response should match the same mental model shown in your diagrams.

Answer key joined to question five?

Check for a blank line between question five and ## Answer key. That blank line keeps the new heading separate from the numbered list.

Help me fix the answer-key formatting in my Markdown file.

That score is solid evidence that you can recall the control model without leaning on the answer key.

Classify each part independently

Classification checks whether you can recognize the same roles when the wording changes. The exercise maps new examples to a control node, an inventory, managed nodes, or a playbook.

Switch back to the ansible-lesson-1.md editor tab.
Place your cursor after the final answer in the answer key.
Add the classification exercise by pasting this section:

## Independent classification exercise

Classify each item before checking the suggested answer.

| Item | Your classification |
| --- | --- |
| Administrator's automation computer | |
| List that groups the three Linux servers | |
| The three Linux servers | |
| YAML file describing ordered work | |

Suggested answer: control node, inventory, managed nodes, and playbook.

What does this exercise change?

The examples describe familiar roles without using their glossary labels.
The empty column gives you space to decide each classification before checking the suggested sequence.
The suggested answer lets you verify all four choices in the same order as the table.

Save ansible-lesson-1.md.
Return to the Markdown Preview from earlier.

You should see a four-row table beneath Independent classification exercise. The suggested answer should appear below the table.

Read each item in the table.
Say its classification aloud before scrolling to the suggested answer.
Compare your four classifications with the suggested sequence.
Explain each choice using the role that the item performs.

Table showing as plain text?

Confirm that every table row starts with a vertical bar. Check that the separator row remains directly beneath the header row.

Help me repair the classification table in my Markdown file.

Practice your 60-second explanation

A short answer forces you to choose the most important parts of the model. Your explanation should connect where Ansible runs to how it reaches targets.

Set a timer for 60 seconds.
Answer this question aloud: “What is Ansible, and how does its agentless model work?”.
Use the terms control node, inventory, managed nodes, agentless, and playbook in your response.
Switch back to the ansible-lesson-1.md editor tab after speaking.
Place your cursor after the suggested classification answer.
Add the interview practice section by pasting this content:

## Interview practice

Question: What is Ansible, and how does its agentless model work?

Model response: Ansible is an automation tool that runs from a control node. It reads an inventory to find managed nodes and uses playbooks to describe ordered work. For Linux targets, it commonly connects over SSH. Ansible is not normally installed as an agent on each managed node, which keeps the managed side simpler.

How is the model response structured?

The opening sentence defines Ansible through its purpose and control node.
The next sentence links the inventory to managed nodes and playbooks.
The final two sentences explain the connection method and agentless design.

Save ansible-lesson-1.md.
Return to the Markdown Preview from earlier.
Read the model response after completing your spoken attempt.
Compare its structure with your response.
Count the five required terms in your response.
Return to Step 3 if two or more required terms were missing.
Repeat your 60-second response until it includes all five terms.

Response running over 60 seconds?

Use one sentence for the control node. Use one sentence for the inventory and playbook relationship.

Finish with one sentence explaining why managed nodes do not normally need an Ansible agent.

Help me shorten my Ansible explanation while keeping the five required terms.

Switch back to the ansible-lesson-1.md editor tab.

Before you refresh the preview, predict whether all four new sections will appear in order.

Press Ctrl+K V to open the Markdown Preview to the side.

You should see the five-question knowledge check, answer key, independent classification exercise, and interview practice response beneath the safety preview. The Explorer should still show first-playbook.yml unchanged beside ansible-lesson-1.md.

Preview did not open to the side?

Press Ctrl+Shift+P to open the Command Palette.
Run Markdown: Open Preview to the Side.

Help me open the completed field guide in Visual Studio Code's Markdown Preview.

You have now proved that the control model is yours. You can recall it, classify it, and explain it in a beginner interview response.

✔️ Awesome, I've got everything!

Your field guide is complete. Keep first-playbook.yml unchanged for the optional challenge that follows.

ⓧ I'd like to double check the full code

# Ansible Academy 1.1 Field Guide

## The problem: one task, three servers

A school has three servers. The IT administrator wants every server to show the same maintenance notice. Without automation, the administrator signs in to each server and repeats the same work.

Illustration: Manual work repeated across three servers

```mermaid
flowchart LR
  A[One IT administrator]
  A -->|Repeat the same task| S1[School server 1]
  A -->|Repeat the same task| S2[School server 2]
  A -->|Repeat the same task| S3[School server 3]
```

Plain-text fallback:

```text
One IT administrator -> repeat task -> School server 1
One IT administrator -> repeat task -> School server 2
One IT administrator -> repeat task -> School server 3
```

The risk is simple: the administrator can forget a server, type something differently, or lose track of which machines were changed.

## The restaurant analogy

Imagine a restaurant manager coordinating three kitchen stations.

- The manager gives directions from one place.
- The seating chart lists the tables and their groups.
- The kitchen stations receive work and prepare the result.

In Ansible language, the manager is like the control node, the seating chart is like the inventory, and the kitchen stations are like managed nodes.

## The Ansible way

Illustration: Ansible control model

```mermaid
flowchart LR
  C[Control node: Ansible runs here]
  I[Inventory: lists and groups targets]
  G[school_servers group]
  S1[Managed node: server 1]
  S2[Managed node: server 2]
  S3[Managed node: server 3]
  C -->|Reads| I
  I -->|Describes| G
  C -->|Sends automation over SSH| S1
  C -->|Sends automation over SSH| S2
  C -->|Sends automation over SSH| S3
```

Plain-text fallback:

```text
Control node -> reads inventory -> selects school_servers
Control node -> SSH -> managed node 1
Control node -> SSH -> managed node 2
Control node -> SSH -> managed node 3
```

Ansible is installed on the control node. It is not normally installed on managed nodes. This is why the usual design is called agentless.

## Small glossary

- Control node: The machine from which Ansible command-line tools run.
- Inventory: A list of managed nodes and groups, plus information Ansible needs to identify them.
- Managed node: A target computer or device that Ansible manages. It is also called a host.
- Transport: The connection method used to reach a managed node. Linux systems commonly use SSH.
- Playbook: A YAML automation blueprint containing one or more plays.
- Play: A connection between a target group and an ordered list of tasks.
- Task: One action Ansible should apply.
- Module: The Ansible code that performs the action named by a task.

## From request to result

1. A person starts automation from the control node.
2. Ansible reads the inventory to learn which managed nodes belong to the target group.
3. The playbook maps that target group to ordered tasks.
4. Each task calls a module.
5. Ansible connects to the managed nodes and performs the work.
6. Ansible reports which hosts succeeded, changed, failed, or could not be reached.

## Reading the first playbook

| YAML part | Everyday meaning |
| --- | --- |
| `- name: Show a school IT notice` | Give the play a human-readable label. |
| `hosts: school_servers` | Aim the play at the inventory group named `school_servers`. |
| `tasks:` | Begin the ordered list of work. |
| `- name: Print the maintenance message` | Give the task a clear label. |
| `ansible.builtin.debug:` | Use Ansible's built-in debug module to print information. |
| `msg: "School systems are maintained by the IT team."` | Provide the exact message the module should print. |

The playbook is a blueprint only in this lesson. It will not run until a later lab provides Ansible and an inventory containing `school_servers`.

## Safety preview

- Least privilege: Give automation only the access it needs.
- Secrets: Never place real passwords in practice files. A later lesson will use Ansible Vault to protect sensitive data.
- Idempotency: Good automation aims for the same final state when it runs more than once.
- Dry run: Ansible check mode can report potential changes without applying alterations.
- Backups: Protect important data and configuration before high-risk changes.
- Rollback: Decide how to restore the previous working state before making a risky change.

This lesson changes no managed system, so it needs no system backup or rollback.

## Five-question knowledge check

Answer before reading the key.

1. Which machine runs the Ansible command-line tools?
2. What does an inventory describe?
3. Are managed nodes normally required to have Ansible installed?
4. What is the difference between a playbook, a task, and a module?
5. Why is repeating the same manual change across many servers risky?

## Answer key

1. The control node.
2. The managed nodes, their groups, and information used to identify or organize them.
3. No. Ansible is not normally installed on managed nodes.
4. A playbook is the YAML blueprint, a task names one action, and a module performs that action.
5. A person can miss a server, enter inconsistent values, or lose track of what changed.

## Independent classification exercise

Classify each item before checking the suggested answer.

| Item | Your classification |
| --- | --- |
| Administrator's automation computer | |
| List that groups the three Linux servers | |
| The three Linux servers | |
| YAML file describing ordered work | |

Suggested answer: control node, inventory, managed nodes, and playbook.

## Interview practice

Question: What is Ansible, and how does its agentless model work?

Model response: Ansible is an automation tool that runs from a control node. It reads an inventory to find managed nodes and uses playbooks to describe ordered work. For Linux targets, it commonly connects over SSH. Ansible is not normally installed as an agent on each managed node, which keeps the managed side simpler.

Secret mission

Adapt the Playbook for a Library

The school playbook has a structure you can reuse. Adapt that structure for a fictional library server group while keeping the same debug operation.

Clean Up Your Resources

This project created only local files, so there are no ongoing costs. Choose whether to keep the lesson-01 workspace open, close it for later, or delete its files.

Resources you used:

A local lesson-01 folder containing ansible-lesson-1.md, first-playbook.yml, and library-playbook.yml.

Keep everything running

No action is required. Choose this option if you want your field guide ready for the next Ansible Academy lesson.

Keep the lesson-01 folder in the Documents folder Windows already shows you.
Leave the Visual Studio Code workspace open if you plan to continue now.
Keep the Markdown Preview open as a rendered reference for your diagrams and glossary.

Pause - I'll come back to this later

Close the open workspace while keeping every lesson file available for later.

Close the Markdown Preview tab.
Close Visual Studio Code.
Keep the lesson-01 folder inside the Documents folder Windows already shows you.

Delete - I don't want to use this again

Deleting this folder removes your field guide and both playbooks. No managed system is affected because this lesson never ran Ansible.

Close the Markdown Preview tab.
Close Visual Studio Code.
Use Windows File Explorer to navigate to Documents\ansible-academy\module-01.
Move the lesson-01 folder to the Recycle Bin.
Open the Recycle Bin.
Permanently remove the lesson-01 folder.
Return to module-01.
Confirm that lesson-01 is no longer listed.

Nice Work!

You made it! Your visual field guide now gives you a concrete way to explain how Ansible coordinates work from one control point.

You learned how to:

Visualize the automation model: Build diagrams that reveal the cost of repeating work across three servers. Replace that pattern with one control node directing three managed nodes.
Decode a playbook: Translate first-playbook.yml from YAML into everyday language. Connect the play to its target group. Trace the task to the module that prints the message. Preview safety habits from least privilege through rollback planning.
Prove your understanding: Complete the five-question knowledge check. Classify each architecture component independently. Deliver a 60-second explanation of the agentless control model.
Secret Mission: Adapt library-playbook.yml for library_servers. Explain why ansible.builtin.debug still fits the new scenario.

Ready to quiz yourself?