Ansible google.cloud Collection 2026: Cloud Build, Parameter Manager, and Storage Guide

What's New in the google.cloud Collection for 2026

At Red Hat Tech Day Netherlands 2026, held in Bunnik on 3 June 2026, the Ansible team unveiled 12 new content collections designed to extend Ansible Automation Platform (AAP) 2.7 across four pillars: Efficiency, Resilience, Governance, and Scale. Among the headline announcements was a significantly expanded google.cloud collection, bringing deeper coverage of five core Google Cloud Platform (GCP) services: Cloud Build 2nd gen, Parameter Manager, Compute, Secret Manager, and Storage.

For platform teams running multi-cloud estates alongside Azure and on-prem infrastructure, this update matters. It closes long-standing gaps in build-pipeline automation and centralized configuration management on GCP, while aligning the collection's module set more closely with what teams already automate on AWS and Azure through Ansible.

This guide walks through what the refreshed google.cloud collection covers, how each service area fits into a typical automation workflow, and a realistic playbook example to get started.

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

Why This Update Matters

Google Cloud has historically lagged behind AWS and Azure in first-party Ansible collection depth, particularly around newer services like Cloud Build 2nd gen and Parameter Manager. Teams standardizing on AAP 2.7 for governance and RBAC across clouds needed consistent module coverage to avoid falling back to raw gcloud CLI calls or custom scripts wrapped in ansible.builtin.command. The 2026 collection refresh directly addresses that gap, letting playbooks manage GCP build pipelines, secrets, and storage with the same idempotent, declarative approach already used for compute and networking.

The Five Service Areas at a Glance

Cloud Build 2nd Gen Automation

Cloud Build 2nd gen introduces tighter integration with source repositories and more flexible trigger configuration than the original generation. With the updated google.cloud collection, teams can define build triggers and pipeline settings declaratively rather than clicking through the GCP console or maintaining Terraform-only definitions disconnected from the rest of their Ansible-managed estate.

A typical use case is provisioning a build trigger tied to a GitHub or Cloud Source Repositories connection whenever a new microservice repository is onboarded — keeping CI/CD bootstrap in the same automation fabric as infrastructure provisioning.

See also: Ansible azure.azcollection Guide: Machine Learning, App Configuration, and Front Door in AAP 2.7

Parameter Manager: Centralized Configuration at Scale

Parameter Manager is the newest addition to the lineup and fills a real operational need: a single, versioned source of truth for application configuration values that isn't secret material (that's what Secret Manager is for) but still needs environment-aware management — think feature flags, service endpoints, and tuning values. Automating parameter creation and updates through Ansible means configuration changes can be reviewed, versioned, and rolled out through the same pipelines as infrastructure changes, rather than being manually edited in a console.

Secret Manager and Storage: Governance Essentials

Secret Manager module coverage extends to secret creation, version management, and IAM policy bindings, letting teams enforce least-privilege access to credentials as part of routine playbook runs rather than a manual afterthought. Combined with Storage module coverage for bucket lifecycle rules, object management, and access policies, this pairing gives governance-focused teams a consistent way to enforce retention, encryption, and access controls across both secrets and object storage — a common audit requirement in regulated industries.

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

Example Playbook: Provisioning Storage and a Build Trigger

The following illustrative playbook shows the kind of workflow this collection enables: creating a versioned storage bucket for build artifacts, then registering a Cloud Build trigger that references it.

---
- name: Provision GCP build artifact storage and CI trigger
  hosts: localhost
  connection: local
  vars:
    gcp_project: "acme-platform-prod"
    gcp_region: "europe-west4"

  tasks:
    - name: Create artifact storage bucket
      google.cloud.gcp_storage_bucket:
        name: acme-build-artifacts
        project: "{{ gcp_project }}"
        location: "{{ gcp_region }}"
        storage_class: STANDARD
        versioning:
          enabled: true
        auth_kind: serviceaccount
        service_account_file: "{{ gcp_service_account_file }}"
        state: present

    - name: Store build notification webhook as a parameter
      google.cloud.gcp_parametermanager_parameter:
        name: build-notification-webhook
        project: "{{ gcp_project }}"
        parameter_data: "https://hooks.acme.internal/build-notify"
        format: UNFORMATTED
        auth_kind: serviceaccount
        service_account_file: "{{ gcp_service_account_file }}"
        state: present

    - name: Register Cloud Build 2nd gen trigger for microservice repo
      google.cloud.gcp_cloudbuild_trigger:
        name: acme-checkout-service-trigger
        project: "{{ gcp_project }}"
        location: "{{ gcp_region }}"
        github:
          owner: acme-org
          name: checkout-service
          push:
            branch: "^main$"
        filename: cloudbuild.yaml
        auth_kind: serviceaccount
        service_account_file: "{{ gcp_service_account_file }}"
        state: present

This kind of playbook can be wrapped as an AAP job template, gated by RBAC, and triggered from a source-control webhook via Event-Driven Ansible — extending the same governance model teams are already applying to other clouds under AAP 2.7.

Fitting Into a Multi-Cloud AAP 2.7 Strategy

The google.cloud refresh doesn't exist in isolation. It was announced alongside an equally significant azure.azcollection update (covering Azure ML, App Configuration, Front Door, Storage, and Arc/HCI) and a hashicorp.vault collection update adding OIDC, PKI, and dynamic credentials with EDA integration. Teams running hybrid or multi-cloud environments should treat these as a coordinated set: consistent secret handling via Vault or Secret Manager, consistent storage governance, and consistent CI/CD provisioning, all orchestrated and RBAC-controlled through ansible.platform's configuration-as-code improvements in AAP 2.7.

Key Takeaways

• The google.cloud collection update announced at Red Hat Tech Day Netherlands 2026 (Bunnik, 3 June 2026) expands coverage to Cloud Build 2nd gen, Parameter Manager, Compute, Secret Manager, and Storage.
• Cloud Build 2nd gen automation lets teams define build triggers and pipelines as code alongside infrastructure.
• Parameter Manager gives teams a versioned, non-secret configuration store that fits naturally into existing playbook-driven change control.
• Secret Manager and Storage module coverage work together to enforce access governance and retention policies consistently.
• This update is part of a broader 12-collection release for AAP 2.7 spanning GCP, Azure, HashiCorp Vault, Cisco Intersight, Splunk, Microsoft endpoint management, and validated Windows/MECM operational roles.
• Combine google.cloud automation with AAP 2.7's RBAC and configuration-as-code improvements for consistent multi-cloud governance.