EX447
Red Hat Certified Specialist in Advanced Automation: Ansible Best Practices
EX447 Exam Guide: Advanced Automation Ansible Best Practices
EX447 was Red Hat’s performance-based exam for advanced Ansible automation, covering practical administration of task execution and the automation controller formerly known as Ansible Tower. Its intended audience included experienced Linux system administrators, DevOps engineers, cloud administrators, and related IT professionals. The most important decision for a reader now is not how to book EX447, but whether the retired exam still fits a current certification plan. This guide explains its former scope, the skills it validated, how to study its objectives responsibly, and what to verify before choosing a current Red Hat path.
Is EX447 still available?
No. Red Hat currently labels EX447 and its associated Red Hat Certified Specialist in Advanced Automation: Ansible Best Practices credential as retired, and states that the credential is no longer available. A candidate should therefore treat EX447 as a legacy exam reference rather than a currently schedulable certification target.
This status changes the practical use of preparation material. The objectives remain useful for understanding advanced Ansible practices, reviewing older automation-controller implementations, or mapping previous experience to a newer Red Hat option. They should not be used as evidence that a booking, delivery appointment, price, exam session, or credential award is currently available.
Start by checking Red Hat’s current training and certification pages rather than relying on an archived course listing or a third-party calendar. If a training provider still advertises EX447, ask whether the listing is historical, a replacement offering, or an error. Do not pay for a purported EX447 appointment without confirming the status through Red Hat or an authorized training partner.
What this means for a certification plan
If the goal is a current Red Hat credential, compare the skills in this guide with the active certifications shown by Red Hat. If the goal is professional development, use the former objectives as a laboratory checklist, but label the result as skills practice rather than EX447 preparation for a live attempt.
The retired status also means that old discussions about exam delivery, available versions, or scheduling procedures may no longer apply. Separate stable information—such as the performance-based testing model—from time-sensitive information that must be confirmed with Red Hat.
What did EX447 validate?
EX447 was a performance-based test of managing multiple systems with Red Hat Ansible Engine and Red Hat Ansible Tower. The associated credential validated skills in administering Ansible task execution and managing the automation controller, which Red Hat now describes in its certification material as the automation controller formerly known as Ansible Tower.
The exam was designed to assess whether a candidate could build, troubleshoot, and operate automation in a realistic administration setting. That is different from recalling isolated module names or recognizing a correct YAML fragment. The work required connecting inventory design, variables, playbook behavior, source control, controller objects, and execution decisions into a functioning automation workflow.
Red Hat’s general certification FAQ explains that its exams are performance-based: candidates perform real-world tasks rather than answer only multiple-choice questions. That fact supports a hands-on preparation method, although it does not restore EX447’s availability or establish that an identical environment exists today.
The credential’s place in the Red Hat portfolio
Passing EX447 earned the Red Hat Certified Specialist in Advanced Automation: Ansible Best Practices credential, which counted toward the Red Hat Certified Architect credential. The historical relationship is useful when interpreting older certification plans, but the associated credential is now retired.
A current RHCE certification remains an eligibility requirement for taking any Red Hat Certificate of Expertise Exam, according to the supplied Red Hat FAQ. That rule is relevant background for older upper-level planning, but it should not be interpreted as a route to schedule the retired EX447.
Who was EX447 intended for?
EX447 was aimed at experienced Linux system administrators, DevOps engineers, cloud administrators, and other IT professionals who already worked with Ansible or comparable automation environments. It was not positioned as a first exposure to Linux administration, YAML, or basic playbook execution.
Red Hat listed DO447 Advanced Automation: Ansible Best Practices, or comparable experience, as an EX447 prerequisite or preparation route. It also listed RH294 Red Hat System Administration III: Linux Automation, or comparable Red Hat Enterprise Linux and Ansible experience, among the prerequisites. These routes indicate the expected starting point: a candidate should already understand ordinary automation before concentrating on advanced structure and controller operations.
Use the prerequisite language as a readiness test rather than a shopping list. If you can write a simple playbook but cannot explain inventory precedence, delegated facts, privilege behavior, or controller workflow objects, advanced preparation should begin with those foundations. If you already maintain shared automation, focus on repeatability, troubleshooting, and operational design rather than introductory syntax.
A practical readiness check
Before following an EX447-based study plan, confirm that you can create an inventory, target groups predictably, write idempotent tasks, use handlers, work with variables, and diagnose a failed play. You should also be comfortable reading existing repositories instead of relying only on files you wrote yourself.
For controller-related practice, determine whether your lab uses the historical Ansible Tower model, a later automation controller, or another platform. The concepts may overlap, but menus, APIs, object names, permissions, and supported behavior can differ. Study the product documentation for the version in your lab and do not assume that a legacy interface is a current exam interface.
Which technical skills were measured?
The published EX447 objectives concentrated on advanced playbook construction, inventory and variable design, delegation, data transformation, Git-based workflow, and controller administration. Organize preparation around the dependency between these areas: first make the automation correct, then make it maintainable, then make it operable through a controller.
The supplied objectives do not provide a percentage blueprint. Do not assign informal weights to the domains or compare unsupported percentages. Instead, use the complete objective set to find weak areas and give additional practice time to tasks that combine several skills.
External data, templates, and transformation
EX447 objectives included using lookup and query functions to obtain external data for playbooks and deployed template files. They also included transforming data with Ansible filters and plugins. These skills require more than memorizing function names: you need to understand the shape of the returned data, when evaluation occurs, and how the result is consumed by a task or template.
Build small exercises that start with a known data source and end with a rendered configuration. Inspect the value before placing it in a template. Test empty results, multiple results, missing keys, and unexpected types. A useful troubleshooting habit is to isolate the lookup or query first, then test the filter chain, and only then debug the final file.
A common mistake is to treat a lookup as if it always returned a scalar string. Document whether your play expects a list, dictionary, or single value, and make that expectation visible in the playbook. This reduces failures caused by a correct function used with an incorrect data model.
Delegation and fact placement
The objectives included delegating tasks to other hosts and controlling where delegated facts were assigned. Practice by separating the host that owns the play from the host that should perform a particular action, then verify which machine receives the resulting fact or state.
Use a laboratory scenario such as collecting information from one system while configuring another, but avoid assuming that delegation automatically changes every variable, connection, or fact. Trace the execution target explicitly. After each task, inspect the relevant host variables and confirm that later tasks read the intended values.
A frequent error is to delegate a task and then reason about it as though the original inventory host performed it. Another is to store a fact on the delegated host when later logic expects it on the original host. Make the ownership decision deliberate and test it with more than one host.
Privilege execution and task selection
EX447 objectives included controlling privilege execution and selecting tasks. Preparation should cover how privilege settings affect a task, a block, a play, and the execution context, as well as how tags or other selection mechanisms change the work that actually runs.
Create a playbook where only a controlled subset of tasks is selected, then verify both the intended changes and the skipped dependencies. Test privileged and unprivileged operations separately. Record which settings are inherited and which are overridden, because a task that works in a full run may fail when selected on its own.
Do not confuse a successful command with a correct privilege design. Prefer the narrowest privilege needed, keep sensitive values out of visible output where appropriate, and test the same task under the account and connection conditions used by the automation environment.
Inventory and variable architecture
The objectives included structuring host and group variables with multiple files and using special variables to override inventory connection details. This area tests whether automation remains understandable as the number of systems and environments grows.
Design a small inventory with separate host and group data, then introduce a connection override for one host. Verify variable resolution by displaying carefully chosen non-secret values and by observing the connection used. Keep the directory layout explicit so that a reviewer can identify where a value originates.
Avoid scattering the same setting across inventory, group variables, host variables, play variables, and task arguments without a reason. When troubleshooting, trace the value from its source to the task that consumes it. A concise variable map is often more useful than another round of blind edits.
Git as part of the automation workflow
EX447 objectives included using Git to clone repositories, modify files, and commit changes to repositories. The expected skill was operational: obtain the source, make a controlled change, and preserve that change in a repository rather than editing an isolated copy.
Practice a complete cycle. Clone a repository, inspect its branches and files, change a playbook or template, run validation, review the diff, and commit only the intended files. Deliberately create an avoidable change and learn to remove it before committing. This habit helps distinguish a working directory problem from an automation problem.
A common mistake is to edit the wrong checkout or commit generated files with the playbook. Use status and diff checks before and after every change. In a controller workflow, also verify which branch or revision the project is configured to use; a correct local change is irrelevant if the controller retrieves another revision.
Controller objects and API operations
The associated certification covered managing inventories, credentials, advanced inventories, projects, and job workflows. It also covered launching jobs with the automation controller API. Prepare by treating these objects as connected parts of an execution system, not as unrelated screens.
Map the relationship between a project source, its revision, an inventory, credentials, a job template or workflow, and the permissions needed to run it. Then reproduce the same execution through the documented API for the controller version available in your lab. Check the response, identify the launched job, and inspect its result rather than assuming that an accepted request means the automation succeeded.
Protect credentials and tokens in the lab. Use documentation to confirm endpoint names, request fields, authentication behavior, and version differences. Do not copy an old API example into a current environment without checking it against the installed product documentation.
How should you prepare for a performance-based exam?
Use task completion and troubleshooting as your principal measures of readiness. A candidate who can explain Ansible concepts but cannot produce a working result under changing inventory, variable, and controller conditions has not yet practiced the behavior that performance-based testing is designed to assess.
Because EX447 is retired, this preparation method is best understood as a skills-development plan or a way to interpret historical requirements. It does not predict a current exam interface, task set, scoring method, or available delivery option. Use current Red Hat documentation for any replacement certification.
Build one integrated lab
Create a lab with multiple managed systems, distinct groups, and at least one host requiring a connection override. Store playbooks in Git. Add a controller or automation platform only after the command-line playbooks are predictable. This ordering helps you identify whether a failure belongs to the playbook, inventory, credentials, project revision, or controller configuration.
Keep the lab reproducible. Record the operating system and Ansible-related versions, inventory layout, repository revision, and controller configuration. A reproducible environment makes it possible to reset after an experiment and compare results rather than accumulating unexplained fixes.
Use deliberately small scenarios first: render one file, delegate one task, set one fact, select one tag, or launch one job. Combine them only after each behavior is understood. Complexity should come from the interaction of known components, not from an untraceable pile of examples.
Study in dependency order
Begin with inventory and variable resolution, because every later task depends on targeting the intended systems and receiving the intended values. Move to privilege and task selection, then delegation and fact placement. After that, add lookups, queries, filters, and templates. Finish with Git and controller workflows, where earlier playbook decisions become operational objects.
At the end of each topic, write a short failure note: what was expected, what happened, how you isolated the cause, and what change fixed it. This creates a troubleshooting record that is more useful than a list of commands copied from a course.
Revisit topics in mixed combinations. For example, render data obtained externally, delegate collection to another host, select only a part of the play, and run the resulting project through a controller. The purpose is not to reproduce a secret question; it is to develop reliable reasoning when several ordinary features interact.
Use documentation deliberately
Practice finding the exact documentation needed for a task instead of memorizing every option. Check module and plugin behavior, variable precedence, controller version differences, Git project settings, and API request requirements against authoritative documentation for the software you are using.
Keep a personal index of the questions that caused delays: Which host owns this fact? Which revision does the project use? Which credential is applied? Is this value a string or a list? What does the selected tag include? These questions become a fast diagnostic checklist during future automation work.
Avoid treating third-party question banks, dumps, or leaked material as preparation. They cannot establish current exam availability, and memorizing purported answers does not demonstrate the practical skill that Red Hat’s performance-based model is intended to measure.
What mistakes most often derail preparation?
The largest planning mistake is preparing as though EX447 were an active exam. The next is studying isolated syntax without verifying behavior in a multi-system environment. A sound plan starts with the retirement notice, confirms the current certification target, and then uses the legacy objectives only where they support a legitimate skills goal.
Other errors are technical and preventable: ambiguous variable ownership, untested delegation, excessive privilege, unreviewed Git changes, and controller configuration that is never validated from source to job result.
Confusing a successful run with a correct design
A playbook can finish without an obvious error and still write the wrong content, target the wrong host, or depend on an accidental variable. Inspect the resulting state, not only the return code. Run it again to check idempotent behavior where appropriate and verify that the intended system—not merely any reachable system—changed.
Ignoring version and product boundaries
EX447 concerned Red Hat Ansible Engine and Red Hat Ansible Tower, while current Red Hat offerings may use different product naming and versions. Do not transfer an old command, endpoint, or interface assumption without validation. Keep a clear boundary between the historical exam objectives and the product version used for present-day practice.
Overlooking controller dependencies
A project, inventory, credential, workflow, and API request can each be valid in isolation while their combination fails. Test the full chain and record the revision, inventory, credentials, permissions, and launch parameters. Troubleshoot from the controller job output back to the source repository instead of changing several objects at once.
Treating prerequisites as optional background
If basic Linux administration, Ansible playbook construction, or RH294-level automation is weak, advanced topics will appear inconsistent because the underlying behavior is not yet stable. Close that gap first. The most efficient study plan is not always the one that starts with the most advanced-looking objective.
What should you verify before pursuing a Red Hat alternative?
Check Red Hat’s current certification catalogue and the current training page before selecting a replacement. Confirm the active exam name, objectives, prerequisites, delivery details, and credential relationship directly from Red Hat. The supplied sources establish EX447’s retirement but do not identify a specific successor, so naming one here would be unsupported.
If you already hold a Red Hat certificate and need to establish its status, Red Hat says to verify it by entering the certificate number at its certificate-verification page. This is separate from deciding whether a retired exam can be taken.
For identification questions, Red Hat’s FAQ says a government-issued photo identification is required in most areas. Candidates in regions where such identification is unavailable should contact their local Red Hat office or authorized Red Hat training partner for guidance on acceptable identification. Because EX447 is retired, confirm requirements for the current exam rather than carrying forward legacy assumptions.
Questions to ask Red Hat or a training partner
Ask which current exam measures the automation skills you need, whether your existing RHCE status affects eligibility, which course or comparable experience is recommended, and where the official objectives are published. Also ask how the current exam is delivered and what identification or technical requirements apply.
Request written confirmation when a provider uses EX447 in a catalogue. A historical course code may describe archived material rather than an available exam. The safest decision is to reconcile the provider’s statement with the current Red Hat certification page before scheduling or purchasing anything.
A practical EX447-based study roadmap
Use the roadmap as a sequence of demonstrated capabilities, not as a promise of exam coverage or a substitute for current Red Hat objectives. At every stage, keep the lab version and the historical nature of EX447 visible in your notes.
The finish line for this roadmap is a repeatable automation workflow: source-controlled playbooks target the correct systems, handle data and delegation explicitly, apply privilege intentionally, and run through controller objects with a result that can be inspected and reproduced.
Stage one: establish the baseline
Confirm that you can administer the Linux systems in the lab, create and troubleshoot ordinary Ansible playbooks, work with inventories, and explain the variables used by each task. If these foundations are uncertain, use the RH294 preparation route or comparable practical experience as the reference point identified by Red Hat.
Write down the gaps rather than compensating with copied snippets. A baseline inventory, a simple configuration playbook, and a short troubleshooting exercise will reveal whether the problem is Linux, connectivity, YAML, Ansible behavior, or environment configuration.
Stage two: master data and execution control
Practice lookups, queries, filters, plugins, templates, privilege control, task selection, delegation, and delegated fact placement. Change one condition at a time, inspect intermediate data, and verify the final system state. Repeat each exercise after resetting the lab.
Do not proceed because the syntax looks familiar. Proceed when you can explain why the value has its observed type, why the task ran on its observed host, why the fact is available where it is, and why the selected task set produced the resulting state.
Stage three: organize for maintenance
Refactor the working exercises into clear host and group variable files, use special variables for connection details where appropriate, and place the work in Git. Review diffs, remove accidental files, commit intentional changes, and test from a clean checkout.
This stage turns a one-off demonstration into maintainable automation. Ask another person—or your future self reading without context—to identify the data source, target hosts, privilege boundary, and expected result from the repository structure.
Stage four: operate through the controller
Create the relevant inventory, credentials, project, advanced inventory, job, and workflow relationships in the controller available to you. Launch a controlled job, inspect its result, then repeat the launch through the documented controller API. Record the source revision and the objects involved.
Treat an API response as the beginning of verification, not the conclusion. Follow the launched job to its output and resulting state. If the controller cannot reproduce the command-line result, isolate project content, inventory, credentials, permissions, and runtime settings one at a time.
Stage five: make a current certification decision
Once the lab work is complete, stop and reassess the objective. If you need a current credential, use the active Red Hat catalogue and official objectives to choose the next exam. If you need the knowledge itself, preserve the lab as a professional automation project and continue updating it for the product versions you actually use.
Do not describe completion of this roadmap as passing EX447 or earning its retired credential. Describe it accurately as preparation based on the former EX447 objectives or as advanced Ansible practice. That distinction protects both your certification plan and the credibility of your skills record.
Conclusion
EX447 is a useful historical reference for advanced Ansible automation, but it is not a current scheduling target: Red Hat identifies the exam and its associated credential as retired. Use its former objectives to test practical abilities in inventory design, data handling, delegation, privilege, Git, and controller workflows, then verify a current Red Hat alternative before making a purchase or booking decision. The next step is to check Red Hat’s active certification pages, establish your prerequisite baseline, and build a reproducible lab that demonstrates the work rather than memorizing unsupported exam material.
Related exams
- EX318 exam — Red Hat Certified Specialist in Virtualization exam(RH318)
- EX407 exam — Red Hat Certified Specialist in Ansible Automation exam