Official Certifications: Ansible
Date: July 15, 2026
Source: https://www.redhat.com/en/services/certifications
This document maps the workshop to official Red Hat certification paths. It does not invent exams and does not copy real exam questions.
1. Official Source
Deep Dive and Submission Example for Official Source
A complete treatment of Official Source contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.
| Submission Part | Content | Minimum Quality |
|---|---|---|
| target description | what should be true after the run | measurable and without hidden assumptions |
| scope evidence | which hosts are affected | output from --list-hosts or inventory graph |
| implementation | which files were changed | small reviewable YAML files |
| validation | how it was checked | syntax check, check mode, diff, real run, second run |
| risk decision | what can go wrong | privileges, secrets, external dependencies, and rollback considered |
Minimal Artifacts for Official Source
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
For roles or collections, the structure expands:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Grading Expectation for Official Source
A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.
Transfer to Real Teams
In a team context, Official Source is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.
Practical Relevance of Official Source
This section is not just a definition. In the workshop, Official Source is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.
| Review Question | Expected Answer |
|---|---|
| Which hosts are affected? | Pattern, group, --limit, and inventory output are documented. |
| Which data sources apply? | group_vars, host_vars, defaults, extra vars, and facts are known. |
| Which privileges are required? | become is close to the task and justified. |
| How is success proven? | Syntax check, check mode, diff, play recap, and second run are present. |
Example Flow for Official Source
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.
Review Criteria for Official Source
- Inventory and patterns are narrower than
allunless a reason is documented. - Modules from
ansible.builtinor reviewed collections are preferred. - Shell or command tasks include
changed_when,failed_when, or a clear reason. - Variables are placed predictably and do not override each other surprisingly.
- Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
- The playbook can run repeatedly without unnecessary changes.
- Cleanup, fix-forward, or controlled acceptance of the target state is documented.
Common Failure Modes for Official Source
| Failure | Cause | Diagnosis |
|---|---|---|
| wrong hosts targeted | pattern or inventory misunderstood | --list-hosts, ansible-inventory --host |
unreachable |
SSH, user, Python, or network issue | -vvvv, SSH test, inventory variables |
| unexpected change | module not idempotent or wrong data source | second run, diff, variable inspection |
| secret leak | debug, diff, or log not scoped | check no_log, Vault, CI artifacts |
| handler does not run | no changed result or wrong handler name |
inspect task result and handler name |
Operations Note for Official Source
For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.
The authoritative source is the Red Hat certification page. It maintains levels, prerequisites, exams, and paths.
2. Current Ansible-related Paths
Deep Dive and Submission Example for Current Ansible-related Paths
A complete treatment of Current Ansible-related Paths contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.
| Submission Part | Content | Minimum Quality |
|---|---|---|
| target description | what should be true after the run | measurable and without hidden assumptions |
| scope evidence | which hosts are affected | output from --list-hosts or inventory graph |
| implementation | which files were changed | small reviewable YAML files |
| validation | how it was checked | syntax check, check mode, diff, real run, second run |
| risk decision | what can go wrong | privileges, secrets, external dependencies, and rollback considered |
Minimal Artifacts for Current Ansible-related Paths
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
For roles or collections, the structure expands:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Grading Expectation for Current Ansible-related Paths
A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.
Transfer to Real Teams
In a team context, Current Ansible-related Paths is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.
Practical Relevance of Current Ansible-related Paths
This section is not just a definition. In the workshop, Current Ansible-related Paths is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.
| Review Question | Expected Answer |
|---|---|
| Which hosts are affected? | Pattern, group, --limit, and inventory output are documented. |
| Which data sources apply? | group_vars, host_vars, defaults, extra vars, and facts are known. |
| Which privileges are required? | become is close to the task and justified. |
| How is success proven? | Syntax check, check mode, diff, play recap, and second run are present. |
Example Flow for Current Ansible-related Paths
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.
Review Criteria for Current Ansible-related Paths
- Inventory and patterns are narrower than
allunless a reason is documented. - Modules from
ansible.builtinor reviewed collections are preferred. - Shell or command tasks include
changed_when,failed_when, or a clear reason. - Variables are placed predictably and do not override each other surprisingly.
- Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
- The playbook can run repeatedly without unnecessary changes.
- Cleanup, fix-forward, or controlled acceptance of the target state is documented.
Common Failure Modes for Current Ansible-related Paths
| Failure | Cause | Diagnosis |
|---|---|---|
| wrong hosts targeted | pattern or inventory misunderstood | --list-hosts, ansible-inventory --host |
unreachable |
SSH, user, Python, or network issue | -vvvv, SSH test, inventory variables |
| unexpected change | module not idempotent or wrong data source | second run, diff, variable inspection |
| secret leak | debug, diff, or log not scoped | check no_log, Vault, CI artifacts |
| handler does not run | no changed result or wrong handler name |
inspect task result and handler name |
Operations Note for Current Ansible-related Paths
For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.
The Red Hat page lists, among others, the following Ansible-related items:
| Path | Requirements according to the official page |
|---|---|
| Red Hat Certified Systems Administrator in the Ansible path | EX200: Red Hat Certified System Administrator exam |
| Red Hat Certified Engineer in Ansible | EX200 and EX294: Red Hat Certified Advanced System Administrator in Ansible exam |
| Ansible Specialist | EX374, EX417, EX457, or EX467 |
| Red Hat Certified Architect in Ansible | EX200, EX294, and at least three specialist exams from the Ansible area |
Listed specialist exams:
- EX374: Red Hat Certified Specialist in Developing Automation with Ansible Automation Platform exam
- EX417: Red Hat Certified Specialist in Microsoft Windows Automation with Ansible exam
- EX457: Red Hat Certified Specialist in Ansible Network Automation exam
- EX467: Red Hat Certified Specialist in Managing Automation with Ansible Automation Platform exam
3. Workshop Mapping
Deep Dive and Submission Example for Workshop Mapping
A complete treatment of Workshop Mapping contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.
| Submission Part | Content | Minimum Quality |
|---|---|---|
| target description | what should be true after the run | measurable and without hidden assumptions |
| scope evidence | which hosts are affected | output from --list-hosts or inventory graph |
| implementation | which files were changed | small reviewable YAML files |
| validation | how it was checked | syntax check, check mode, diff, real run, second run |
| risk decision | what can go wrong | privileges, secrets, external dependencies, and rollback considered |
Minimal Artifacts for Workshop Mapping
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
For roles or collections, the structure expands:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Grading Expectation for Workshop Mapping
A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.
Transfer to Real Teams
In a team context, Workshop Mapping is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.
Practical Relevance of Workshop Mapping
This section is not just a definition. In the workshop, Workshop Mapping is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.
| Review Question | Expected Answer |
|---|---|
| Which hosts are affected? | Pattern, group, --limit, and inventory output are documented. |
| Which data sources apply? | group_vars, host_vars, defaults, extra vars, and facts are known. |
| Which privileges are required? | become is close to the task and justified. |
| How is success proven? | Syntax check, check mode, diff, play recap, and second run are present. |
Example Flow for Workshop Mapping
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.
Review Criteria for Workshop Mapping
- Inventory and patterns are narrower than
allunless a reason is documented. - Modules from
ansible.builtinor reviewed collections are preferred. - Shell or command tasks include
changed_when,failed_when, or a clear reason. - Variables are placed predictably and do not override each other surprisingly.
- Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
- The playbook can run repeatedly without unnecessary changes.
- Cleanup, fix-forward, or controlled acceptance of the target state is documented.
Common Failure Modes for Workshop Mapping
| Failure | Cause | Diagnosis |
|---|---|---|
| wrong hosts targeted | pattern or inventory misunderstood | --list-hosts, ansible-inventory --host |
unreachable |
SSH, user, Python, or network issue | -vvvv, SSH test, inventory variables |
| unexpected change | module not idempotent or wrong data source | second run, diff, variable inspection |
| secret leak | debug, diff, or log not scoped | check no_log, Vault, CI artifacts |
| handler does not run | no changed result or wrong handler name |
inspect task result and handler name |
Operations Note for Workshop Mapping
For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.
| Workshop Area | Relevant Competencies |
|---|---|
| Fundamentals | Inventory, playbooks, modules, idempotence, diagnostics |
| Intermediate | Variables, facts, templates, roles, includes, Vault basics |
| Professional | Collections, CI, orchestration, multiple inventories, Controller/AWX orientation |
| Advanced + Security | Least privilege, secret flows, supply chain, execution environments, security review |
4. Preparation Without Exam Questions
Deep Dive and Submission Example for Preparation Without Exam Questions
A complete treatment of Preparation Without Exam Questions contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.
| Submission Part | Content | Minimum Quality |
|---|---|---|
| target description | what should be true after the run | measurable and without hidden assumptions |
| scope evidence | which hosts are affected | output from --list-hosts or inventory graph |
| implementation | which files were changed | small reviewable YAML files |
| validation | how it was checked | syntax check, check mode, diff, real run, second run |
| risk decision | what can go wrong | privileges, secrets, external dependencies, and rollback considered |
Minimal Artifacts for Preparation Without Exam Questions
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
For roles or collections, the structure expands:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Grading Expectation for Preparation Without Exam Questions
A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.
Transfer to Real Teams
In a team context, Preparation Without Exam Questions is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.
Practical Relevance of Preparation Without Exam Questions
This section is not just a definition. In the workshop, Preparation Without Exam Questions is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.
| Review Question | Expected Answer |
|---|---|
| Which hosts are affected? | Pattern, group, --limit, and inventory output are documented. |
| Which data sources apply? | group_vars, host_vars, defaults, extra vars, and facts are known. |
| Which privileges are required? | become is close to the task and justified. |
| How is success proven? | Syntax check, check mode, diff, play recap, and second run are present. |
Example Flow for Preparation Without Exam Questions
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.
Review Criteria for Preparation Without Exam Questions
- Inventory and patterns are narrower than
allunless a reason is documented. - Modules from
ansible.builtinor reviewed collections are preferred. - Shell or command tasks include
changed_when,failed_when, or a clear reason. - Variables are placed predictably and do not override each other surprisingly.
- Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
- The playbook can run repeatedly without unnecessary changes.
- Cleanup, fix-forward, or controlled acceptance of the target state is documented.
Common Failure Modes for Preparation Without Exam Questions
| Failure | Cause | Diagnosis |
|---|---|---|
| wrong hosts targeted | pattern or inventory misunderstood | --list-hosts, ansible-inventory --host |
unreachable |
SSH, user, Python, or network issue | -vvvv, SSH test, inventory variables |
| unexpected change | module not idempotent or wrong data source | second run, diff, variable inspection |
| secret leak | debug, diff, or log not scoped | check no_log, Vault, CI artifacts |
| handler does not run | no changed result or wrong handler name |
inspect task result and handler name |
Operations Note for Preparation Without Exam Questions
For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.
The workshop prepares through concepts, labs, and reviewability. It does not contain real exam questions. Good preparation means running tasks yourself, analyzing failures, and documenting evidence cleanly.
5. Boundaries
Deep Dive and Submission Example for Boundaries
A complete treatment of Boundaries contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.
| Submission Part | Content | Minimum Quality |
|---|---|---|
| target description | what should be true after the run | measurable and without hidden assumptions |
| scope evidence | which hosts are affected | output from --list-hosts or inventory graph |
| implementation | which files were changed | small reviewable YAML files |
| validation | how it was checked | syntax check, check mode, diff, real run, second run |
| risk decision | what can go wrong | privileges, secrets, external dependencies, and rollback considered |
Minimal Artifacts for Boundaries
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
For roles or collections, the structure expands:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Grading Expectation for Boundaries
A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.
Transfer to Real Teams
In a team context, Boundaries is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.
Practical Relevance of Boundaries
This section is not just a definition. In the workshop, Boundaries is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.
| Review Question | Expected Answer |
|---|---|
| Which hosts are affected? | Pattern, group, --limit, and inventory output are documented. |
| Which data sources apply? | group_vars, host_vars, defaults, extra vars, and facts are known. |
| Which privileges are required? | become is close to the task and justified. |
| How is success proven? | Syntax check, check mode, diff, play recap, and second run are present. |
Example Flow for Boundaries
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.
Review Criteria for Boundaries
- Inventory and patterns are narrower than
allunless a reason is documented. - Modules from
ansible.builtinor reviewed collections are preferred. - Shell or command tasks include
changed_when,failed_when, or a clear reason. - Variables are placed predictably and do not override each other surprisingly.
- Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
- The playbook can run repeatedly without unnecessary changes.
- Cleanup, fix-forward, or controlled acceptance of the target state is documented.
Common Failure Modes for Boundaries
| Failure | Cause | Diagnosis |
|---|---|---|
| wrong hosts targeted | pattern or inventory misunderstood | --list-hosts, ansible-inventory --host |
unreachable |
SSH, user, Python, or network issue | -vvvv, SSH test, inventory variables |
| unexpected change | module not idempotent or wrong data source | second run, diff, variable inspection |
| secret leak | debug, diff, or log not scoped | check no_log, Vault, CI artifacts |
| handler does not run | no changed result or wrong handler name |
inspect task result and handler name |
Operations Note for Boundaries
For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.
Always check the official page before booking because names, versions, paths, and blueprints can change.