This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Federal Modernization Workbook

Ansible for Configuration Automation

Where Ansible fits in a federal modernization program beside Intune, Azure Arc, Azure Policy machine configuration and Configuration Manager, with one owning tool per setting: Azure Arc onboarding at scale, and the tier-2 populations Intune and Arc don’t reach (AIX, Solaris, Linux beyond Arc’s support list, network gear, appliances, VMware, Infoblox and cloud VMs). Ansible Automation Platform’s federal posture (authorization, FIPS, baseline content from CIS Benchmarks and agency CM-6 settings, hosting, credentials and the controller as a non-person identity), the evidence it produces for CM-2, CM-3, CM-6, CM-7, CM-8 and AU, the dangers and how to avoid them, a phased adoption path, and tested example playbooks.

Ansible can reach almost anything with an SSH port or an API, which is exactly why a program has to decide, setting by setting, where it is allowed to write.

NoteIn this guide

What Ansible is and isn’t next to Intune, Azure Arc, Azure Policy and machine configuration, and Configuration Manager, and the rule that keeps them from fighting: one owning tool per setting, recorded in the CMDB. Where Ansible fits: onboarding servers to Azure Arc at scale, and managing the populations Intune and Arc don’t reach (AIX and Solaris, Linux outside Arc’s support list, network devices, VMware, Infoblox NIOS, Windows where Configuration Manager isn’t used, and cloud VMs), which the program’s coverage tiers call tier 2. Ansible Automation Platform in a federal setting: authorization status, FIPS mode, baseline content (CIS Benchmarks, Red Hat’s CIS profiles and the agency’s own CM-6 settings), hosting, and credentials, with the controller governed as a non-person identity. The evidence Ansible produces for CM-2, CM-3, CM-6, CM-7, CM-8 and the AU family. The dangers and how to avoid them. A phased adoption path with gates. And a folder of example playbooks, tested and downloadable.

TipDownload the examples

ansible-examples.zip: a dynamic inventory that reads a CMDB export, and six small playbooks (the CM-8 inventory feed, gated Azure Arc onboarding, a Linux baseline drift check pinned to check mode, read-only network and Infoblox facts, the Arc wave plan, and the same onboarding through Microsoft’s role), with tests that fail on any ungated write. Rebuilt on every site deploy from examples/ansible. The example playbooks section below describes them.

TipWatch or present

Technical deep dive (about 19 minutes narrated, captions): where Ansible fits, Ansible Automation Platform in a federal setting, evidence and dangers, and adoption with the example playbooks, in four modules, on the Presentations page, or ▶ watch it in the browser.

How to read this guide

Ansible appears in several books, always in passing: as an Azure Arc onboarding method in Book 05, Chapter 09, as the Red Hat configuration stack in Book 12, Chapter 07, as a remediation tool in VMware’s hardening content in Book 15, Chapter 09, and as the Infoblox collection in Book 08. This guide gathers those mentions into one implementation view and links back to the chapters for the depth.

It follows the identity and device material’s four tracks: HR for people, Intune for end-user devices, Azure Arc for servers, and non-person identities. Ansible belongs to the Arc track, where it onboards servers and manages the ones Arc can’t, and to the non-person identity track, because the automation controller is itself an identity with standing access to many hosts.

Facts in this guide come from the chapters it links to, and the ones the chapters don’t carry were checked on October 29, 2026 against Microsoft Learn, Red Hat’s documentation, the FedRAMP Marketplace, AWS, CISA, CIS, NIST, the Ansible Lockdown project and the Ansible documentation, and are footnoted. The Ansible community documentation site refused automated requests on that date, so Ansible facts were checked against the source files the site is built from, and the footnotes give the published address. Statements marked (design guidance) are the program’s recommendations, as in the books. Product names are examples, not endorsements.

The guide is written for a FedRAMP Moderate civilian agency, so configuration baselines are the agency’s own CM-6 settings, drawn from civilian sources such as the CIS Benchmarks, the NIST National Checklist Program and the vendor’s hardening guide. High only marks material that applies to FedRAMP High or Defense environments, such as DISA STIGs, not to the Moderate civilian baseline this workbook targets. It’s kept as an optional reference.

What Ansible is, and what it isn’t

Ansible is an automation engine that connects to the hosts it manages, over SSH for Linux and Unix and over WinRM, PowerShell Remoting or SSH for Windows,¹ runs small programs called modules there, and removes them. There’s no Ansible agent on the target. A playbook lists tasks in YAML; an inventory lists hosts and groups; a collection packages modules, plugins and roles for a platform. Modules should be idempotent, meaning that running a task once has the same result as running it repeatedly, but the documentation is candid that not every playbook or module behaves that way.² Ansible also has a check mode that simulates a run without making changes, which this guide leans on heavily.³

ansible-core is the free command-line engine. Red Hat Ansible Automation Platform is the supported product around it: an automation controller (web interface, API, role-based access, credential store, job scheduling and logging), a private automation hub for approved content, and execution environments that package ansible-core with pinned collections.

What Ansible isn’t is a management plane with a record of its own. It doesn’t enroll a device, evaluate compliance continuously, or keep a desired state that it re-applies by itself; it does what a playbook says, when the playbook runs. That distinction decides where it fits.

Which tool owns which population

Tool	What it manages	How it acts	Population it owns (design guidance)
Microsoft Intune	End-user devices: Windows, macOS, iOS and Android. Its supported platforms don’t include Windows Server (Book 05, Chapter 03)	Enrollment; the device checks in and applies assigned policy	Tier 1 end-user devices
Azure Arc with Azure Policy machine configuration	Windows and Linux servers outside Azure, on the versions Microsoft lists4	The Connected Machine agent; machine configuration audits, applies and monitors, or applies and auto-corrects operating system settings5	Tier 1 servers
Azure Policy	Azure resources, including the Arc machine resource and its tags	Policy assignments evaluated by Azure Resource Manager	Azure resources
Configuration Manager	Windows devices and servers where it’s already deployed; co-management moves workloads to Intune one at a time (Book 05, Chapter 01)	The Configuration Manager client	Existing estates only: no greenfield use (Book 05, Chapter 04, pillar 4)
Ansible	Anything reachable over SSH, WinRM or an API, including network devices and appliances	Push: a playbook runs when someone or a schedule starts it	Tier 2 assets whose CMDB record names it; Arc onboarding for tier 1 servers

One owning tool per setting

Book 05’s onboarding standard allows one management plane per asset and no co-management for new assets (Chapter 04, pillar 4). Ansible makes that rule easy to break, because it can write to a server that Azure machine configuration already governs, and nothing in either tool notices. Machine configuration’s auto-correct mode makes the collision worse: when a setting drifts, the agent corrects it, and Microsoft says there’s no way to report that a drift was automatically corrected.⁶ Two tools that disagree on one setting can therefore flip it back and forth indefinitely while both report success. Microsoft’s own warning on the point is narrow, about running machine configuration beside older Desired State Configuration versions, but the principle is general: “don’t try to manage the same settings.”⁷ Microsoft doesn’t publish guidance on dividing settings between machine configuration and Ansible, Chef or Puppet.

The program’s rule (design guidance):

1. The owner is an attribute. Every asset’s CMDB record names the one tool that owns its configuration settings (config_owner: Intune, Arc machine configuration, Configuration Manager, Ansible or the platform’s own controller). The CMDB is already the origin of business facts about devices and servers (Book 05, Chapter 03); which tool owns the settings is one more.
2. Ansible reads anything and writes only what it owns. Assessment playbooks may run anywhere the program allows. A playbook that changes a setting runs only against hosts whose config_owner is Ansible, enforced by building the inventory group from that attribute and by an assertion in the playbook itself.
3. Onboarding isn’t owning. Installing and connecting the Arc agent hands a server to Arc. After that, Ansible doesn’t set what machine configuration sets.
4. An exception is a record. Where Ansible must touch a setting another tool owns (an emergency fix, a setting the owner can’t express), it’s a dated exception with a reason, and the owning tool’s baseline is updated to match within the exception’s life.
5. Patching has one owner too. The CMDB names the tool that patches each server (patch_owner), mirrored to the Arc PatchOwner tag. Where Ansible already patches a fleet, such as Red Hat Enterprise Linux on AWS, Update Manager only assesses those servers and schedules nothing on them (Book 05, Chapter 09).

Where Ansible fits

The device and server tracks sort every asset into four coverage tiers: tier 1, managed by Intune or Arc; tier 2, managed by the platform’s own tool with an evidence feed, the CMDB as the attribute source; tier 3, discovered only; tier 4, segmented or retired. Ansible is the natural tier-2 tool, and an onboarding tool for tier 1.

Ansible across the coverage tiers

Tier	Ansible’s role (design guidance)
1. Intune or Arc	Onboards servers to Arc at scale; reads facts for the CM-8 feed; doesn’t own settings
2. Platform’s own tool with an evidence feed	Owns configuration where the CMDB names it; posts every job’s results to the evidence store; reads its targets from the CMDB
3. Discovered only	Reads facts where it’s allowed to, to move an asset into tier 1 or 2; never changes it
4. Segmented or retired	Nothing. No playbook targets the group

Arc onboarding at scale

Microsoft lists Ansible among the at-scale Arc onboarding methods: “the Azure Arc onboarding role in Ansible Core or Ansible Automation Platform.”⁸ The role, azure.azcollection.azure_arc, installs the Connected Machine agent and registers each target; Microsoft calls it idempotent, skips machines already connected, and says it neither discovers machines nor replaces Azure Policy–based management.⁹ It takes the resource group, subscription, tenant, region, cloud and tags as variables.¹⁰

How the role signs in to Azure decides how much secret handling the program inherits:

Sign-in	What Microsoft says	Program use (design guidance)
Managed identity of the control node (auth_source: msi)	“the recommended authentication method for production automation,” because it removes stored secrets; the control node must be an Azure VM or an Arc-enabled server, and the identity has no Azure permissions until granted11	First choice where the controller runs in Azure or is itself Arc-enabled
Service principal through Automation Platform’s Azure credential (auth_source: env)	The platform injects the values, so no secret is hard-coded in the playbook12	Where the controller can’t have a managed identity; a certificate credential, as Book 05 recommends
Azure CLI sign-in (auth_source: cli)	For interactive use and development; not applicable in Automation Platform13	Pilots only

Whichever identity signs in, it holds the Azure Connected Machine Onboarding role on the target resource group and nothing else.¹⁴ Microsoft’s security guidance recommends assigning that role only to the onboarding service principal.¹⁵ Book 05 adds the program’s rules: a dedicated, certificate-based service principal, scoped to the resource group, created and removed per wave, because the credential is needed only while azcmagent connect runs (Chapter 09). Where a playbook calls azcmagent connect itself, Microsoft recommends passing the service principal secret in a configuration file rather than on the command line, to keep it out of console logs; --config takes a JSON or YAML file of the command’s flags, and --tags a comma-delimited list of Name=Value pairs.^{16 17} For Azure Government, --cloud AzureUSGovernment goes with --location.¹⁸

The tags are where Ansible earns its place. The inventory comes from the CMDB, so the onboarding run writes the CMDB’s owner, environment, location and patch group onto the Arc resource on the same change, and the derived pointer starts out explainable from its origin, as Book 05, Chapter 03 requires. Run onboarding in Book 05’s waves: credential, connect, attach the baseline, verify, close (Chapter 09). The example playbook 02_arc_onboarding.yml spells those steps out with azcmagent, gated so nothing changes without confirm_change=true; for production, prefer Microsoft’s role, which the example 06_arc_onboarding_role.yml shows.

Linux and Unix baselines

Arc supports the Windows and Linux versions on Microsoft’s list, and “Operating system versions not listed in either table aren’t supported by Azure Arc.”¹⁹ AIX, Solaris and HP-UX aren’t on it. Several Linux releases still common in federal estates no longer get new agent versions: Red Hat Enterprise Linux 7, Oracle Linux 7, Amazon Linux 2, Debian 11 and 12, SUSE Linux Enterprise Server 12 SP5 and 15 SP3 through SP6, and Ubuntu 18.04 and 20.04 reached the end of new agent version support in October 2026, with 1.69 their final compatible agent version, serviced for 12 months after its release.²⁰ Microsoft also says the agent isn’t tested on operating systems hardened to the CIS Benchmark.²¹

Those hosts are tier 2. Ansible reaches them over SSH, escalating with the host’s own mechanism (sudo, su, pfexec, doas, pbrun, dzdo and others),²² and a baseline is a playbook that sets or checks a list of settings. Two cautions from the documentation shape how. First, become can’t be limited to particular commands, because modules run from temporary files whose names change on every run, so a sudo rule that allows only named commands will fail.²³ The escalation account therefore has broad rights, which is why it’s governed as a privileged non-person identity (below). Second, check mode is “just a simulation”; a task whose condition depends on an earlier task’s result won’t report in check mode.²⁴ Write drift checks so each comparison stands alone, as the example 03_linux_baseline_check.yml does.

For Red Hat Enterprise Linux, Red Hat ships SCAP Security Guide content that turns a CIS profile into Ansible remediation; Baseline content has what Red Hat and the community publish. Whatever content the program adopts, the playbook version in Git is the baseline (Evidence).

Network devices

Routers, switches and firewalls take no endpoint agent, and Ansible’s network collections connect to them over SSH or the platform’s API. The Cisco IOS collection’s facts module, for one, runs over the network_cli connection and gathers the min subset by default, returning facts prefixed ansible_net_: host name, model, serial number and software version.²⁵ That’s a CM-8 feed for the network estate with no new software on any device.

Ownership needs care here (design guidance). Where a vendor controller already manages the devices (an SD-WAN manager, a wireless controller, a firewall manager), the controller owns the configuration and Ansible reads, or drives the controller’s API, rather than writing to the devices behind its back. Where no controller exists, Ansible can own the device configuration, with the rendered configuration as the CM-2 baseline.

VMware

Two layers, two owners. Virtual machines on vCenter can be tier 1: Arc-enabled VMware vSphere installs the Connected Machine agent on supported VMs at scale (Book 05, Chapter 09). The hypervisor and its appliances can’t run an operating system agent, and that’s where Ansible fits. Their baseline is the agency’s CM-6 settings, drawn from Broadcom’s VMware Cloud Foundation Security Configuration and Hardening Guide and the CIS VMware ESXi 8.0 (1.4.0) and 9.0 (1.0.0) Benchmarks;²⁶ Book 15 covers how VMware’s own tools assess them (Book 15, Chapter 09). Broadcom’s STIG readiness content for VMware Cloud Foundation 9 (High only) also remediates appliances with Ansible playbooks, an optional reference. Book 15 records which content version each scan used, and the same discipline applies to the playbook version that remediated.

For VM inventory, use the vmware.vmware.vms inventory plugin. The older community.vmware.vmware_vm_inventory plugin was removed in community.vmware 7.0.0, which points to vmware.vmware.vms instead.²⁷ The vmware.vmware_rest collection reads vCenter through its REST API, for example vcenter_vm_info to list virtual machines.²⁸ Where VMware’s own Configuration Profiles or Security Posture Management already govern a setting, those own it (Book 15, Chapter 09), and Ansible reads.

Infoblox NIOS

The infoblox.nios_modules collection manages DNS, DHCP and IPAM objects through the NIOS WAPI (Book 08, Appendix A), and Infoblox Universal DDI has a Red Hat–certified collection of its own (Book 08, Chapter 11). Its lookup plugins (nios_lookup for any WAPI object, nios_next_ip for the next free address) run on the control node and need the infoblox-client Python package.²⁹ Record and address changes from a playbook are the “configuration management” integration Book 08 lists; the program’s rules for who may change DDI objects, through scoped service accounts, are in Book 08, Chapter 11, and the NIOS build is in the Infoblox NIOS implementation guide. Give the automation account a NIOS admin group scoped to the objects it manages, and a read-only group for the evidence playbooks.

Windows where Configuration Manager isn’t used

Ansible manages Windows over WinRM, PowerShell Remoting (PSRP) or SSH; SSH has been officially supported since ansible-core 2.18 and needs the OpenSSH that ships with recent Windows versions.^{30 31} That makes it a candidate for Windows hosts outside both Configuration Manager and Arc: appliances built on Windows, systems in enclaves Arc can’t reach, and application deployment on servers whose operating system settings another tool owns. A Windows Server that’s connected to Arc is tier 1, and its operating system settings belong to machine configuration (Book 05, Chapter 09); Ansible may still deploy and configure the application on it, which is a different setting with a different owner (design guidance).

Cloud VMs

Microsoft doesn’t support installing the Connected Machine agent on an Azure VM; Azure VMs are managed natively.³² On AWS, the Arc multicloud connector onboards EC2 instances (Book 05, Chapter 09), and AWS Systems Manager State Manager can itself run Ansible playbooks through its associations (Book 12, Chapter 07). For inventory, Ansible’s cloud inventory plugins read each provider’s API directly: amazon.aws.aws_ec2, google.cloud.gcp_compute and azure.azcollection.azure_rm.³³ Use them to reconcile the cloud’s view against the CMDB, not to replace it: the cloud knows the instance exists, the CMDB knows who owns it and why.

Ansible Automation Platform in a federal setting

Automation Platform is software the agency runs, in almost every deployment option, and that one fact drives its federal treatment. Everything in this section was checked on October 29, 2026; recheck it before an authorization decision, because product status changes.

Versions

Ansible Automation Platform 2.7 became generally available on June 2, 2026, with full support until June 2, 2027 and maintenance until June 2, 2029; 2.6 left full support on October 1, 2026 and is maintained until October 1, 2028.³⁴ The platform’s default automation engine is ansible-core 2.16, which Red Hat supports for the whole life of 2.5, 2.6 and 2.7 even though the community version reached end of life in July 2025; execution environments with ansible-core 2.18 are supported the same way, and 2.7 adds an optional 2.20 stream.^{35 36} Version 2.7 installs as containers on RHEL 9 or 10, rootless by default, or through the operator on OpenShift; there’s no RPM installer in 2.7.^{37 38} It also makes the platform gateway the only supported path for external sign-in and API access.³⁹

Authorization status

Ansible Automation Platform and FedRAMP

Offering	FedRAMP status, as published
Self-managed Ansible Automation Platform (on agency infrastructure, or on agency-provisioned VMs in any cloud)	Not a cloud service offering, and not on the FedRAMP Marketplace. Neither Red Hat nor FedRAMP publishes a statement about it; it’s customer-operated software inside the agency system’s own boundary, as Book 12 treats it (Chapter 07)
Red Hat Ansible Automation Platform Service on AWS (Red Hat runs the control plane; the customer runs execution nodes)	Not on the FedRAMP Marketplace40 and not on Red Hat’s list of FedRAMP offerings41
Ansible Automation Platform on Microsoft Azure (a managed application in the customer’s tenant)	Not on the FedRAMP Marketplace;42 availability in Azure Government not published43
For contrast: Red Hat OpenShift Service on AWS	FedRAMP Certified at High (package FR2102031769), with Red Hat Lightspeed, formerly Insights, bundled44

Red Hat’s own page is explicit that “FedRAMP is only applicable to the products listed below,” and the list holds only the two OpenShift Service on AWS architectures and Lightspeed, available through AWS GovCloud.⁴⁵ The marketplace’s product data contained no Ansible offering on that date.⁴⁶ So the program’s default (design guidance) is self-managed Automation Platform inside the system boundary, authorized as an agency-operated component and hardened like any other, with the managed offerings considered only after their authorization status changes. Book 12 already excludes Red Hat Insights (now Red Hat Lightspeed) from the boundary by default until an authorization review admits it (Chapter 07).

FIPS mode

Red Hat’s FIPS 140 page lists certificates for RHEL’s cryptographic modules and says they generally apply to other Red Hat products running unmodified on that RHEL; Automation Platform isn’t listed by name.⁴⁷ The 2.6 and 2.7 documentation opened for this guide doesn’t state whether the platform is supported on RHEL in FIPS mode. The history shows the combination has been worked on: the 2.5 release notes listed platform gateway on FIPS-enabled RHEL 9 as unsupported (AAP-39146) and fixed it in the April 9, 2025 update, with later fixes for PostgreSQL password handling on FIPS systems.⁴⁸ Ask Red Hat for a written support statement for the version you deploy, and test it. FIPS mode is a question in its own right, not a side effect of a hardening profile: where the agency requires FIPS 140-validated cryptography for the controller, its RHEL host runs in FIPS mode, and the platform’s support for that mode is what has to be confirmed (design guidance).

Baseline content

A Moderate civilian agency doesn’t adopt a hardening profile wholesale. NIST SP 800-53’s CM-6 asks the organization to establish configuration settings using organization-defined common secure configurations, and to document and approve deviations; its discussion says those configurations can come from product developers and vendors, federal agencies, consortia, academia and industry.⁴⁹ NIST’s National Checklist Program is the federal repository for finding them.⁵⁰ CISA’s SCuBA secure configuration baselines cover Microsoft 365 and Google Workspace,⁵¹ not the servers and devices Ansible manages, so for those the starting points are the CIS Benchmarks and the vendor’s own hardening guidance (design guidance). Two targets:

• The hosts it manages. For RHEL, Red Hat’s SCAP Security Guide ships CIS profiles, including the CIS Red Hat Enterprise Linux 9 Benchmark at Level 1 and Level 2 for servers and workstations,⁵² and Red Hat’s security hardening guide documents remediating a system to a baseline “by using an SSG Ansible Playbook” from that package, for RHEL 9 and RHEL 10.⁵³ CIS publishes the benchmarks themselves, among them Red Hat Enterprise Linux 9 (3.0.0) and 10 (1.0.1) and Windows Server 2022 (5.1.0) and 2025 (2.1.0).⁵⁴ Outside Red Hat’s content, the community Ansible Lockdown project, sponsored by MindPoint Group, publishes CIS remediation roles such as RHEL9-CIS, RHEL10-CIS and Windows-2022-CIS, each with an -Audit counterpart.⁵⁵ Its RHEL9-CIS role warns that it “will make changes to the system” and was developed against a clean operating system install, while RHEL9-CIS-Audit only checks the current state, with goss; on the date checked both tracked version 2.0.0 of the CIS RHEL 9 Benchmark, behind CIS’s 3.0.0.^{56 57} It’s community content, not a Red Hat–supported product, so review it and pin it like any third-party collection (Dangers), and check which benchmark version it tracks (design guidance). Whatever content the program adopts, it customizes it in Git to the agency’s CM-6 settings, records each deviation, and runs it in check mode first.
• The controller. The 2.7 documentation covers installing on hosts hardened to CIS, PCI DSS or the DISA STIG: fapolicyd rules, noexec on /tmp and /var during installation, and the umask a containerized install needs.⁵⁸ So the controller’s host is hardened like any other RHEL server, to the CIS RHEL 9 or 10 Benchmark and the agency’s CM-6 settings, with those installation caveats (design guidance). For the controller application itself, Red Hat lists a DISA STIG for Red Hat Ansible Automation Controller among the published STIGs,⁵⁹ first released in April 2023 (High only).⁶⁰ It’s an optional reference for the controller’s own settings, not a requirement. This guide couldn’t reach the DoD Cyber Exchange to confirm its current release or the platform version it covers.

Hosting

Where Automation Platform can run

Option	What Red Hat documents	Program view (design guidance)
On premises	Containerized installation on RHEL, or the OpenShift operator61	The default where the managed estate is on premises; nearest to the targets
Self-managed on agency-provisioned cloud VMs (for example AWS GovCloud (US), AWS US East/West or Azure Government)	Self-managed offers on the AWS, Google Cloud and Oracle marketplaces; on any cloud, the agency can install on RHEL VMs it provisions itself62	The controller inherits the cloud’s infrastructure authorization for the services and Region it uses, checked per service, and adds its own controls; a managed identity becomes possible where the controller is an Azure VM (Arc onboarding)
Azure managed application	Deployed from Azure Marketplace into the customer’s tenant; Red Hat reaches only the managed resource group63	Published for commercial regions only; not FedRAMP-listed, which is what keeps it out of the default
AWS managed service	Red Hat runs the control plane in its own infrastructure; execution nodes run in the customer’s network; job logs erased every 30 days64	Published for commercial regions only; not FedRAMP-listed, which is what keeps it out of the default; the 30-day log erasure means job results must be exported for AU retention

Red Hat publishes no Azure Government or AWS GovCloud availability for either managed offering; both guides’ region tables list commercial regions only.^{65 66} A commercial Region isn’t the obstacle for a Moderate system: AWS lists its US East/West Regions as FedRAMP Certified Class C (formerly the Moderate baseline) and GovCloud (US) as Class D (formerly High), and records each service’s authorization per Region.⁶⁷ Because the baselines are cumulative, a Moderate system can run in either (inference). The managed offerings stay out of the default because neither is FedRAMP-listed. Wherever the controller runs, the management traffic to its targets crosses a boundary edge, and Book 12 records each such channel as an external connection with its own agreement (Chapter 07).

Sign-in, roles and tokens

The platform gateway brokers user sign-in through local accounts, LDAP, SAML, generic OIDC, Microsoft Entra ID and others; role-based access assigns predefined or custom roles per resource to users and teams.⁶⁸ Federate sign-in to the agency’s identity provider so Conditional Access, phishing-resistant MFA and joiner-mover-leaver processes apply, and keep local accounts to the break-glass minimum (design guidance). API tokens are issued only by the gateway in 2.7; the default access-token lifetime was cut from 1,000 years to 1 year, and tokens created before the 2.5.20250604 update keep the old lifetime,⁶⁹ so inventory and revoke old tokens when upgrading.

Logging and audit

The controller sends logs to an external aggregator (Splunk, Loggly, Sumo Logic or Elastic) over HTTPS, TCP or UDP; Red Hat names job facts, job events, activity stream data and log messages as the most useful streams.⁷⁰ The activity stream records the time, user and action for every change to a controller object,⁷¹ and Red Hat’s hardening guidance is to collect logging and auditing centrally, alongside RHEL’s own audit daemon.⁷² Cleanup jobs delete job history and activity-stream records older than a configured number of days,⁷³ so set them to the agency’s retention schedule, or rely on the SIEM copy for retention and keep the controller’s history short.

Content and change sources

Automation hub serves Red Hat Certified collections, included in the subscription, and Ansible validated content, alongside whatever the agency approves from Galaxy.⁷⁴ Collection and container signing in the hub is disabled by default and is enabled with GPG keys at installation; 2.7 adds post-quantum signing as a manual option.⁷⁵ Clients verify signatures only if a keyring is configured.⁷⁶ Project signing with ansible-sign makes the controller refuse to update a project whose signature fails, so its jobs don’t launch,⁷⁷ which ties the CM-3 pull request to what actually runs. Job templates can also be triggered by GitHub or GitLab webhooks.⁷⁸

Credential plugins

Automation Platform stores machine, cloud, network, source control and vault credentials, and fetches secrets at run time from external stores through credential plugins: AWS Secrets Manager, Centrify, CyberArk Central Credential Provider and Conjur, HashiCorp Vault (key-value and signed SSH certificates), Microsoft Azure Key Vault, and Thycotic.⁷⁹ Version 2.7 adds HashiCorp Vault credential types that authenticate with a short-lived token issued per job.⁸⁰ The program uses those to keep long-lived secrets out of the controller altogether.

Credentials and the controller’s identity

An automation controller holds the keys to every host it manages. It’s a non-person identity with more reach than almost any administrator, and the program governs it as one (design guidance):

• An owner. Two named human owners for the controller and for each of its credentials, as for any service principal (Book 02, Chapter 09).
• Least privilege, by credential. One credential per purpose and scope (Arc onboarding for one resource group, read-only facts for the network estate, change rights for one tier-2 platform), never one account that can do everything. The escalation account on Linux and Unix has broad rights by necessity (above); confine it to the hosts whose config_owner is Ansible.
• No standing secrets. Prefer a managed identity or workload identity federation for Azure (Book 04, Chapter 05); otherwise certificates; and fetch every remaining secret at run time from the agency’s vault through a credential plugin rather than storing it in the controller. Ansible Vault protects secrets in files, but the documentation warns that it “ONLY protects ‘data at rest’”: once decrypted for a run, keeping the value out of output is the playbook author’s job, with no_log.^{81 82}
• Expiring credentials. Every credential has an end date. Arc onboarding credentials live for one wave (Book 05, Chapter 09); the rest rotate on the program’s schedule.
• Reviewed like a privileged account. The controller’s role assignments, its credentials and the people who can launch jobs that use them are in the quarterly access review, and launching a job that changes production is itself a privileged action, logged and attributable to a person.

Evidence to the program

Ansible produces evidence as a side effect of being used properly: the playbook is a file in Git, the change is a pull request, the run is a job with a result. The program’s job is to land those artifacts where assessors look. The control titles are from NIST SP 800-53 Revision 5, release 5.2.0, and every control below is in the Moderate baseline.⁸³

Controls and the Ansible evidence for each

Control	What it asks	Ansible’s evidence (design guidance unless cited)
CM-2 Baseline Configuration	A current, documented baseline	The playbook or role version, by Git commit and tag, is the baseline version for the hosts it owns, as Book 12 already records Ansible playbook versions (Chapter 07)
CM-3 Configuration Change Control	Changes reviewed, approved and recorded	Every change to a playbook, inventory source or variable reaches the main branch only by pull request with a required reviewer; the controller runs only content from the main branch. Book 12 treats baseline changes by pull request as CM-3 (Chapter 07)
CM-6 Configuration Settings	Settings established, implemented and monitored	The baseline playbook implements; the same playbook in check mode monitors and reports drift. Book 12 lists Ansible enforcement under CM-6 (Chapter 07)
CM-7 Least Functionality	Only essential capabilities; prohibited functions, ports, protocols and services disabled	Baseline tasks that remove packages and disable services, checked by the same drift run (the example checks that telnet-server and rsh-server are absent)
CM-8 System Component Inventory	An accurate, current inventory	Inventory comes from the CMDB, so Ansible never invents a host; a facts run reports what each host actually is beside what the CMDB says, and records nothing reached as not collected (the example 01_inventory_assessment.yml)
AU-2 Event Logging, AU-12 Audit Record Generation	Defined events logged and records generated	The controller’s job records, activity stream and external logging to the SIEM (see Logging); for ansible-core alone, a callback or log file shipped to the SIEM
AC-6 Least Privilege, AC-6(5) Privileged Accounts	Least privilege; privileged accounts restricted	Per-purpose credentials and the controller as a governed non-person identity (above)
SR-3 Supply Chain Controls and Processes, SR-11 Component Authenticity	Supply chain risk addressed; counterfeit components detected	Collections from a reviewed, signed source, pinned by version and verified (see Dangers). SA-12, the Revision 4 supply chain control, was withdrawn and incorporated into the SR family84

Job results to the evidence store. Book 12’s evidence contract already expects Ansible Automation Platform job results to be posted to the coordination layer’s inbound integration, in the same shape every other stack emits: the asset’s authoritative identity as the join key, aap as the source stack, the finding or baseline reference, and the job ID as the evidence pointer (Chapter 07). Because the inventory came from the CMDB, every result already carries the CMDB’s configuration item number, which maps to the contract’s asset_id; the asset’s authoritative identity from the naming plane stays the join key. The example playbooks write CSV and JSON with that column for the same reason.

Evidence checklist

• Configuration: the playbooks, roles, inventory source and requirements.yml, by Git commit and tag, as the CM-2 baseline of the hosts Ansible owns
• Operational: check-mode drift reports, job results posted with the CMDB key, and the controller’s activity stream and job events in the SIEM (Logging), retained past any hosted service’s own log erasure
• Test: the two consecutive runs with no change on the second, the canary batch’s result, and the rollback test of Phase 3, with date and tester
• Exception: dated records for every setting Ansible touches that another tool owns (One owning tool per setting), with approver and expiry
• Assessor-ready artifact: the evidence-store entries for CM-2, CM-3, CM-6, CM-7, CM-8, AU-2, AU-12, AC-6 and SR-3, traceable to the four above

Dangers and how to avoid them

Ansible’s dangers and their controls

Danger	How it fails	How to avoid it
Blast radius	A playbook runs against all, or an inventory group is wider than anyone thought, and one bad task changes every host at once	Run in check mode first: Ansible “runs without making any changes on remote systems,” though modules without check-mode support “report nothing and do nothing.”85 Target narrowly with --limit.86 Change in batches with serial, which takes a number, a percentage or a list such as [1, 5, "25%"], so the first batch is a canary; set max_fail_percentage (it applies per batch, and must be exceeded, not equaled) or any_errors_fatal to stop on the first failure.87 88 Use --diff to see what would change, but it “can reveal sensitive information,” so turn it off on tasks that handle secrets.89
Inventory drift	A hand-kept hosts file disagrees with the CMDB: decommissioned hosts are still targeted, new ones are missed, owners are wrong	Generate inventory from the CMDB at run time. Ansible recommends inventory plugins over scripts for dynamic inventory;90 the constructed plugin builds groups from variables an earlier inventory source supplied.91 Fail the run on a duplicate or malformed record instead of producing a partial inventory
Credential sprawl	Each engineer keeps keys and passwords in local files; the same service account is used everywhere; a secret sits in a playbook	One controller, credentials stored or brokered there, per-purpose and expiring (above). Mark every task that handles a secret no_log: true; it doesn’t hide debugging output, so don’t run production jobs at high verbosity92
Two tools fighting over one setting	Ansible and machine configuration both set a value; auto-correct silently reverts Ansible, Ansible reverts it back, both report success	One owning tool per setting, as a CMDB attribute that builds the inventory groups (above), and an assertion in every changing playbook that refuses a host another tool owns
Unreviewed Galaxy content	A playbook installs the latest version of a collection from the public Galaxy server at run time; the new version changes behavior, or isn’t what it claims to be	Galaxy is a site for “finding and sharing Ansible community content.”93 Install collections from a private automation hub or after review, pin each one to an exact version in requirements.yml (by default ansible-galaxy installs the latest), and verify installed content with ansible-galaxy collection verify; where the source signs collections, require signatures with --keyring, which Ansible checks only for collections from a distribution server.94 95 Record each collection’s name, version and source as the automation’s software bill of materials, under SR-3 and SR-11
Running as root	Every task escalates, so a mistake in any task has root’s reach	Escalate per task, not per play: set become: false as the default and become: true only on tasks that need it. Remember escalation can’t be confined to commands (above), so confine it to hosts instead. Read-only checks that need root to read a file run pinned to check mode
Idempotence failures	command and shell tasks report a change every time, or change something every time, so drift reports are noise and reruns aren’t safe	Prefer a purpose-built module over command; the command module supports check mode only with creates or removes.96 Give every command task a changed_when that says when it actually changed something; ansible-lint’s no-changed-when rule flags those that don’t.97 Run each playbook twice in test and require the second run to report no changes

Lint as a gate. ansible-lint’s profiles increase in strictness from min through basic, moderate, safety and shared to production, which “meets requirements for inclusion in Ansible Automation Platform”; safety flags non-deterministic and risky module calls, and production requires fully qualified collection names.⁹⁸ Requiring the production profile on every pull request makes several of the controls above mechanical (design guidance).

A phased adoption path

(Design guidance.) Each phase ends at a gate, and the gate’s evidence is what the next phase builds on.

Adoption phases, decisions and gates

Phase	What happens	Decision, and who decides	Gate: done when
0. Read-only inventory	ansible-core on a hardened control node; inventory from the CMDB export; facts runs only, posted to the evidence store	Which CMDB attributes drive groups, and the config_owner values: the CMDB owner with the platform teams	Every managed CMDB record has a collected or not-collected row; owner-missing and version-mismatch findings sent back to the CMDB
1. Arc onboarding	Book 05’s waves, run by Microsoft’s role or a gated playbook, tags from the CMDB	Onboarding identity (managed identity or certificate service principal) and wave plan: server infrastructure (Book 05, Chapter 09)	Each wave connected, baselined and verified; the wave’s credential removed; Arc tags match the CMDB
2. Tier-2 baselines in check mode	Baseline playbooks for each tier-2 platform (Unix, Linux beyond Arc, network, VMware, Infoblox), run in check mode only, drift reported	The baseline content per platform (the agency’s CM-6 settings, drawn from the CIS Benchmark, Red Hat’s CIS profile or the vendor’s hardening guide): the CISO’s configuration authority	Every tier-2 host has a drift report against a versioned baseline; findings triaged
3. Enforcement under change control	Baselines applied for real, by pull request, in canary-first batches, on hosts whose config_owner is Ansible	Go-live per platform: the platform owner, through change control	Two clean consecutive runs (no changes on the second); rollback tested; exceptions recorded
4. Automation Platform at scale	The controller, private automation hub and execution environments; credentials brokered from the agency vault; logging to the SIEM; job results posted automatically	Hosting, authorization boundary and credential design: the system owner and the authorizing official	The controller is in the boundary documentation; its identity is reviewed like a privileged account; evidence arrives with no hand steps

Phase 0 can start in a week with nothing but a laptop-class control node and a CMDB export, and it produces evidence the program needs anyway. Automation Platform isn’t a prerequisite for phases 0 to 2; it’s the way to make phase 3 governable at scale.

Control states, change safety and assessment mapping

The workbook’s conventions for implementation procedures are in Book 00, Appendix D; this section applies them to the adoption path above.

Control states.

State	This page	Evidence
Designed	One owning tool per setting; Phase 0 and Phase 2 decisions (adoption path); baseline content	config_owner values in the CMDB; the approved baseline per platform
Configured	Phase 2: baseline playbooks run in check mode only	Playbook versions by commit; drift reports against the versioned baseline
Enforced	Phase 3: baselines applied by pull request, canary first, on hosts whose config_owner is Ansible	Job results; the pull request and its reviewer; the exception records
Evidenced	Phase 3’s gate: two clean consecutive runs and a tested rollback	The two job records and the rollback record
Operated	Phase 4, with credentials and the controller’s identity and logging	Owners and the quarterly access review; the drift-run schedule; controller logs in the SIEM

A finding this page addresses is ready for closure when every applicable state has evidence; the authorizing official or assessor decides.

How-template coverage. Where the guide carries each part of the How-section template:

How-section template, mapped to Ansible adoption

Subsection	Where
Prerequisites	Phase 0 (control node, CMDB inventory); Ansible Automation Platform in a federal setting for versions, authorization status, FIPS mode and hosting
Pilot	The canary batch of serial (Dangers); the example’s one host, then 5, then 25 percent
Report-only or audit phase	Check mode and --diff (Phase 2)
Enforcement	Phase 3, by pull request, in canary-first batches
Rollback	A playbook is reverted by applying the previous tagged version of the baseline to the same hosts through the same pull-request path, and tested in Phase 3 (design guidance)
Exclusions	Hosts another tool owns are refused by the playbook’s assertion; exceptions are dated records. Emergency access accounts: not applicable, because no step here blocks a sign-in
Telemetry	Logging and audit: job events, activity stream and logs to the SIEM
Evidence	Evidence to the program and its evidence checklist
Day-two ownership	Two named owners for the controller and each credential; the quarterly access review (credentials)

Change safety

Ring	Scope	Exit criteria
0	Check mode against the platform’s hosts	Drift report triaged; no unexpected change in --diff
1	The canary batch (first serial batch, for example one host)	Run succeeds; the second run reports no changes
2	The next batches (for example 5 hosts, then 25 percent)	max_fail_percentage not exceeded; no attributable incidents
3	Every host of the platform whose config_owner is Ansible	Two clean consecutive runs; drift reports clean

• Emergency access: not applicable to sign-in. The way back to a host is the platform’s own break-fix access, kept outside the controller so a bad run can’t remove it (design guidance).
• Change window: go-live per platform through the platform owner’s change control (Phase 3), with the playbook’s pull request as the change record.
• Backout triggers: set before the run: the first failure in a batch (any_errors_fatal, or max_fail_percentage exceeded), a service failure on a canary host, or a second run that still reports changes (program decision, settled as WD-150).
• Post-change validation: the same playbook in check mode after each ring, and the second-run test.

NoteAssessment mapping

• Microsoft Zero Trust pillar: Infrastructure
• CISA ZTMM pillar: Devices (servers and network devices as assets), with Applications and Workloads for the controller
• Depends on: the CMDB as the inventory of record; Identity (the controller and its credentials as non-person identities, Non-Person Identity guide); the Arc track for servers Arc can govern; SecOps (logs in the SIEM, Book 12)
• Attack chain interrupted: Persistence and Defense Evasion (configuration drift reverted to the baseline); Credential Access (no standing secrets in playbooks or on engineers’ machines); supply-chain compromise through unreviewed collections

The example playbooks

The examples/ansible folder, downloadable as ansible-examples.zip, shows the patterns above in small, readable files. It follows the house rules of the workbook’s Start Kit: read-only by default, tested, and a test that fails on any write it doesn’t allow.

What the example folder contains

File	Pattern it shows
inventory/cmdb_inventory.py and inventory/sample/cmdb_export.csv	The CMDB as the attribute source: groups by coverage tier, platform, environment and configuration owner; Arc onboarding candidates; owner-missing findings. Fails on a duplicate or malformed record
playbooks/01_inventory_assessment.yml	The CM-8 feed: facts and Arc agent status beside each CMDB record, as CSV and JSON
playbooks/02_arc_onboarding.yml	Gated change: check mode unless -e confirm_change=true; one canary host, then 5, then 25 percent; stop on the first failure; tags from the CMDB; the secret from Vault or the environment, passed through a deleted configuration file, never logged
playbooks/03_linux_baseline_check.yml	Drift as evidence: the play is pinned to check mode, runs only where Ansible owns the configuration, and refuses a host another tool owns
playbooks/04_network_and_ddi_facts.yml	Tier-2 evidence without agents: Cisco IOS facts and Infoblox Grid members, read-only
playbooks/05_arc_wave_plan.yml	The wave plan from the CMDB: ready servers, resource group, region and tags, and the servers the CMDB blocked; read-only, and stops on an empty wave, a wrong-cloud region, a production server in a non-production wave or a missing owner
playbooks/06_arc_onboarding_role.yml	The same waves through Microsoft’s azure.azcollection.azure_arc role; runs the wave plan first and calls the role only with confirm_change=true (commercial Azure only)
tests/	yamllint and ansible-lint (production profile) clean; --syntax-check on every playbook; a static check that fails on any ungated write; inventory tests; real runs against the control node

They were tested on October 29, 2026 with ansible-core 2.21.5, ansible-lint 26.10.1 and yamllint 1.38.0, on the control node only; the Arc, Windows, Cisco and Infoblox paths pass lint and syntax checks but haven’t run against those platforms. They’re illustrations, not production code.

Checklist

Ansible adoption checklist

Area	Done when
Ownership	Every asset’s CMDB record names one configuration owner · Changing playbooks run only on hosts Ansible owns · Exceptions are dated records
Inventory	Generated from the CMDB at run time · Malformed records fail the run · Not-collected hosts reported, never counted as compliant
Arc onboarding	Managed identity or certificate service principal · Onboarding role only, on the resource group · Credential removed when the wave closes · Tags from the CMDB
Change safety	Check mode first · --limit and canary-first serial · Stop on first failure · Second run reports no changes
Credentials	Two human owners · One credential per purpose · No secret in Git or in a playbook · Every credential expires · no_log on every secret-handling task
Content	Collections from a reviewed or signed source · Pinned versions · collection verify in the pipeline · Collection list kept as the automation’s bill of materials
Evidence	Playbook version as the CM-2 baseline · Pull requests as CM-3 · Job results posted with the CMDB key · Controller logs in the SIEM
Platform	Authorization treatment recorded · FIPS mode where required · CIS-aligned agency CM-6 baseline applied to the controller host and the hosts it manages · Controller reviewed as a privileged non-person identity

TipBack to the books

This is a companion guide, not part of a numbered book. ← The Workbook Books

Version and revision history

Version 2.0, in edition 2026.11.5 (November 8, 2026). Every edition is kept on the Archive page; every change between editions is in the commit history.

Versions of this guide, newest first

Version	Edition	Date	Changes
2.0	2026.11.5	2026-11-08	Release 2.0, the baseline: checked against every other book; Draft becomes Baseline; Edition 2026.11.4: record the edition and point deck links at it (#362); Guides A: fix 14 inconsistency findings (#441); Approve 116 gated pages (Nov 7); fix RMF map stale-review test (#457); Consistency read D: Books 15-19, guides, non-book pages (#483); Approve 15 gated pages (Nov 8, after the consistency read) (#490); Release 2.0: Draft becomes Baseline (#491)
1.4	2026.11.4	2026-11-05	Deck and audio links point at edition 2026.11.4
1.3	2026.11.3	2026-11-05	Review gate: Mike’s approval of the 15 implementation guides gated on November 3 (#348)
1.2	2026.11.1	2026-11-01	Edition 2026.11: record the edition, and publish the four gate-level decks and videos (#282)
1.1	2026.11	2026-11-01	Move the decks and narration audio out of git, onto edition 2026.10 (#260); Retire Research: move each page to a home by type (guides, training, reference, evaluations, explainers) (#269)
1.0	2026.10	2026-10-31	First edition (4 merged changes since the guide began)

Footnotes

1. Ansible documentation, “Managing Windows hosts with Ansible” (connection plugins psrp, ssh and winrm), https://docs.ansible.com/projects/ansible/latest/os_guide/intro_windows.html; checked against its source, docs/docsite/rst/os_guide/intro_windows.rst in the ansible-documentation repository (accessed Oct 29, 2026).

2. Ansible documentation, “Glossary,” Idempotency, https://docs.ansible.com/projects/ansible/latest/reference_appendices/glossary.html, and “Ansible playbooks,” Idempotency (“not all playbooks and not all modules behave this way”), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_intro.html; checked against their sources in the ansible-documentation repository (accessed Oct 29, 2026).

3. Ansible documentation, “Validating tasks: check mode and diff mode” (check mode makes no changes; modules without check-mode support report nothing and do nothing; check mode is a simulation; check_mode per task; --diff and sensitive information), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_checkmode.html; checked against its source, playbook_guide/playbooks_checkmode.rst (accessed Oct 29, 2026).

4. Microsoft Learn, “Connected Machine agent prerequisites,” Supported operating systems (unlisted versions unsupported; end of new agent version support dates; not tested on CIS-hardened systems), “Operating systems no longer supported by new agent versions” and “Azure Connected Machine Agent OS support and deprecation,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites#supported-operating-systems (accessed Nov 9, 2026).

5. Microsoft Learn, “Remediation options for machine configuration” (Audit, ApplyAndMonitor and ApplyAndAutoCorrect; no way to report an automatic correction), https://learn.microsoft.com/azure/governance/machine-configuration/concepts/remediation-options (accessed Oct 29, 2026).

6. Microsoft Learn, “Remediation options for machine configuration” (Audit, ApplyAndMonitor and ApplyAndAutoCorrect; no way to report an automatic correction), https://learn.microsoft.com/azure/governance/machine-configuration/concepts/remediation-options (accessed Oct 29, 2026).

7. Microsoft Learn, “PowerShell DSC in machine configuration” (no conflict detection across DSC versions), https://learn.microsoft.com/azure/governance/machine-configuration/whats-new/psdsc-in-machine-configuration (accessed Oct 29, 2026).

8. Microsoft Learn, “Azure Connected Machine agent deployment options” (Ansible row; the agent can’t be installed on an Azure VM), https://learn.microsoft.com/azure/azure-arc/servers/deployment-options (accessed Oct 29, 2026).

9. Microsoft Learn, “Connect machines to Azure Arc at scale with Ansible” (the azure.azcollection.azure_arc role; idempotent, skips connected machines; scope; role variables; authentication with Azure CLI, managed identity or an Automation Platform service principal credential; the Azure Connected Machine Onboarding role), https://learn.microsoft.com/azure/azure-arc/servers/onboard-ansible-playbooks (accessed Oct 29, 2026).

10. Microsoft Learn, “Connect machines to Azure Arc at scale with Ansible” (the azure.azcollection.azure_arc role; idempotent, skips connected machines; scope; role variables; authentication with Azure CLI, managed identity or an Automation Platform service principal credential; the Azure Connected Machine Onboarding role), https://learn.microsoft.com/azure/azure-arc/servers/onboard-ansible-playbooks (accessed Oct 29, 2026).

11. Microsoft Learn, “Connect machines to Azure Arc at scale with Ansible” (the azure.azcollection.azure_arc role; idempotent, skips connected machines; scope; role variables; authentication with Azure CLI, managed identity or an Automation Platform service principal credential; the Azure Connected Machine Onboarding role), https://learn.microsoft.com/azure/azure-arc/servers/onboard-ansible-playbooks (accessed Oct 29, 2026).

12. Microsoft Learn, “Connect machines to Azure Arc at scale with Ansible” (the azure.azcollection.azure_arc role; idempotent, skips connected machines; scope; role variables; authentication with Azure CLI, managed identity or an Automation Platform service principal credential; the Azure Connected Machine Onboarding role), https://learn.microsoft.com/azure/azure-arc/servers/onboard-ansible-playbooks (accessed Oct 29, 2026).

13. Microsoft Learn, “Connect machines to Azure Arc at scale with Ansible” (the azure.azcollection.azure_arc role; idempotent, skips connected machines; scope; role variables; authentication with Azure CLI, managed identity or an Automation Platform service principal credential; the Azure Connected Machine Onboarding role), https://learn.microsoft.com/azure/azure-arc/servers/onboard-ansible-playbooks (accessed Oct 29, 2026).

14. Microsoft Learn, “Connect machines to Azure Arc at scale with Ansible” (the azure.azcollection.azure_arc role; idempotent, skips connected machines; scope; role variables; authentication with Azure CLI, managed identity or an Automation Platform service principal credential; the Azure Connected Machine Onboarding role), https://learn.microsoft.com/azure/azure-arc/servers/onboard-ansible-playbooks (accessed Oct 29, 2026).

15. Microsoft Learn, “Identity and authorization” (Azure Arc-enabled servers security), Azure Connected Machine Onboarding role, https://learn.microsoft.com/azure/azure-arc/servers/security-identity-authorization (accessed Oct 29, 2026).

16. Microsoft Learn, “azcmagent connect,” Flags (--service-principal-secret and the configuration-file recommendation; --tags; --cloud with --location), https://learn.microsoft.com/azure/azure-arc/servers/azcmagent-connect (accessed Oct 29, 2026).

17. Microsoft Learn, “azcmagent CLI reference,” Common flags (--config takes a JSON or YAML file; the command line takes precedence), https://learn.microsoft.com/azure/azure-arc/servers/azcmagent (accessed Oct 29, 2026).

18. Microsoft Learn, “azcmagent connect,” Flags (--service-principal-secret and the configuration-file recommendation; --tags; --cloud with --location), https://learn.microsoft.com/azure/azure-arc/servers/azcmagent-connect (accessed Oct 29, 2026).

19. Microsoft Learn, “Connected Machine agent prerequisites,” Supported operating systems (unlisted versions unsupported; end of new agent version support dates; not tested on CIS-hardened systems), “Operating systems no longer supported by new agent versions” and “Azure Connected Machine Agent OS support and deprecation,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites#supported-operating-systems (accessed Nov 9, 2026).

20. Microsoft Learn, “Connected Machine agent prerequisites,” Supported operating systems (unlisted versions unsupported; end of new agent version support dates; not tested on CIS-hardened systems), “Operating systems no longer supported by new agent versions” and “Azure Connected Machine Agent OS support and deprecation,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites#supported-operating-systems (accessed Nov 9, 2026).

21. Microsoft Learn, “Connected Machine agent prerequisites,” Supported operating systems (unlisted versions unsupported; end of new agent version support dates; not tested on CIS-hardened systems), “Operating systems no longer supported by new agent versions” and “Azure Connected Machine Agent OS support and deprecation,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites#supported-operating-systems (accessed Nov 9, 2026).

22. Ansible documentation, “Understanding privilege escalation: become” (supported escalation methods; “Risks and limitations of become”: privilege escalation can’t be limited to certain commands), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_privilege_escalation.html; checked against its source, playbook_guide/playbooks_privilege_escalation.rst (accessed Oct 29, 2026).

23. Ansible documentation, “Understanding privilege escalation: become” (supported escalation methods; “Risks and limitations of become”: privilege escalation can’t be limited to certain commands), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_privilege_escalation.html; checked against its source, playbook_guide/playbooks_privilege_escalation.rst (accessed Oct 29, 2026).

24. Ansible documentation, “Validating tasks: check mode and diff mode” (check mode makes no changes; modules without check-mode support report nothing and do nothing; check mode is a simulation; check_mode per task; --diff and sensitive information), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_checkmode.html; checked against its source, playbook_guide/playbooks_checkmode.rst (accessed Oct 29, 2026).

25. Ansible documentation, cisco.ios collection, “cisco.ios.ios_facts module” (network_cli connection; gather_subset defaults to min; ansible_net_ facts), https://docs.ansible.com/projects/ansible/latest/collections/cisco/ios/ios_facts_module.html; checked against the module source in the ansible-collections/cisco.ios repository (accessed Oct 29, 2026).

26. Center for Internet Security, “CIS Benchmarks” (description; benchmark list, including Red Hat Enterprise Linux 9 (3.0.0) and 10 (1.0.1), Microsoft Windows Server 2022 (5.1.0) and 2025 (2.1.0), and VMware ESXi 8.0 (1.4.0) and 9.0 (1.0.0)), https://www.cisecurity.org/cis-benchmarks (accessed Oct 29, 2026).

27. community.vmware changelog, 7.0.0 (removal of vmware_vm_inventory; use vmware.vmware.vms), https://github.com/ansible-collections/community.vmware/blob/main/CHANGELOG.rst; and vmware.vmware collection, vms inventory plugin (“Create an inventory containing VMware VMs”), https://github.com/ansible-collections/vmware.vmware (both accessed Oct 29, 2026).

28. vmware.vmware_rest collection, vcenter_vm_info module (“Gather information about virtual machines in vCenter”), https://github.com/ansible-collections/vmware.vmware_rest (accessed Oct 29, 2026).

29. Ansible documentation, infoblox.nios_modules collection, “nios_lookup” and “nios_next_ip” lookup plugins (WAPI; requirement infoblox-client), https://docs.ansible.com/projects/ansible/latest/collections/infoblox/nios_modules/index.html; checked against the plugin sources and README in the infobloxopen/infoblox-ansible repository (accessed Oct 29, 2026).

30. Ansible documentation, “Managing Windows hosts with Ansible” (connection plugins psrp, ssh and winrm), https://docs.ansible.com/projects/ansible/latest/os_guide/intro_windows.html; checked against its source, docs/docsite/rst/os_guide/intro_windows.rst in the ansible-documentation repository (accessed Oct 29, 2026).

31. Ansible documentation, “Windows SSH” (official support added in version 2.18; OpenSSH requirements), https://docs.ansible.com/projects/ansible/latest/os_guide/windows_ssh.html; checked against its source, os_guide/windows_ssh.rst (accessed Oct 29, 2026).

32. Microsoft Learn, “Azure Connected Machine agent deployment options” (Ansible row; the agent can’t be installed on an Azure VM), https://learn.microsoft.com/azure/azure-arc/servers/deployment-options (accessed Oct 29, 2026).

33. Inventory plugin documentation for amazon.aws.aws_ec2 (“EC2 inventory source”), google.cloud.gcp_compute (“Google Cloud Compute Engine inventory source”) and azure.azcollection.azure_rm (“Azure Resource Manager inventory plugin”), published under https://docs.ansible.com/projects/ansible/latest/collections/; checked against the plugin sources in each collection’s repository (accessed Oct 29, 2026).

34. Red Hat, “Red Hat Ansible Automation Platform Life Cycle” (versions 2.5 to 2.7, support phases and dates; ansible-core in each version; install methods by version), https://access.redhat.com/support/policy/updates/ansible-automation-platform, dates confirmed in the Red Hat Product Life Cycle API (accessed Oct 29, 2026).

35. Red Hat, “Red Hat Ansible Automation Platform Life Cycle” (versions 2.5 to 2.7, support phases and dates; ansible-core in each version; install methods by version), https://access.redhat.com/support/policy/updates/ansible-automation-platform, dates confirmed in the Red Hat Product Life Cycle API (accessed Oct 29, 2026).

36. Ansible documentation, “Releases and maintenance,” ansible-core support matrix, https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html; checked against its source, reference_appendices/release_and_maintenance.rst in the ansible-documentation repository, last changed Oct 27, 2026 (accessed Oct 29, 2026).

37. Red Hat, “Red Hat Ansible Automation Platform Life Cycle” (versions 2.5 to 2.7, support phases and dates; ansible-core in each version; install methods by version), https://access.redhat.com/support/policy/updates/ansible-automation-platform, dates confirmed in the Red Hat Product Life Cycle API (accessed Oct 29, 2026).

38. Red Hat, Ansible Automation Platform 2.7, “Install containerized Ansible Automation Platform” (rootless containers by default) and “Install on OpenShift Container Platform,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

39. Red Hat, Ansible Automation Platform 2.7, “Pluggable authentication,” “Mandatory platform gateway authentication in Ansible Automation Platform 2.7” and “View, create, and assign roles to grant user access to resources,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

40. FedRAMP, “Marketplace Products” (product data searched for Ansible and for Red Hat offerings), https://www.fedramp.gov/marketplace/products/ (accessed Oct 29, 2026).

41. Red Hat Customer Portal, “FedRAMP” (FedRAMP applies only to the listed products: Red Hat OpenShift Service on AWS with hosted control planes, its classic architecture, and Red Hat Lightspeed; available through AWS GovCloud), https://access.redhat.com/compliance/fedramp (accessed Oct 29, 2026).

42. FedRAMP, “Marketplace Products” (product data searched for Ansible and for Red Hat offerings), https://www.fedramp.gov/marketplace/products/ (accessed Oct 29, 2026).

43. Red Hat, “Red Hat Ansible Automation Platform on Microsoft Azure Guide” (managed application from Azure Marketplace in the customer’s tenant; Red Hat access limited to the managed resource group; supported regions), https://docs.redhat.com/en/documentation/ansible_on_clouds/2.x/html-single/red_hat_ansible_automation_platform_on_microsoft_azure_guide/index (accessed Oct 29, 2026).

44. FedRAMP Marketplace, “Red Hat OpenShift Service on AWS (ROSA),” package FR2102031769 (FedRAMP Certified; High; bundled services), https://www.fedramp.gov/marketplace/products/FR2102031769/ (accessed Oct 29, 2026).

45. Red Hat Customer Portal, “FedRAMP” (FedRAMP applies only to the listed products: Red Hat OpenShift Service on AWS with hosted control planes, its classic architecture, and Red Hat Lightspeed; available through AWS GovCloud), https://access.redhat.com/compliance/fedramp (accessed Oct 29, 2026).

46. FedRAMP, “Marketplace Products” (product data searched for Ansible and for Red Hat offerings), https://www.fedramp.gov/marketplace/products/ (accessed Oct 29, 2026).

47. Red Hat Customer Portal, “FIPS” (FIPS 140 certificates for RHEL cryptographic modules; applicability to other Red Hat products running unmodified), https://access.redhat.com/compliance/fips (accessed Oct 29, 2026).

48. Red Hat, Ansible Automation Platform 2.5, “Release notes” (known issue AAP-39146, platform gateway on FIPS-enabled RHEL 9; fix in the April 9, 2025 update; AAP-16456 and AAP-50443), https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html-single/release_notes/index (accessed Oct 29, 2026).

49. National Institute of Standards and Technology, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, controls CM-2 and CM-6 (statement and discussion: organization-defined common secure configurations; documented and approved deviations; who develops common secure configurations), https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; read from NIST’s OSCAL Rev. 5 catalog, https://github.com/usnistgov/oscal-content/tree/main/nist.gov/SP800-53/rev5 (accessed Oct 29, 2026).

50. National Institute of Standards and Technology, SP 800-70 Rev. 5, National Checklist Program for IT Products: Guidelines for Checklist Users and Developers, May 2026, https://csrc.nist.gov/pubs/sp/800/70/r5/final; and NIST, “National Checklist Program,” https://csrc.nist.gov/projects/national-checklist-program (repository at https://ncp.nist.gov/) (accessed Oct 29, 2026).

51. Cybersecurity and Infrastructure Security Agency, “Secure Cloud Business Applications (SCuBA) Project” (baselines for Microsoft 365 and Google Workspace; ScubaGear and ScubaGoggles assessment tools), https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project (accessed Oct 29, 2026).

52. Red Hat, Security hardening, RHEL 9 (SCAP Security Guide profiles, including the CIS Level 1 and Level 2 Server and Workstation profiles), https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/security_hardening/index (accessed Oct 29, 2026).

53. Red Hat, Security hardening, RHEL 9, section 7.5, and RHEL 10, section 5.3.2, “Remediating the system to align with a specific baseline by using an SSG Ansible Playbook,” https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/security_hardening/index and https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/security_hardening/index (accessed Oct 29, 2026).

54. Center for Internet Security, “CIS Benchmarks” (description; benchmark list, including Red Hat Enterprise Linux 9 (3.0.0) and 10 (1.0.1), Microsoft Windows Server 2022 (5.1.0) and 2025 (2.1.0), and VMware ESXi 8.0 (1.4.0) and 9.0 (1.0.0)), https://www.cisecurity.org/cis-benchmarks (accessed Oct 29, 2026).

55. Ansible Lockdown (sponsored by MindPoint Group), GitHub organization, CIS roles such as RHEL9-CIS, RHEL10-CIS, Windows-2022-CIS and their -Audit counterparts, https://github.com/ansible-lockdown (accessed Oct 29, 2026).

56. Ansible Lockdown, “RHEL9-CIS” README (“Automated CIS Benchmark Compliance Remediation for RHEL 9 with Ansible”; CIS RHEL 9 Benchmark v2.0.0; “will make changes to the system”; developed against a clean install), https://github.com/ansible-lockdown/RHEL9-CIS; and “RHEL9-CIS-Audit” README (audit with goss; CIS 2.0.0), https://github.com/ansible-lockdown/RHEL9-CIS-Audit (accessed Oct 29, 2026).

57. Center for Internet Security, “CIS Benchmarks” (description; benchmark list, including Red Hat Enterprise Linux 9 (3.0.0) and 10 (1.0.1), Microsoft Windows Server 2022 (5.1.0) and 2025 (2.1.0), and VMware ESXi 8.0 (1.4.0) and 9.0 (1.0.0)), https://www.cisecurity.org/cis-benchmarks (accessed Oct 29, 2026).

58. Red Hat, Ansible Automation Platform 2.7, “Ensure compliance with host-level security controls” and “Automate nodes that comply with security profiles,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

59. Red Hat Customer Portal, “DISA STIG” (published Red Hat STIGs, including Red Hat Ansible Automation Controller), https://access.redhat.com/compliance/disa-stig (accessed Oct 29, 2026).

60. Red Hat Blog, “DISA releases the first Ansible STIG,” April 11, 2023, https://www.redhat.com/en/blog/disa-releases-first-ansible-stig (accessed Oct 29, 2026).

61. Red Hat, Ansible Automation Platform 2.7, “Install containerized Ansible Automation Platform” (rootless containers by default) and “Install on OpenShift Container Platform,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

62. Red Hat, “Which Red Hat Ansible Automation Platform deployment option is right for you?” (managed and self-managed offers on AWS, Azure, Google Cloud and Oracle), https://www.redhat.com/en/technologies/management/ansible/ansible-deployment-options (accessed Oct 29, 2026).

63. Red Hat, “Red Hat Ansible Automation Platform on Microsoft Azure Guide” (managed application from Azure Marketplace in the customer’s tenant; Red Hat access limited to the managed resource group; supported regions), https://docs.redhat.com/en/documentation/ansible_on_clouds/2.x/html-single/red_hat_ansible_automation_platform_on_microsoft_azure_guide/index (accessed Oct 29, 2026).

64. Red Hat, “Red Hat Ansible Automation Platform Service on AWS” (control plane in Red Hat’s infrastructure; execution plane in the customer’s network; job logs erased every 30 days; regions), https://docs.redhat.com/en/documentation/ansible_on_clouds/2.x/html-single/red_hat_ansible_automation_platform_service_on_aws/index (accessed Oct 29, 2026).

65. Red Hat, “Red Hat Ansible Automation Platform on Microsoft Azure Guide” (managed application from Azure Marketplace in the customer’s tenant; Red Hat access limited to the managed resource group; supported regions), https://docs.redhat.com/en/documentation/ansible_on_clouds/2.x/html-single/red_hat_ansible_automation_platform_on_microsoft_azure_guide/index (accessed Oct 29, 2026).

66. Red Hat, “Red Hat Ansible Automation Platform Service on AWS” (control plane in Red Hat’s infrastructure; execution plane in the customer’s network; job logs erased every 30 days; regions), https://docs.redhat.com/en/documentation/ansible_on_clouds/2.x/html-single/red_hat_ansible_automation_platform_service_on_aws/index (accessed Oct 29, 2026).

67. Amazon Web Services, “FedRAMP” (US East/West FedRAMP Certified Class C, formerly Moderate; GovCloud (US) Class D, formerly High), https://aws.amazon.com/compliance/fedramp/; and “FedRAMP — Services in Scope” (per-service, per-Region columns), https://aws.amazon.com/compliance/services-in-scope/FedRAMP/ (accessed Oct 29, 2026).

68. Red Hat, Ansible Automation Platform 2.7, “Pluggable authentication,” “Mandatory platform gateway authentication in Ansible Automation Platform 2.7” and “View, create, and assign roles to grant user access to resources,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

69. Red Hat, Ansible Automation Platform 2.7, “Configure access to external applications with tokens” (gateway-issued tokens; default access-token expiry changed from 1,000 years to 1 year; earlier tokens keep their lifetime), https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

70. Red Hat, Ansible Automation Platform 2.7, “Send log files to third-party aggregation services” and “Configure third-party services” (Splunk, Loggly, Sumologic, Elastic; the most useful data), https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

71. Red Hat, Ansible Automation Platform 2.7, “View activity streams for all resources,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

72. Red Hat, Ansible Automation Platform 2.7, “Best practices for setting up secure logging,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

73. Red Hat, Ansible Automation Platform 2.5, Configuring automation execution, management jobs (Cleanup Activity Stream, Cleanup Job Details; days of data to keep), https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html-single/configuring_automation_execution/index (accessed Oct 29, 2026).

74. Red Hat, Ansible Automation Platform 2.7, “Red Hat Certified, validated, and Ansible Galaxy content in automation hub,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

75. Red Hat, Ansible Automation Platform 2.7, “Enable automation content collection and container signing” (disabled by default), “Configure content signing on private automation hub” (clients opt in with a keyring) and “Post-Quantum Cryptography signing in automation hub,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

76. Red Hat, Ansible Automation Platform 2.7, “Enable automation content collection and container signing” (disabled by default), “Configure content signing on private automation hub” (clients opt in with a keyring) and “Post-Quantum Cryptography signing in automation hub,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

77. Red Hat, Ansible Automation Platform 2.7, “Enforce project integrity with signing and verification,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

78. Red Hat, Ansible Automation Platform 2.7, “Trigger automation with webhooks” (GitHub and GitLab), https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

79. Red Hat, Ansible Automation Platform 2.7, “Credential types” and “Integrate third-party secret management systems,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

80. Red Hat, Ansible Automation Platform 2.7, “OIDC credential types for HashiCorp Vault,” https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/ (accessed Oct 29, 2026).

81. Ansible documentation, “Ansible Vault” (encrypts variables and files; protects only data at rest), https://docs.ansible.com/projects/ansible/latest/vault_guide/vault.html; checked against its source, vault_guide/vault.rst (accessed Oct 29, 2026).

82. Ansible documentation, “Logging Ansible output” (no_log: True on tasks that expose secrets; no_log doesn’t affect debugging output), https://docs.ansible.com/projects/ansible/latest/reference_appendices/logging.html; checked against its source (accessed Oct 29, 2026).

83. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, release 5.2.0 (August 27, 2025), controls CM-2, CM-3, CM-6, CM-7, CM-8, AU-2, AU-12, AC-6, AC-6(5), SR-3, SR-11 and withdrawn SA-12 (incorporated into the SR family), https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; titles and withdrawal read from NIST’s OSCAL Rev. 5 catalog, version 5.2.0, and the Moderate baseline profile, https://github.com/usnistgov/oscal-content/tree/main/nist.gov/SP800-53/rev5 (accessed Oct 29, 2026).

84. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, release 5.2.0 (August 27, 2025), controls CM-2, CM-3, CM-6, CM-7, CM-8, AU-2, AU-12, AC-6, AC-6(5), SR-3, SR-11 and withdrawn SA-12 (incorporated into the SR family), https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; titles and withdrawal read from NIST’s OSCAL Rev. 5 catalog, version 5.2.0, and the Moderate baseline profile, https://github.com/usnistgov/oscal-content/tree/main/nist.gov/SP800-53/rev5 (accessed Oct 29, 2026).

85. Ansible documentation, “Validating tasks: check mode and diff mode” (check mode makes no changes; modules without check-mode support report nothing and do nothing; check mode is a simulation; check_mode per task; --diff and sensitive information), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_checkmode.html; checked against its source, playbook_guide/playbooks_checkmode.rst (accessed Oct 29, 2026).

86. Ansible documentation, “Patterns: targeting hosts and groups” (--limit), https://docs.ansible.com/projects/ansible/latest/inventory_guide/intro_patterns.html; checked against its source, inventory_guide/intro_patterns.rst (accessed Oct 29, 2026).

87. Ansible documentation, “Controlling playbook execution: strategies and more” (serial as a number, percentage or list; failure scope per batch; throttle; run_once), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_strategies.html; checked against its source, playbook_guide/playbooks_strategies.rst (accessed Oct 29, 2026).

88. Ansible documentation, “Error handling in playbooks” (any_errors_fatal; max_fail_percentage applies per batch with serial and must be exceeded, not equaled; changed_when), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_error_handling.html; checked against its source, playbook_guide/playbooks_error_handling.rst (accessed Oct 29, 2026).

89. Ansible documentation, “Validating tasks: check mode and diff mode” (check mode makes no changes; modules without check-mode support report nothing and do nothing; check mode is a simulation; check_mode per task; --diff and sensitive information), https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_checkmode.html; checked against its source, playbook_guide/playbooks_checkmode.rst (accessed Oct 29, 2026).

90. Ansible documentation, “Working with dynamic inventory” (inventory plugins recommended over scripts), https://docs.ansible.com/projects/ansible/latest/inventory_guide/intro_dynamic_inventory.html; checked against its source, inventory_guide/intro_dynamic_inventory.rst (accessed Oct 29, 2026).

91. Ansible documentation, “ansible.builtin.constructed inventory” (groups and variables from existing inventory with Jinja2; only variables from earlier inventories or the fact cache), https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/constructed_inventory.html; checked against the plugin source in ansible-core 2.21 (accessed Oct 29, 2026).

92. Ansible documentation, “Logging Ansible output” (no_log: True on tasks that expose secrets; no_log doesn’t affect debugging output), https://docs.ansible.com/projects/ansible/latest/reference_appendices/logging.html; checked against its source (accessed Oct 29, 2026).

93. Ansible documentation, “Glossary,” Galaxy (“finding and sharing Ansible community content”), https://docs.ansible.com/projects/ansible/latest/reference_appendices/glossary.html; checked against its source (accessed Oct 29, 2026).

94. Ansible documentation, “Installing collections” (requirements files and version ranges; latest version by default; signature verification with --keyring, only for collections installed from a distribution server), https://docs.ansible.com/projects/ansible/latest/collections_guide/collections_installing.html; checked against its source (accessed Oct 29, 2026).

95. Ansible documentation, “Verifying collections” (ansible-galaxy collection verify; signed collections), https://docs.ansible.com/projects/ansible/latest/collections_guide/collections_verifying.html; checked against its source (accessed Oct 29, 2026).

96. Ansible documentation, “ansible.builtin.command module,” Attributes (check mode supported only with creates or removes), https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/command_module.html; checked against the module source in ansible-core 2.21 (accessed Oct 29, 2026).

97. Ansible Lint documentation, “Profiles” (min, basic, moderate, safety, shared, production) and the rules no-changed-when, risky-shell-pipe and fqcn, https://docs.ansible.com/projects/lint/profiles/; checked against its source in the ansible/ansible-lint repository (accessed Oct 29, 2026).

98. Ansible Lint documentation, “Profiles” (min, basic, moderate, safety, shared, production) and the rules no-changed-when, risky-shell-pipe and fqcn, https://docs.ansible.com/projects/lint/profiles/; checked against its source in the ansible/ansible-lint repository (accessed Oct 29, 2026).