Ansible Q12: A custom shell script returns exit code 0 even when it fails and reports changed every time How do you fix it using register failed_when and changed_when [L1]

Third-party CLI utilities and legacy bash scripts often hide errors by returning exit code 0, or generate false 'changed' statuses that trigger unnecessary service restarts. I resolve this by capturing task execution telemetry with register and writing explicit failed_when and changed_when expressions. Step 1 (Capture Script Telemetry with register): Capture the command's stdout, stderr, and return code into a variable: - name: Run legacy database migration script; command: /opt/scripts/migrate.sh Step 2 (Override Failure Logic with failed_when): Define custom boolean conditions that mark the task as failed even when the exit code is 0: failed_when: - migration_out.rc != 0 or 'ERROR' in migration_out.stdout or 'FAILED' in migration_out.stderr; This halts execution immediately when error patterns appear in stdout, preventing silent failures. Step 3 (Refine Mutation Status with changed_when): By default, command/shell tasks always report changed: true . Override this so changes only register when work was actually performed: changed_when: "'MIGRATION_APPLIED' in migration_out.stdout; If stdout contains 'NO_CHANGES_NEEDED', the task cleanly reports green ( ok ), preventing downstream restart handlers from firing. Key Takeaway: Never rely solely on binary exit codes for custom scripts. Register task output and use failed_when to catch embedded error strings, while using changed_when to ensure only actual mutations trigger downstream handlers.

What common mistakes should candidates avoid when answering: Ansible Q12: A custom shell script returns exit code 0 even when it fails and reports changed every time How do you fix it using register failed_when and changed_when [L1]?

1. Using ignore_errors: yes instead of failed_when: ignore_errors blindly continues execution on real catastrophic errors; failed_when allows fine-grained error evaluation. 2. Leaving changed_when undefined on diagnostic shell scripts: Causes monitoring tools and CI reports to show false configuration drifts on every single run. 3. Checking for substring matching without accounting for case sensitivity: A script outputting 'error' will not match 'ERROR' unless explicitly lowercased via Jinja2 filters.

Junior / Associate DevOps [L1] Ansible Task Conditions & Error Handling Core Fundamentals [L1]

🎯 Target Role / Context: Junior / Associate DevOps Scenario #12 · Task Conditioning

Q: In an Ansible playbook, a custom CLI command returns exit code 1 for non-fatal status warnings, causing the task to fail. How do you tune failed_when and changed_when conditions?

Custom scripts frequently violate standard exit code conventions. Capture stdout and return codes using register, override failure logic using failed_when, and accurately enforce changed_when conditions to eliminate false positives.

#Ansible #failed_when #changed_when #register #Conditions

🎙️ Candidate Opening & Architectural Context

""Third-party CLI utilities and legacy bash scripts often hide errors by returning exit code 0, or generate false 'changed' statuses that trigger unnecessary service restarts. I resolve this by capturing task execution telemetry with register and writing explicit failed_when and changed_when expressions.""

⚡ Recommended Practice Lab

Want to master this scenario in a live sandbox? KodeKloud's CKA & CKAD Hands-On Certification Track covers this exact problem with hands-on terminal drills.

🛠️ Production Runbook & Step-by-Step Resolution

1️⃣

Capture Script Telemetry with register

Capture the command's stdout, stderr, and return code into a variable:

- name: Run legacy database migration script
command: /opt/scripts/migrate.sh
register: migration_out

2️⃣

Override Failure Logic with failed_when

Define custom boolean conditions that mark the task as failed even when the exit code is 0:

failed_when:
- migration_out.rc != 0 or 'ERROR' in migration_out.stdout or 'FAILED' in migration_out.stderr
This halts execution immediately when error patterns appear in stdout, preventing silent failures.

3️⃣

Refine Mutation Status with changed_when

By default, command/shell tasks always report changed: true. Override this so changes only register when work was actually performed:

changed_when: "'MIGRATION_APPLIED' in migration_out.stdout"
If stdout contains 'NO_CHANGES_NEEDED', the task cleanly reports green (ok), preventing downstream restart handlers from firing.

💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)

"Never rely solely on binary exit codes for custom scripts. Register task output and use failed_when to catch embedded error strings, while using changed_when to ensure only actual mutations trigger downstream handlers."

⚡ 60-Second Elevator Pitch Talking Points

By default, Ansible determines success purely by exit code 0 and marks all command/shell tasks as 'changed'.
Use 'register: output_var' to capture stdout, stderr, and return code in task memory.
Use 'failed_when: "'FATAL' in output_var.stdout"' to fail tasks when legacy scripts return exit code 0 on errors.
Use 'changed_when: "'UPDATED' in output_var.stdout"' to prevent false positive 'changed' status on no-op runs.
Set 'changed_when: false' on read-only status and audit commands to maintain pristine idempotency metrics.
Combine conditions with YAML lists to evaluate multiple logical expressions cleanly without complex bash regex.

⛔ Critical Candidate Mistakes to Avoid in This Scenario

Senior hiring managers and bar raisers evaluate how you prioritize during outages. Avoid these common anti-patterns:

Using ignore_errors: yes instead of failed_when ignore_errors blindly continues execution on real catastrophic errors; failed_when allows fine-grained error evaluation.
Leaving changed_when undefined on diagnostic shell scripts Causes monitoring tools and CI reports to show false configuration drifts on every single run.
Checking for substring matching without accounting for case sensitivity A script outputting 'error' will not match 'ERROR' unless explicitly lowercased via Jinja2 filters.

Q: In an Ansible playbook, a custom CLI command returns exit code 1 for non-fatal status warnings, causing the task to fail. How do you tune failed_when and changed_when conditions?

🛠️ Production Runbook & Step-by-Step Resolution

Capture Script Telemetry with register

Override Failure Logic with failed_when

Refine Mutation Status with changed_when

Get 1 DevOps interview question in your inbox every week

📚 Related Questions & Incident Scenarios

Ansible Q7: A junior engineer uses the shell module for every task in an enterprise playbook What are the security risks when should you use command vs shell and how do you enforce idempotency [L1]

Ansible Q4: Why is an Nginx restart handler not firing even though a template configuration task notified it and how do you prevent broken configurations from reloading [L2]

Ansible Q9: During a maintenance window ansible all -m ping reports UNREACHABLE for 30 out of 100 Linux servers Walk me through your step-by-step diagnostic triage runbook [L1]

Ansible Q8: Before applying a disruptive network configuration change what is the difference between syntax-check and check diff and what are the limitations of check mode [L1]

Ansible Q3: You need to rotate database credentials across 80 microservices How do you integrate Ansible Vault with automated CI/CD pipelines without exposing keys in console logs [L3]

Ansible Q15: An in-place database schema migration fails halfway through a playbook How do you use block rescue and always to implement automated rollback [L3]