How do you automate Windows and Linux server provisioning with Ansible Automation Platform across hybrid cloud?

Think of Ansible Automation Platform as a universal remote control for every server in your bank — whether it is a Red Hat Linux box in AWS, a Windows Server in your on-premise VMware cluster, or a SUSE machine in Azure. Without it, every team has their own scripts, their own credentials, and their own way of setting up servers. With AAP, there is one platform that speaks every server's language, follows the same playbooks, and logs every action for compliance.

Ansible Automation Platform (formerly Ansible Tower/AWX) provides the enterprise features that raw Ansible lacks: a web UI and API for managing automation, RBAC for controlling who can run what against which servers, credential management that securely stores SSH keys, WinRM credentials, and cloud API tokens, job scheduling for recurring tasks, and a comprehensive audit trail of every playbook execution. For a bank operating across hybrid cloud (AWS EC2, on-premise VMware, Azure VMs), AAP serves as the single automation control plane. Execution environments — containerized Ansible runtimes with pre-installed collections and dependencies — ensure consistent behavior regardless of where the playbook runs.

Windows and Linux provisioning differ at the connection layer but share the same automation framework. Linux servers use SSH with key-based authentication. Windows servers use WinRM (Windows Remote Management) with certificate-based or Kerberos authentication. AAP handles this transparently through separate credential types and execution environments. A Windows execution environment includes the ansible.windows and community.windows collections, while a Linux execution environment includes ansible.posix and community.general. The key insight is that the playbook structure is identical — the difference is in the modules used (win_feature vs yum, win_service vs systemd, win_copy vs copy).

A standardized provisioning workflow in AAP uses job templates with surveys. The survey presents a form to the requester: server name, operating system (RHEL 9, Windows Server 2022, Ubuntu 22.04), environment (dev, staging, production), team, application role, and cloud target (AWS, VMware, Azure). The job template triggers a workflow that provisions the VM (calling Terraform or the cloud API), waits for the server to become reachable, then runs the appropriate provisioning playbook based on the OS. The Linux playbook applies CIS benchmark hardening (firewall rules, password policies, auditd configuration, SSH hardening), installs monitoring agents (Datadog, Splunk forwarder), configures time synchronization, joins the server to FreeIPA for centralized authentication, and registers the server in the CMDB. The Windows playbook applies STIG hardening, installs monitoring agents, joins the Active Directory domain, configures Windows Firewall rules, enables PowerShell logging for audit compliance, and registers in SCCM.

In production at a bank, AAP integrates with the ITSM workflow. A developer requests a server through ServiceNow, which triggers the AAP API via webhook. AAP provisions and configures the server, then updates the ServiceNow ticket with the server details, IP address, and compliance scan results. The entire process — from ticket creation to a fully hardened, monitored, domain-joined server — takes 15-20 minutes instead of the 2-3 days it took with manual processes. For compliance, every AAP job execution is logged with the user who triggered it, the playbook that ran, the inventory targets, and the full output. These logs feed into Splunk for SIEM integration and are available for SOX and PCI-DSS audit reviews.

The biggest gotcha is credential management across hybrid cloud. AAP's credential types handle this — you create separate credentials for AWS (access key + secret key or IAM role assumption), VMware (vCenter username/password), Azure (service principal), Linux SSH (private key), and Windows WinRM (domain admin or local admin). These credentials are encrypted at rest in AAP's database and injected into playbook executions as environment variables — operators can use credentials without seeing them. Another gotcha is execution environment bloat — do not create one massive execution environment with every collection installed. Build purpose-specific environments (windows-provisioning, linux-hardening, cloud-networking) that are small, fast to pull, and easy to maintain. Finally, test playbooks with Molecule against both fresh and partially-configured servers to ensure idempotency — a playbook should produce the same result whether it runs on a brand-new server or one that was partially provisioned before a failure.