Build an AAP Self-Service Template: Request an Azure Resource Group

Why Self-Service Azure Provisioning Matters

At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed one of the headline features of Ansible Automation Platform 2.7: the new Automation Portal. Instead of asking requesters to know which job template to run, which survey fields to fill in, or where a playbook even lives, the Automation Portal presents a curated gallery of self-service templates. Each entry has a single "Start" button. Click it, answer a short form, and the automation runs — no knowledge of AAP's internals required.

Among the templates shown in the live demo catalog was Cloud - Request Azure Resource Group, which provisions an Azure Resource Group with appropriate RBAC applied automatically. This article walks through what that template represents, how it fits alongside the other catalog entries, and how you would build an equivalent job template behind it.

See also: Build an AAP Self-Service Template: Create a Compliant S3 Bucket

What the Demo Catalog Looked Like

The Bunnik demo catalog mixed branch operations, network tasks, cloud provisioning, and patching into a single self-service experience. Seeing the full list makes it clear why a dedicated Azure Resource Group template earns its place — cloud infrastructure requests are exactly the kind of task that benefits from guardrails and a form-based front end rather than direct console or CLI access.

Anatomy of the "Cloud - Request Azure Resource Group" Template

Behind the Automation Portal's Start button sits a standard AAP job template — the same building block AAP has always used, now exposed through a friendlier front end. To reproduce something equivalent, you need four pieces:

1. A project pointing at the Git repository containing the Azure RG playbook.
2. A credential of type Microsoft Azure Resource Manager, scoped to the subscription(s) the template is allowed to touch.
3. A survey collecting the requester's inputs — resource group name, region, environment tag, and the Azure AD group that should receive access.
4. A job template tying the project, credential, and survey together, with RBAC on the template itself controlling who can even see it in the catalog.

---
- name: Request Azure Resource Group (self-service)
  hosts: localhost
  gather_facts: false
  vars:
    rg_name: "{{ resource_group_name }}"
    rg_location: "{{ azure_region }}"
    environment_tag: "{{ environment | default('dev') }}"
    requester_group_object_id: "{{ aad_group_object_id }}"

  tasks:
    - name: Create the Azure Resource Group
      azure.azcollection.azure_rm_resourcegroup:
        name: "{{ rg_name }}"
        location: "{{ rg_location }}"
        tags:
          environment: "{{ environment_tag }}"
          requested_by: "{{ tower_user_name | default('automation-portal') }}"
          managed_by: ansible-automation-platform
      register: rg_result

    - name: Assign Contributor role to the requesting team's AAD group
      azure.azcollection.azure_rm_roleassignment:
        scope: "{{ rg_result.state.id }}"
        assignee_object_id: "{{ requester_group_object_id }}"
        role_definition_id: "Contributor"

    - name: Report the new resource group back to the requester
      ansible.builtin.debug:
        msg: >-
          Resource group {{ rg_name }} created in {{ rg_location }}
          with Contributor access granted to group {{ requester_group_object_id }}.

The important design choice is that the requester never supplies a role definition or a subscription ID directly — those are fixed by the template's defaults or restricted via survey choices, which is what keeps "appropriate RBAC" appropriate rather than accidental.

See also: Build an AAP Self-Service Template: Provision an AWS EC2 Instance

Building the Survey That Powers Self-Service

The Automation Portal's simplicity for the end user comes entirely from the survey configured on the underlying job template. For the Azure Resource Group template, a sensible survey would ask for:

• Resource Group Name — text field, with a regex validator matching your naming convention (for example, a required environment prefix).
• Region — multiple choice, limited to the two or three Azure regions your organization actually supports.
• Environment — multiple choice (dev, test, prod), which can drive different tagging or approval logic downstream.
• Requesting Team (AAD Group) — multiple choice populated from your known Azure AD groups, rather than free text, so the RBAC assignment can't target an arbitrary object ID.

Fitting the Template into the Automation Portal Catalog

Once the job template, survey, and RBAC are in place, adding it to the Automation Portal is a matter of publishing it into the self-service gallery alongside the other entries demoed at Bunnik. From the requester's point of view, "Cloud - Request Azure Resource Group" looks identical in interaction pattern to "Cloud - Create S3 Bucket" or "Cloud - Provision AWS EC2 Instance" — a tile, a Start button, a short form, and a job that runs without the requester ever touching AAP's job template list, inventories, or credentials directly.

See also: AAP BYOM Provider Comparison 2026: Red Hat AI vs OpenAI vs Azure vs watsonx vs Gemini

Key Takeaways

• The Automation Portal in AAP 2.7 exposes existing job templates as one-click, form-driven self-service items — it does not replace the underlying job template mechanics.
• "Cloud - Request Azure Resource Group" pairs provisioning with automatic RBAC assignment, following the same guardrail pattern as the S3 and EC2 cloud templates shown in the same demo.
• A well-designed survey (dropdowns over free text for region, environment, and target AAD group) is what actually enforces "appropriate RBAC" — the playbook just executes what the survey constrains.
• Credential and template-level RBAC still govern who can even see the template in the catalog, layering platform-level access control on top of the Azure-level role assignment the playbook performs.
• This pattern generalizes: any cloud or network task in the catalog — S3 buckets, EC2 instances, firewall rule requests — follows the same project, credential, survey, job template structure behind its Start button.