Red Hat Certified Engineer EX294 EX294 Questions 526–528 | Page 8/8

526

MCQhard

An admin attempts to build an execution environment using the exhibited files. The build fails with an error about incompatible Python dependency. What is the most likely cause?

A.The Python requirements.txt tries to install a version of Ansible that conflicts with the version in the base image.

B.The execution-environment.yml file uses incorrect syntax for the 'dependencies' section.

C.The collections in requirements.yml are not fully qualified.

D.The base image 'ee-minimal-rhel8' is not a valid execution environment base image.

AnswerA

The base image already contains Ansible; specifying a version causes conflict.

Why this answer

The build fails because the Python `requirements.txt` file attempts to install a version of Ansible that conflicts with the version already present in the base image `ee-minimal-rhel8`. Execution environments are designed to include a specific Ansible version in the base image; adding a different version via pip creates a dependency conflict that breaks the build.

Exam trap

The trap here is that candidates often assume the error is due to syntax or invalid base images, but the question specifically mentions 'incompatible Python dependency,' which directly points to a version conflict in the pip requirements.

How to eliminate wrong answers

Option B is wrong because the `execution-environment.yml` file syntax for the 'dependencies' section is correct as shown in the exhibit (it uses a list of file references). Option C is wrong because collections in `requirements.yml` do not need to be fully qualified; they can be specified with just the collection name, and the build would still succeed. Option D is wrong because `ee-minimal-rhel8` is a valid Red Hat-provided execution environment base image, and the error message specifically points to a Python dependency conflict, not an invalid base image.

Full explanation →

527

Multi-Selecteasy

A systems administrator is securing Ansible automation. Which two practices help protect sensitive data in playbooks? (Choose two.)

Select 2 answers

A.Use ansible-vault to encrypt variable files.

B.Set the no_log flag on tasks that handle sensitive data.

C.Use the debug module with verbosity to output passwords.

D.Avoid using become: yes on tasks that access secrets.

E.Store credentials in plain text in the inventory.

AnswersA, B

Encrypts sensitive variables at rest.

Why this answer

Option A is correct because `ansible-vault` encrypts variable files at rest using AES-256, allowing sensitive data like passwords or API keys to be stored securely in version control. When a playbook runs, the vault password must be provided (e.g., via `--ask-vault-pass` or a vault password file), and Ansible decrypts the file in memory only, never writing plaintext to disk. This ensures that sensitive values are not exposed in the playbook source code or logs.

Exam trap

The trap here is that candidates often confuse `no_log` with encryption, thinking it protects data at rest, when it only prevents output from being displayed in logs, while `ansible-vault` provides actual file-level encryption.

Full explanation →

528

MCQeasy

A playbook uses `{{ my_var | default('fallback') }}`. What is the effect?

A.If `my_var` is defined but empty, the expression evaluates to 'fallback'.

B.If `my_var` is defined but equal to None, the expression evaluates to 'fallback'.

C.The filter raises an error because 'default' is not a valid filter.

D.If `my_var` is undefined, the expression evaluates to 'fallback'.

AnswerD

Correct; default filter provides a fallback for undefined variables.

Why this answer

Option D is correct because the `default` filter in Ansible (also known as `d()`) returns the specified fallback value only when the variable is undefined. If `my_var` is defined but empty or None, the filter returns the variable's value (empty string or None), not the fallback. This behavior is specific to the `default` filter's default mode; to also catch empty or None values, you must use `default('fallback', true)`.

Exam trap

The trap here is that candidates often confuse 'undefined' with 'falsy' (empty, None, 0), assuming the default filter replaces all falsy values, but Ansible's default filter only triggers on undefined variables unless the `true` parameter is explicitly added.

How to eliminate wrong answers

Option A is wrong because if `my_var` is defined but empty, the `default` filter without the `true` parameter returns the empty string, not 'fallback'. Option B is wrong because if `my_var` is defined and equal to None, the filter returns None (since None is a defined value), not 'fallback'. Option C is wrong because `default` is a valid Jinja2 filter that Ansible inherits; it does not raise an error.

Full explanation →

Red Hat Certified Engineer EX294 (EX294) — Questions 526–528