Someone pushes a merge request, the CI pipeline runs, but then deploys stall behind a pile of IAM permissions and half-forgotten service accounts no one wants to touch. That’s the situation most teams face right before automating infrastructure on Google Cloud with GitLab CI. It should feel easy. Instead, it feels like crossing a minefield of YAML files.
GitLab CI handles build and test beautifully. Google Cloud Deployment Manager defines infrastructure declaratively, versioned like code. Together, they promise repeatable environments with zero manual clicking. The gap between promise and reality comes down to credentials, roles, and how those get injected during automation.
The workflow works like this: GitLab CI uses service identities to trigger deployments in Google Cloud. Deployment Manager reads configuration templates (usually in YAML or Jinja), then applies them using APIs governed by IAM policies. When authentication is set through OpenID Connect (OIDC), tokens can be scoped tightly and rotated automatically. That avoids the nightmare of long-lived keys sitting in repos.
To connect GitLab CI and Google Cloud Deployment Manager securely, create a workload identity pool in Google Cloud and map it to your GitLab project’s OIDC. That link turns each pipeline job into a verifiable identity without storing secrets. Once configured, the CI job can apply templates, update instances, or roll out environment changes using fine-grained roles.
Common pain points include permission mismatches and token expiration during long deploys. The fix is simple: define short-lived access scopes and use retry logic inside the deployment scripts. Audit logs will show who triggered what, down to the minute, and compliance teams can actually read them instead of guessing.