🧪Module 11 — Testing, Molecule & CI/CD

In layers, cheapest first. yamllint for YAML validity. --syntax-check so Ansible can parse it. ansible-lint for design quality — unnamed tasks, missing FQCN, shell where a module exists. --check --diff against a real host to see what would change. Molecule to run it for real in a container and verify idempotency. Then a staging run.

The important distinction: only Molecule proves idempotency, because that requires actually running twice against something real.

It only proves the YAML parses and the structure is valid Ansible. It says nothing about whether the tasks are correct, idempotent, or safe — a playbook full of shell commands with no names passes --syntax-check perfectly.

It is the cheapest gate and belongs first in a pipeline, not the only one.

WARNING  Listing 9 violation(s) that are fatal

name[play]: All plays should be named.
bad.yml:2

fqcn[action-core]: Use FQCN for builtin module actions (shell).
bad.yml:4 Use `ansible.builtin.shell` instead.

name[missing]: All tasks should be named.
bad.yml:4 Task/Handler: shell systemctl restart nginx

command-instead-of-module: systemctl used in place of service module
bad.yml:4

no-changed-when: Commands should not change things if nothing needs doing.
bad.yml:4

risky-octal: Use quotes for octal permissions.
bad.yml:9 mode: 0644 -> mode: "0644"

no-log-password: Password should have no_log configured.
bad.yml:11

ignore-errors: Use failed_when and specify error conditions instead of using
ignore_errors.
bad.yml:17

Rule Violation Summary
 count tag                        profile   rule associated tags
     1 command-instead-of-module  basic     command-shell, idiom
     1 ignore-errors              basic     unpredictability
     1 no-changed-when            shared    command-shell, idempotency
     1 no-log-password            production security
     2 name[missing]              basic     idiom
     ...

Eight distinct problems in twelve lines of YAML — and every one of them was warned about earlier in this course. The shell: systemctl restart nginx line alone triggered four rules: no name, no FQCN, a command where a module exists, and no changed_when.

Read the summary table's profile column. It tells you which profile each rule belongs to, so you can see exactly what raising your profile one step would newly enforce. no-log-password is production — which is why a team on moderate would not catch a leaking password until they raise the bar.

Now run ansible-lint bad.yml --fix and diff the file. It safely fixes the mechanical ones — FQCNs, octal quoting — and correctly leaves the judgement calls (ignore_errors, no_log) to you.

Design and safety problems rather than parse errors: unnamed tasks and plays, short module names instead of FQCN, unquoted octal file modes, shell/command where a real module exists, command tasks with no changed_when, passwords without no_log, blanket ignore_errors, invalid variable names, Jinja spacing.

Essentially it encodes the community's accumulated production experience — a playbook can be perfectly valid YAML and perfectly parseable while being full of these.

Incrementally, using profiles. Start at min, gate CI on it so nothing gets worse, then raise one profile step at a time — basic, moderate, safety, production — cleaning up as you go.

Turning on --profile production immediately produces a thousand-issue report nobody reads and a rule everyone disables. The profile ladder exists precisely for this.

Inline # noqa: rule-name on the specific task, with a comment explaining why — scoped, reviewable, and visible in a diff.

Avoid a global skip_list entry, which disables the rule everywhere permanently and quietly removes a safety check that nobody revisits.

They tell ansible-lint that a role or module exists even though it is not installed in the linting environment — so it does not report "couldn't resolve module/action" for your own collection's content or for roles installed only at deploy time.

Without them, CI linting fails on perfectly valid references to content that is installed later in the pipeline.

INFO     Running default > converge
TASK [Ensure the marker directory exists] ****   changed: [ubuntu2204]
TASK [BROKEN - appends every run] ************   changed: [ubuntu2204]

INFO     Running default > idempotence
TASK [Ensure the marker directory exists] ****   ok: [ubuntu2204]
TASK [BROKEN - appends every run] ************   changed: [ubuntu2204]

CRITICAL Idempotence test failed because of the following tasks:
* [ubuntu2204] => demo : BROKEN - appends every run

Molecule named the exact task. Not "something changed" — the specific task that was not idempotent, on the specific platform. That is the whole value: this bug is invisible to linting, invisible to --syntax-check, and invisible to a single run.

Note the first task passed. file: state: directory reported changed on run one and ok on run two, because it inspects state first — the Module 01 Part C3 lesson, now verified automatically.

Two ways to fix it:

# A - a marker, so it runs once
- name: Write the marker once
  ansible.builtin.shell: echo "installed at $(date)" > /opt/demo/log.txt
  args:
    creates: /opt/demo/log.txt

# B - declare the content, which is better
- name: Manage the marker file
  ansible.builtin.copy:
    content: "demo marker\n"
    dest: /opt/demo/log.txt
    mode: "0644"

Re-run molecule test and the idempotence step passes.

This is the exercise to remember for interviews. "How do you know your role is idempotent?" — "Molecule's idempotence step runs it twice and fails the build on any change, naming the offending task. It runs on every commit."

A testing framework for roles and collections. It runs a lifecycle: create a container or VM, optionally prepare it, converge (apply the role), idempotence (apply it again and fail on any change), verify (assert the end state), destroy.

The idempotence step is unique — no linter, no --syntax-check and no --check run can prove idempotency, because it requires actually applying the role twice to something real. That single step catches every idempotency trap: unsalted password_hash, unsorted dictionary iteration, timestamps in generated files, bare shell tasks.

Observable end state, not task results. The service is running and enabled, the config file exists with the right mode and owner, and the port actually answers a request.

converge already told you whether tasks succeeded. A role can go entirely green and still leave a service that does not serve traffic — testing behaviour rather than task outcomes is what makes the suite worth having.

The container almost certainly has no init system — a stock ubuntu:22.04 image runs bash as PID 1, so systemd is not there and service: state: started cannot work.

Use an image that runs systemd, such as the geerlingguy/docker-*-ansible family, with command: /lib/systemd/systemd, privileged: true, cgroupns_mode: host and the cgroup volume mount. The role is fine; the test environment was wrong.

converge creates the container and applies the role, then leaves it running — so you can molecule login and inspect what actually happened. That is the development loop: converge, login, fix, converge.

molecule test runs the whole lifecycle including destroy. It is what CI runs and what you use when you believe it already works. Using it as a development loop means recreating the container on every iteration for no reason.

To test the combinations it supports. default for the happy path, tls to prove a feature flag genuinely changes behaviour, upgrade to converge an old version then the new one and prove a version bump does not destroy existing data.

That last one is the case real deployments break on and almost nobody tests.

yamllint.................................................................Failed
- hook id: yamllint
- exit code: 1

site.yml
  12:81     warning  line too long (94 > 80 characters)  (line-length)
  18:1      error    trailing spaces  (trailing-spaces)

ansible-lint.............................................................Failed
- hook id: ansible-lint

name[missing]: All tasks should be named.
site.yml:8

Detect Private Key.......................................................Passed
Fix End of Files.........................................................Fixed
Trim Trailing Whitespace.................................................Fixed

Two of those hooks fixed the files in place and staged nothing — so git commit aborts, you review the changes, git add and commit again. That is intentional: the hook never silently rewrites what you are committing.

detect-private-key is the one worth having regardless of everything else. It catches an SSH private key or a PEM file heading into version control — which, per Module 07, is not fixable by deleting it later, because the history retains it and the credential must be rotated.

Why pre-commit and not just CI? Both. Pre-commit gives feedback in two seconds instead of two minutes and keeps trivially broken commits out of the branch. CI is the gate that cannot be skipped, since git commit --no-verify bypasses hooks. Pre-commit is convenience; CI is enforcement.

Staged, cheapest first. Lint: yamllint, ansible-lint at an agreed profile, --syntax-check on playbooks and ansible-inventory --graph on inventories. Test: Molecule per role, in a parallel matrix, which proves the roles work and are idempotent. Pre-deploy: --check --diff against staging so the diff is visible in the job log. Deploy: a manual gate, main only, with the vault password from the platform's secret store written to a 0600 temp file and shredded afterwards.

For configuration management, no. Application deployment can roll back on a failed health check; a bad playbook reconfigures 500 servers and keeps going.

Use a manual approval gate on production, with --check --diff against staging having run automatically, and combine it with serial plus max_fail_percentage: 0 so even an approved run halts on the first failure.

Both, for different jobs. Pre-commit gives feedback in seconds and keeps trivially broken commits out of the branch — but git commit --no-verify bypasses it, so it cannot be the gate.

CI is enforcement. Pre-commit is convenience. The one hook worth having regardless is detect-private-key, because a committed credential is not fixable by deletion — the history keeps it and the key must be rotated.

From the platform's secret store as a masked variable, written to a 0600 temporary file, passed with --vault-password-file, and shredded in an after_script that runs even on failure.

Never as a command-line argument — it appears in the process list and often in job logs. Better still, a vault password client script that fetches it from AWS Secrets Manager or HashiCorp Vault at run time, so nothing is written to disk at all.

# roles/webserver/molecule/default/molecule.yml   -- requirements 2, 3
---
dependency:
  name: galaxy
  options:
    requirements-file: ../../../../requirements.yml

driver:
  name: docker

platforms:
  - name: ubuntu2204
    image: geerlingguy/docker-ubuntu2204-ansible:latest
    pre_build_image: true
    command: /lib/systemd/systemd        # requirement 3 - real init system
    cgroupns_mode: host
    privileged: true
    volumes: ["/sys/fs/cgroup:/sys/fs/cgroup:rw"]

  - name: rocky9
    image: geerlingguy/docker-rockylinux9-ansible:latest
    pre_build_image: true
    command: /usr/sbin/init
    cgroupns_mode: host
    privileged: true
    volumes: ["/sys/fs/cgroup:/sys/fs/cgroup:rw"]

provisioner:
  name: ansible
  config_options:
    defaults:
      interpreter_python: auto_silent

verifier:
  name: ansible

# roles/webserver/molecule/default/verify.yml     -- requirement 4
---
- name: Verify
  hosts: all
  become: true
  gather_facts: true
  tasks:
    - ansible.builtin.service_facts:

    - name: Service must be running and enabled
      ansible.builtin.assert:
        that:
          - ansible_facts.services['nginx.service'].state == 'running'
          - ansible_facts.services['nginx.service'].status == 'enabled'

    - name: Config must exist with correct ownership
      ansible.builtin.stat:
        path: /etc/nginx/nginx.conf
      register: cfg

    - ansible.builtin.assert:
        that:
          - cfg.stat.exists
          - cfg.stat.mode == '0644'
          - cfg.stat.pw_name == 'root'

    - name: It must ACTUALLY answer on the port      # requirement 4
      ansible.builtin.uri:
        url: "http://localhost:{{ webserver_port | default(80) }}/"
        status_code: 200

# .ansible-lint   -- requirement 1
---
profile: moderate                 # not 'production' on a legacy repo
exclude_paths: [collections/, galaxy_roles/, .venv/]
skip_list: [yaml[line-length]]    # yamllint owns line length, with our limit
warn_list: [experimental]

# .gitlab-ci.yml   -- requirements 1, 5, 6, 7
---
stages: [lint, test, deploy]

.base: &base
  image: python:3.11
  before_script:
    - pip install -q ansible-core ansible-lint yamllint
    - ansible-galaxy install -r requirements.yml

lint:
  stage: lint
  <<: *base
  script:                                   # requirement 1 - fail fast, cheapest first
    - yamllint .
    - ansible-lint --profile moderate
    - ansible-playbook playbooks/site.yml --syntax-check
    - ansible-inventory -i inventories/staging --graph

molecule:
  stage: test
  image: python:3.11
  services: [docker:dind]
  variables: {DOCKER_HOST: "tcp://docker:2375"}
  before_script:
    - pip install -q "molecule-plugins[docker]" molecule ansible-core ansible-lint
  script: [cd roles/$ROLE && molecule test]
  parallel:                                 # requirement 5
    matrix:
      - ROLE: [webserver, monitoring, common]

check-staging:
  stage: test
  <<: *base
  script:                                   # requirements 6, 7
    - echo "$VAULT_PASSWORD" > /tmp/.vpass && chmod 600 /tmp/.vpass
    - ansible-playbook -i inventories/staging playbooks/site.yml
        --check --diff --vault-password-file /tmp/.vpass
  after_script:
    - shred -u /tmp/.vpass || rm -f /tmp/.vpass

deploy-production:
  stage: deploy
  <<: *base
  when: manual                              # requirement 6 - a human clicks
  only: [main]
  environment: production
  script:
    - echo "$VAULT_PASSWORD" > /tmp/.vpass && chmod 600 /tmp/.vpass
    - ansible-playbook -i inventories/production playbooks/site.yml
        --vault-password-file /tmp/.vpass
  after_script:
    - shred -u /tmp/.vpass || rm -f /tmp/.vpass

The seven decisions:

1. profile: moderate, not production — requirement 1 explicitly said a level a legacy repo can pass. Starting too strict is how linting gets disabled.
2. systemd images with privileged and the cgroup mount — requirement 3. Without them service: state: started fails and you debug a role that is fine.
3. Two platforms in one scenario — requirement 2. Molecule runs the converge and idempotence steps against both, so a Debian-only assumption surfaces immediately.
4. The uri assertion in verify — requirement 4, and the one that matters. Everything above it checks that Ansible did what it said; only this checks that the outcome is real.
5. parallel: matrix in GitLab (or fail-fast: false in GitHub Actions) — requirement 5.
6. when: manual plus only: [main] — requirement 6. Staging's --check --diff runs automatically in the same stage, so the diff is in the log before anyone approves.
7. Password to a 0600 file, shred in after_script — requirement 7. after_script runs even when the job fails, which a trailing line in script: would not.

Verify locally before pushing:

yamllint . && ansible-lint --profile moderate
cd roles/webserver && molecule test
cd - && ansible-playbook -i inventories/staging playbooks/site.yml --check --diff

yamllint → --syntax-check → ansible-lint → --check --diff → Molecule → staging run.

Gate CI on each so a YAML error fails in seconds rather than after a five-minute Molecule run.

Idempotency. Its idempotence step applies the role a second time and fails the build if any task reports changed, naming the offending task.

No linter, no --syntax-check and no --check run can establish that, because it requires actually applying the role twice to something real.

By profile. Start at min, gate CI so nothing gets worse, then raise one step at a time — basic, moderate, safety, production — cleaning up as you go.

Enabling production immediately produces a report nobody reads and a tool everyone disables.

Inline # noqa: rule-name with a comment explaining why — scoped to the one justified place, reviewable, and visible in a diff.

A global skip_list entry disables the rule everywhere forever and quietly removes a safety check nobody revisits.

The container has no init system — a stock image runs bash as PID 1. Use a systemd-capable image such as geerlingguy/docker-*-ansible, with command: /lib/systemd/systemd, privileged: true, cgroupns_mode: host and the cgroup volume mount.

The role is fine; the test environment was wrong.

Observable end state — the service is running and enabled, the file has the right mode and owner, and the port actually answers a request.

Not task results: converge already reported those, and a role can go entirely green while leaving a service that does not serve traffic.

converge applies the role and leaves the container running, so you can molecule login and inspect — that is the development loop.

molecule test runs the whole lifecycle including destroy; it is what CI runs and what you use when you believe it already works.

For configuration management, no. An application deploy can fail a health check and roll back; a bad playbook reconfigures 500 servers and keeps going.

Manual gate on production, main only, with --check --diff against staging having run automatically — combined with serial and max_fail_percentage: 0 so even an approved run halts on the first failure.

Both — pre-commit for two-second feedback, CI for enforcement, because git commit --no-verify bypasses hooks.

The non-negotiable hook is detect-private-key: a committed credential cannot be fixed by deletion, since the history retains it and the key must be rotated.

From the platform's masked secret store, written to a 0600 temp file, passed with --vault-password-file, and shredded in an after_script that runs even on failure.

Never as a command-line argument — it lands in the process list and often the job log. Better still, a client script fetching it at run time so nothing touches disk.

By default one role's failure cancels the others, so you fix one bug, push, and discover the next. With it disabled you get every role's result from a single run, turning a multi-round debugging cycle into one.

Behaviour verified against the current ansible-lint and Molecule documentation.

Question selection cross-referenced against publicly published 2026 Ansible interview question sets:

• Spacelift — 50+ Top Ansible Interview Questions & Answers for 2026
• GeeksforGeeks — Top 50+ Ansible Interview Questions and Answers
• Vinsys — Top 30 Ansible Interview Questions and Answers 2026
• K21 Academy — Ansible Interview Questions & Answers 2026
• Hirist — Top 25+ Ansible Interview Questions and Answers 2026

Answers were rewritten and deepened rather than reproduced — published versions are usually correct but shallow, and the added operational detail is what differentiates a candidate in the room.