Ansible ansible.platform Collection: Configuration-as-Code for AAP 2.7

Managing an Ansible Automation Platform deployment by hand — clicking through the UI to set up organizations, teams, RBAC roles, credentials, and platform settings — does not scale once you're running AAP across multiple environments or business units. At Red Hat Tech Day Netherlands 2026, held in Bunnik on 3 June 2026, the Ansible team addressed this directly by announcing 12 new content collections for AAP 2.7, organized around four themes: Efficiency, Resilience, Governance, and Scale. Among them, the ansible.platform collection stands out because it doesn't automate infrastructure outside AAP — it automates AAP itself.

This article focuses on that collection: what it's for, why it matters for teams standardizing on AAP 2.7, and how to start thinking about it in configuration-as-code terms.

What the ansible.platform Collection Delivers

According to the Red Hat Tech Day Netherlands 2026 announcement, the ansible.platform collection for AAP 2.7 is built around three pillars:

• AAP configuration-as-code — defining organizations, teams, credentials, execution environments, job templates, and platform-wide settings declaratively, instead of through manual UI configuration.
• RBAC and settings refactoring — a reworked approach to how role-based access control and platform settings are modeled and applied, aligned with AAP 2.7's platform architecture.
• Performance improvements — faster module execution against the platform's gateway and controller APIs, reducing the time it takes to converge large configuration runs.

See also: ansible.platform Collection: Configuration as Code for Ansible Automation Platform 2.7

Why Configuration-as-Code for AAP Matters

Treating your automation platform's own configuration as code closes a gap that many organizations run into as they scale AAP: the platform that manages configuration drift everywhere else becomes, itself, a source of drift. Organizations get created ad hoc, RBAC roles diverge between environments, and nobody has a clean audit trail for who changed what settings and when.

With ansible.platform, teams can express the desired state of the platform in playbooks and manage it through the same GitOps workflows used for every other piece of infrastructure — version-controlled, peer-reviewed, and reproducible across dev, staging, and production instances of AAP.

A Practical Example

The example below is illustrative of the style of tasks you'd expect from a collection with this scope — using the platform's controller and gateway APIs to enforce organizational and RBAC structure declaratively. Treat module names and parameters as representative rather than a verbatim reference until Red Hat's official collection documentation is published.

---
- name: Enforce AAP organization and RBAC baseline
  hosts: localhost
  gather_facts: false
  vars:
    aap_hostname: "https://aap.example.com"
    aap_username: "{{ lookup('env', 'AAP_ADMIN_USER') }}"
    aap_password: "{{ lookup('env', 'AAP_ADMIN_PASSWORD') }}"

  tasks:
    - name: Ensure the Platform Engineering organization exists
      ansible.platform.organization:
        name: "Platform Engineering"
        description: "Owns core AAP configuration and shared execution environments"
        state: present
        controller_host: "{{ aap_hostname }}"
        controller_username: "{{ aap_username }}"
        controller_password: "{{ aap_password }}"

    - name: Create a Automation Operators team
      ansible.platform.team:
        name: "Automation Operators"
        organization: "Platform Engineering"
        state: present
        controller_host: "{{ aap_hostname }}"
        controller_username: "{{ aap_username }}"
        controller_password: "{{ aap_password }}"

    - name: Grant the operators team Execute role on production job templates
      ansible.platform.role:
        team: "Automation Operators"
        resource_type: "job_template"
        resource_name: "Production Deploy"
        role: "Execute"
        state: present
        controller_host: "{{ aap_hostname }}"
        controller_username: "{{ aap_username }}"
        controller_password: "{{ aap_password }}"

    - name: Apply platform-wide session timeout setting
      ansible.platform.settings:
        settings:
          SESSIONS_TOKEN_EXPIRATION: 1800
        controller_host: "{{ aap_hostname }}"
        controller_username: "{{ aap_username }}"
        controller_password: "{{ aap_password }}"

This playbook shows the core pattern: declare organizations, teams, and RBAC role assignments, then push global platform settings, all idempotently, all from version control.

See also: Configuration as Code with ansible.platform Collection in AAP 2.6

How It Compares to Adjacent Collections

The 12 collections announced at Red Hat Tech Day Netherlands 2026 split cleanly across different automation domains. Here's where ansible.platform sits relative to a few others in the same announcement:

Getting Ready for AAP 2.7

Since ansible.platform was announced rather than fully documented at Red Hat Tech Day Netherlands 2026, teams preparing to adopt it should:

1. Inventory current manual configuration — document every organization, team, RBAC role, and global setting currently configured by hand in your AAP instance.
2. Establish a Git repository for platform config — even before the collection is generally available, structure your desired-state definitions (in whatever format you use today) so migrating to ansible.platform playbooks is a lift-and-shift, not a redesign.
3. Review RBAC role assignments now — the announced "RBAC/settings refactoring" suggests role modeling may shift in AAP 2.7, so a clean baseline going in will make the transition smoother.
4. Watch for execution environment implications — configuration-as-code collections typically ship as part of a supported execution environment; plan to pull the updated EE once AAP 2.7 collections are generally available.

Key Takeaways

• The ansible.platform collection, announced at Red Hat Tech Day Netherlands 2026 (Bunnik, 3 June 2026), brings configuration-as-code to AAP 2.7 itself — organizations, teams, RBAC, and platform settings.
• It's one of 12 new collections announced for AAP 2.7, spanning Efficiency, Resilience, Governance, and Scale, alongside collections like hashicorp.vault, cisco.intersight, and infra.windows_ops.
• Core focus areas are AAP configuration-as-code, RBAC/settings refactoring, and performance improvements to platform-facing modules.
• Teams should start documenting current manual AAP configuration now so it can be migrated into version-controlled playbooks once the collection ships.
• Expect ansible.platform to work best in combination with other governance-focused collections from the same announcement, such as hashicorp.vault for secrets.