Ansible Automation Platform: your first controlled job

1. Choose a realistic learning route

This is a platform walkthrough, not an installer. Complete the local Ansible lesson first. No platform? Explore Red Hat developer learning options and current trial terms. Confirm availability, eligibility and expiration before signing up.

AAP is Red Hat’s enterprise platform. Community ansible-core is the engine; AWX is an upstream controller project, not a free supported AAP subscription. Marketplace infrastructure can still cost money. Do not install a full platform on our tiny beginner VM without checking version-specific sizing and supported topology.

2. Learn the platform objects

Automation execution runs jobs; automation hub distributes automation content; platform access controls govern who can use them. Event-driven automation reacts to events, but comes after deliberate manual testing.

3. Sync a reviewed project

1. Place inventory.ini, site.yml and message.txt.j2 from our local lesson into an authorized Git repository. Exclude secrets, state and private inventories.
2. Under Automation Execution, create a Project named contoso-practice, using Git and your actual repository URL.
3. Select a reviewed revision. Prefer a commit or immutable reviewed tag for repeatable releases. Private repositories need an approved, read-scoped source-control credential.
4. Sync and inspect the result. Record the revision. Sync fetches code; it does not run the playbook.

Only trusted maintainers should edit executable automation. A source-control credential does not automatically grant access to target machines.

4. Use an intentionally safe inventory

Create inventory contoso-practice and a host named localhost. Set these host variables:

ansible_connection: local

No SSH machine credential or privilege escalation is needed. For a remote host, use one authorized target, an appropriate scoped machine credential, verified host trust and reachable networking from the execution node. A private-key path on your laptop is not a usable platform path.

5. Select a repeatable toolbox

Select an administrator-approved execution environment with compatible Python and ansible-core. Built-in modules need no extra cloud collection here. Record the image version or digest; latest is a moving target.

Ansible Builder packages the engine, runner, collections and dependencies into an image. Build and test outside production, scan the image, push to an authorized registry and register it in the platform. Credentials belong in the platform’s credential system, not Git or image definitions. Match architecture and your organization’s support policy.

A collection installed on your laptop is not automatically in the execution environment. A Python dependency required on a managed host may need installation there instead.

Reference: execution environments and Ansible Builder.

6. Launch the first controlled job

1. Create contoso-practice-run with job type Run, practice inventory, synced project, site.yml and the approved environment.
2. Leave privilege escalation off and unrelated credentials unattached. Keep unrestricted prompt-for-extra-variables disabled.
3. If permitted, add a text survey for lab_message: nonempty, maximum 120 characters, a harmless default. The playbook assertion still checks the input.
4. Launch once. Review the revision, inventory, environment, task results and assertions. Record the job ID.

Another AAP job commonly starts in a fresh container, so file tasks may report changed again. That differs from repeated runs against the same persistent remote host.

A Check job only predicts supported changes. On a fresh container the verification tasks skip; a successful check does not prove a file was created. Reference: launch a job template.

7. Add approval and scoped access

Create a separate Check template with the same reviewed project. Connect Check success → Approval → Run in a workflow. Set a finite approval timeout, confirm who can approve, and test that denial or expiry prevents the Run node.

Verify the harmless lab_message is passed consistently through child templates. Keep revision and image consistent across nodes; avoid a branch moving between review and execution. Approval is a human gate, not automatic rollback.

Give learners only the permission needed to execute this practice template. Separate project editing, inventory changes and credential administration. Launch overrides can broaden the effects of a job; review them carefully. Success-only paths stop on failure but do not undo previous changes.

Add schedules only after manual testing, with an owner, expiry, concurrency policy and maintenance window. Reference: AAP workflows.

8. Diagnose and finish responsibly

Record revision, image, input and job ID for reproducibility. Remove only your practice schedules, workflow, templates, inventory and project when dependencies allow. Do not delete shared credentials or execution environments. Follow the administrator’s retention policy.

Finish a trial deliberately: check terms and separately remove cloud resources you provisioned. Trial expiry does not automatically remove VM, disk or registry charges. Next, pair a reviewed Terraform plan with an authorized remote Ansible job, keeping both approvals explicit.