Red Hat Certified Ansible (EX294-style) Practice Exam

What the Red Hat Certified Ansible (EX294-style) exam covers

• Ansible Fundamentals154 questions
• Inventory161 questions
• Playbooks and Tasks208 questions
• Variables and Templates159 questions
• Roles and Reuse120 questions

Free Red Hat Certified Ansible (EX294-style) practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 802.

1. Question 1Ansible Fundamentals

   How does Ansible connect to managed Linux nodes by default (agentless)?

   • AOver SSHCorrect
   • BBy installing a permanent agent on each node
   • CVia DNS only
   • DVia DHCP
   ✓ Correct answer: A

   Ansible drives Linux nodes over plain SSH, which is what makes it agentless: the managed host needs an SSH daemon and a Python interpreter, both of which are already present on a standard install, and nothing has to be deployed or kept running for Ansible's benefit. Modules are copied over, executed, and cleaned up per task. Windows hosts use WinRM for the same reason - it is the transport the OS already exposes.

   Why the other options are wrong

   • BBy installing a permanent agent on each node is incorrect because Agent-based approaches contradict Ansible's agentless architecture that uses SSH/WinRM.
   • CVia DNS only is incorrect because DNS is a name resolution service and does not provide the automation or management capabilities.
   • DVia DHCP is incorrect because DHCP provides dynamic IP assignment and has no relation to Ansible automation.
2. Question 2Roles and Reuse

   A role is imported in many plays, re-parsing all its tasks each time even when only sometimes needed. Which include style defers loading until runtime so unused branches cost nothing?

   • Aimport_role (static, always parsed)
   • Bmeta: end_play
   • Croles: at play top, always
   • Dinclude_role (dynamic inclusion)Correct
   ✓ Correct answer: D

   import_role is static: Ansible parses and inserts its tasks when the playbook is first read, so the cost is paid regardless of whether a branch runs. include_role is dynamic, resolved during execution, so a role behind a conditional is only loaded when that branch is actually reached.

   Why the other options are wrong

   • Aimport_role (static, always parsed) is incorrect because this does not provide the specific technical capability required by the question.
   • Bmeta: end_play is incorrect because this does not provide the specific technical capability required by the question.
   • Croles: at play top, always is incorrect because this does not provide the specific technical capability required by the question.
3. Question 3Inventory

   When using a YAML inventory plugin, why might 'ansible-inventory --list' show a host you expected to be excluded by a 'keyed_groups' or 'compose' rule?

   • Akeyed_groups and compose only create groups or set variables; they never filter hosts, so add a 'filters' rule to exclude themCorrect
   • Bkeyed_groups silently disables the whole inventory plugin, so none of its hosts appear anywhere in the run
   • Ccompose always deletes any host whose composed variable expression does not evaluate to a truthy match
   • Dansible-inventory ignores all plugin configuration entirely and falls back to reading a static INI inventory file on disk instead
   ✓ Correct answer: A

   YAML is the human-readable markup format used for Ansible playbooks and configuration files. YAML format provides a clean, human-readable structure that enables infrastructure-as-code practices. The declarative nature allows operators to specify desired state rather than imperative steps.

   Why the other options are wrong

   • Bkeyed_groups creates groups; it does not disable the plugin.
   • Ccompose sets variables and does not delete non-matching hosts.
   • Dansible-inventory does honor plugin configuration when listing hosts.
4. Question 4Ansible Fundamentals

   A task using the apt module fails with 'You need to be root to perform this command' even though SSH login works. What is missing?

   • APrivilege escalation with become: true (and a usable become method like sudo)Correct
   • BA dynamic inventory plugin to refresh the host's group membership
   • CA second SSH key added to the automation user's authorized_keys
   • Dgather_facts: true so root-level facts are collected first
   ✓ Correct answer: A

   Ansible uses SSH as the default transport protocol for agentless Linux node management, eliminating the need for persistent agents.

   Why the other options are wrong

   • BA dynamic inventory plugin manages the host list, not privilege escalation for apt.
   • CAn additional SSH key changes authentication, not whether the task runs as root.
   • DGathering facts does not grant root privileges needed by the apt module.
5. Question 5Ansible Fundamentals

   In an INI-format inventory, you need to define a 'webservers' group containing three hosts. Which snippet is syntactically correct?

   • A[webservers]\nweb1.example.com\nweb2.example.com\nweb3.example.comCorrect
   • Bwebservers:\n - web1.example.com\n - web2.example.com
   • Cgroup webservers { web1.example.com; web2.example.com; }
   • D<webservers>web1.example.com,web2.example.com</webservers>
   ✓ Correct answer: A

   INI inventory uses a bracketed group header followed by one host per line, so [webservers] with web1, web2, and web3 beneath it defines that group. The YAML list, brace-block, and XML forms are not valid INI inventory syntax and would be parsed as hostnames or rejected.

   Why the other options are wrong

   • Bwebservers:\n - web1.example.com\n - web2.example.com is incorrect because this does not provide the specific technical capability required by the question.
   • Cgroup webservers { web1.example.com; web2.example.com; } is incorrect because this does not provide the specific technical capability required by the question.
   • D<webservers>web1.example.com,web2.example.com</webservers> is incorrect because this does not provide the specific technical capability required by the question.
6. Question 6Inventory

   You expected web01..web09 from the inventory but the current line 'web[1:9]' produced web1..web9 without padding. How do you force two-digit zero padding in the range?

   • AWrite the start value with the desired padding: web[01:09]Correct
   • BAdd a step value: web[1:9:01]
   • CSet ansible_zero_pad=true in group_vars
   • DQuote the range: 'web[1:9]'
   ✓ Correct answer: A

   Zero-padding in an inventory range is driven by how you write the starting number. Writing web[01:09] tells Ansible to keep two-digit width across the sequence, producing web01 through web09. There is no separate padding toggle to set.

   Why the other options are wrong

   • BAdd a step value: web[1:9:01] is incorrect because this does not provide the specific technical capability required by the question.
   • CSet ansible_zero_pad=true in group_vars is incorrect because this does not provide the specific technical capability required by the question.
   • DQuote the range: 'web[1:9]' is incorrect because this does not provide the specific technical capability required by the question.
7. Question 7Playbooks and Tasks

   What is the correct module and parameter to ensure a file /etc/motd is absent (deleted) from the host?

   • Aansible.builtin.file: path=/etc/motd state=absentCorrect
   • Bansible.builtin.copy: dest=/etc/motd state=absent
   • Cansible.builtin.file: path=/etc/motd state=deleted
   • Dansible.builtin.command: rm -f /etc/motd
   ✓ Correct answer: A

   Modules are reusable Ansible components that perform specific tasks like package management, service control, or file operations. Modules are purpose-built components that abstract away implementation details and provide idempotent interfaces. They enable consistent task execution across different operating systems.

   Why the other options are wrong

   • Bansible.builtin.copy: dest=/etc/motd state=absent is incorrect because this does not provide the specific technical capability required by the question.
   • Cansible.builtin.file: path=/etc/motd state=deleted is incorrect because this does not provide the specific technical capability required by the question.
   • Dansible.builtin.command: rm -f /etc/motd is incorrect because this does not provide the specific technical capability required by the question.
8. Question 8Variables and Templates

   After 'gather_facts: true', which fact key reliably holds the operating system family (for example 'RedHat' or 'Debian') so you can branch on package managers?

   • Aansible_facts['os_family']Correct
   • Bansible_facts['distribution_release']
   • Cansible_facts['kernel']
   • Dansible_facts['architecture']
   ✓ Correct answer: A

   ansible_facts['os_family'] groups distributions by their lineage, returning values like RedHat or Debian, which is exactly the axis you branch on to pick dnf versus apt. distribution_release, kernel and architecture describe finer details, not the package-manager family.

   Why the other options are wrong

   • Bansible_facts['distribution_release'] is incorrect because this does not provide the specific technical capability required by the question.
   • Cansible_facts['kernel'] is incorrect because this does not provide the specific technical capability required by the question.
   • Dansible_facts['architecture'] is incorrect because this does not provide the specific technical capability required by the question.
9. Question 9Roles and Reuse

   A teammate placed custom module 'check_widget.py' so a role can ship its own module alongside its tasks. Which standard role subdirectory should hold that custom module so the role's tasks can call it without extra configuration?

   • Alibrary/Correct
   • Bfiles/
   • Ctemplates/
   • Dmodule_defaults/
   ✓ Correct answer: A

   Modules are reusable Ansible components that perform specific tasks like package management, service control, or file operations. Modules are purpose-built components that abstract away implementation details and provide idempotent interfaces. They enable consistent task execution across different operating systems.

   Why the other options are wrong

   • Bfiles/ is incorrect because this does not provide the specific technical capability required by the question.
   • Ctemplates/ is incorrect because this does not provide the specific technical capability required by the question.
   • Dmodule_defaults/ is incorrect because this does not provide the specific technical capability required by the question.
10. Question 10Ansible Fundamentals

    A cloud team wants inventory to be generated automatically from AWS EC2 tags so newly launched instances appear without manual edits. Which mechanism is the correct, modern way to achieve this in Ansible?

    • AConfigure the amazon.aws.aws_ec2 inventory plugin via a '*.aws_ec2.yml' inventory source file.Correct
    • BWrite the new instances into /etc/ansible/hosts manually after each launch.
    • CSet 'dynamic = true' in the [defaults] section of ansible.cfg.
    • DUse the 'gather_facts' module to discover EC2 instances at play start.
    ✓ Correct answer: A

    Modern dynamic inventory uses inventory plugins (the successor to the old inventory scripts), enabled by pointing '-i' or ansible.cfg at a configuration file named with a recognized suffix such as 'something.aws_ec2.yml' and naming the plugin inside it. The aws_ec2 plugin queries the AWS API, can build groups from tags via 'keyed_groups', and refreshes membership on each run so new instances appear automatically. You can also enable inventory plugins through the 'enable_plugins' setting. This avoids any manual host file maintenance.

    Why the other options are wrong

    • BManual edits to /etc/ansible/hosts defeat the entire purpose of dynamic inventory and do not scale with autoscaling instances.
    • CThere is no 'dynamic = true' switch in ansible.cfg; dynamic behavior comes from inventory plugins/scripts, not a boolean flag.
    • Dgather_facts collects facts from already-known hosts over SSH; it cannot discover or enumerate cloud instances to build inventory.

Who this Red Hat Certified Ansible (EX294-style) practice exam is for

This practice set is for anyone preparing for the Red Hat Certified Ansible (EX294-style) exam - from first-time candidates building a foundation to experienced Linux practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this Red Hat Certified Ansible (EX294-style) practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Treat your readiness score as knowledge readiness, then validate it with hands-on practice in a real environment before booking the Red Hat Certified Ansible (EX294-style) exam.

Related Linux resources

• Red Hat Certified Ansible (EX294-style) study guideKey concepts
• Linux practice examsAll Linux
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• Hands-on ansible labsLearn
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• Red Hat Certified System Administrator (RHCSA, EX200-style) practice examRelated
• CompTIA Linux+ (XK0-006) practice examRelated
• Linux Foundation Certified System Administrator (LFCS) practice examRelated

Red Hat Certified Ansible (EX294-style) practice exam FAQ