Ansible / Advanced: orchestration, platforms, tests, and diagnosis / Lesson 16

Design platform and privilege contracts

Separate POSIX, Windows, network-device, and API execution requirements while keeping connection and privilege choices explicit.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain platform-specific module and transport requirements.
Distinguish login identity from become identity and method.
Validate a support matrix without contacting platforms.

One playbook language does not imply one target runtime

Ansible uses a common orchestration language across platforms, but modules, transports, interpreters, privilege mechanisms, and configuration semantics differ. A POSIX file path, Windows service, network device resource, and cloud API object are not interchangeable targets. Read the module’s platform and connection support rather than inferring it from an attractive generic name. A portable role should either adapt through a reviewed platform interface or reject unsupported platforms clearly. Do not let a missing module or fact silently select a fallback shell command that runs with broader privilege than the original design.

Execution location determines dependency and credential scope

Traditional POSIX modules often execute using a managed-node interpreter through a connection such as SSH. Windows commonly uses its documented management transports and platform modules, with support dependent on the selected release. Network automation often runs module logic on the controller and communicates through platform connections or APIs. Therefore controller libraries, target runtime, and device credentials require separate inventories. A command that works in an interactive login may fail under automation because the shell, environment, authentication delegation, or privilege context differs. No transport is opened or configured in this course.

Privilege escalation is an explicit execution capability

become uses the platform’s supported escalation mechanism to act as another identity. Setting become_user alone does not automatically enable become. The login account, escalation method, destination identity, and applicable policy must be reviewed together. More privilege is not a generic fix for a missing path, wrong variable, or unsupported module. Scope escalation narrowly to required tasks and keep credentials out of inventory and logs. Different connection plugins and platforms impose limitations, including temporary-file and identity-transition behavior, so a successful method on one platform is not a universal cross-platform recipe.

Represent privilege intent without exercising it

The illustrative task below declares an account and escalation flag for a fictional lab target. It is intentionally non-runnable, and its harmless command text does not authorize using the same pattern on a configured host. A real project should state why that identity is needed and verify both permitted and denied actions on an isolated target. Module-specific privilege behavior can differ from a generic command. YAML parsing confirms only the mapping structure, not that the account exists, the escalation method is supported, or the policy permits it.

yaml Non-runnable scoped become illustration

- name: Illustrate scoped privilege intent
  hosts: lab_posix
  gather_facts: false
  tasks:
    - name: Describe a fictional service identity
      ansible.builtin.command:
        argv:
          - /usr/bin/printf
          - '%s\n'
          - Synthetic identity review
      become: true
      become_user: lab_service
      changed_when: false

No account lookup, connection, escalation, command, or target operation was executed. The fictional identity and command are design data only.

Test a declared support matrix before effects

A small offline matrix can expose a deliberately unsupported platform/module combination before any execution is considered. It cannot discover actual module capabilities or prove a real platform version is supported. Source the real matrix from engine, collection, platform, and module documentation and retain the reviewed versions. Include interpreter or PowerShell requirements where relevant without assuming one release’s matrix lasts forever. Test unsupported input as a clear preflight rejection, not as a late remote failure after partial changes. Keep all such platform validation separate from credentials and actual host access.

python Reject a declared incompatible fixture combination

supported = {'posix': {'file', 'template'}, 'windows': {'win_file', 'win_template'}}
requested = ('windows', 'file')
print('synthetic_supported=' + str(requested[1] in supported[requested[0]]))
print('platform_probe=not-performed')

Expected output

synthetic_supported=False
platform_probe=not-performed

The simplified names are model labels, not a module resolver. The output checks the declared table only and does not probe Windows, POSIX, or any endpoint.

Common errors and fixes

become_user is assumed to enable escalation

Why it happens: Destination identity and enabling flag were conflated.
How to fix it: Review become, method, identity, and policy explicitly.
Prevent it next time: Test privilege contracts on each supported platform.

A POSIX module is assumed to work on every target

Why it happens: Shared playbook syntax was confused with module portability.
How to fix it: Use platform-supported modules or reject the target.
Prevent it next time: Maintain module and runtime support matrices.

More privilege is used to hide an unrelated defect

Why it happens: The actual path, type, or compatibility cause was not diagnosed.
How to fix it: Identify the failed operation before changing authority.
Prevent it next time: Require a justification for every escalated task.

Check your understanding

1. Why can a network-device module require controller libraries rather than Python on the device?

Show worked solution

Its module logic can execute on the controller and communicate through a platform transport or API. Dependency and credential scope follow that design, so inspect the specific collection and connection documentation rather than assuming POSIX-style remote execution.

2. What should an unsupported platform test prove?