{"id":708,"date":"2026-04-15T02:52:24","date_gmt":"2026-04-15T02:52:24","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-infrastructure-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-infrastructure-as-code\/"},"modified":"2026-04-15T02:52:24","modified_gmt":"2026-04-15T02:52:24","slug":"google-cloud-infrastructure-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-infrastructure-as-code","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-infrastructure-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-infrastructure-as-code\/","title":{"rendered":"Google Cloud Infrastructure Manager Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Infrastructure as code"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Infrastructure as code<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Infrastructure Manager is Google Cloud\u2019s managed <strong>Infrastructure as code<\/strong> service for provisioning and managing Google Cloud resources using <strong>Terraform<\/strong> configurations. It provides a Google-managed way to run Terraform \u201cplan\/apply\/destroy\u201d-style workflows as a cloud service, with Google Cloud IAM, logging, and governance wrapped around the deployment lifecycle.<\/p>\n\n\n\n<p>In simple terms: you write Terraform, store it in a supported source (for example, a Cloud Storage bucket or a Git repository, depending on what your organization standardizes on), and Infrastructure Manager creates and updates your Google Cloud infrastructure in a controlled, auditable way\u2014without you having to run Terraform from a laptop or maintain your own state backend tooling.<\/p>\n\n\n\n<p>Technically, Infrastructure Manager is a Google Cloud API and control plane that orchestrates Terraform operations against Google Cloud APIs using an execution identity (service account) you choose. It keeps track of deployments, revisions\/operations, and surfaces status and logs via Google Cloud\u2019s operational tooling. This makes Terraform-based provisioning more consistent across teams, especially in regulated environments where you want stronger auditability and least-privilege execution.<\/p>\n\n\n\n<p>The core problem it solves is the operational friction of running Terraform at scale: coordinating state, permissions, audit logs, repeatable deployments, and consistent execution environments\u2014while integrating tightly with Google Cloud IAM and governance.<\/p>\n\n\n\n<blockquote>\n<p>Note on naming and legacy services: Google Cloud historically offered <strong>Deployment Manager<\/strong> (a separate, older Infrastructure as code product). Many teams consider Infrastructure Manager the modern, Terraform-aligned approach. Always verify current product lifecycle status and guidance in official docs:<br\/>\nhttps:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Infrastructure Manager?<\/h2>\n\n\n\n<p>Infrastructure Manager is a Google Cloud service whose official purpose is to <strong>deploy and manage Google Cloud infrastructure using Terraform configurations<\/strong>, as a managed service.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose (what it\u2019s for)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run Terraform-based infrastructure provisioning as a managed Google Cloud service.<\/li>\n<li>Standardize and audit how infrastructure changes are planned and applied.<\/li>\n<li>Use Google Cloud IAM and service accounts to control who can change infrastructure and what the deployment engine is allowed to do.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (high level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create and manage <strong>deployments<\/strong> from Terraform configuration sources.<\/li>\n<li>Apply updates by creating new <strong>revisions\/operations<\/strong> (terminology can vary\u2014verify exact resource model in docs).<\/li>\n<li>Use an execution <strong>service account<\/strong> to perform changes in a controlled, least-privilege way.<\/li>\n<li>Integrate with Google Cloud <strong>Logging<\/strong> and <strong>Audit Logs<\/strong> for visibility.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deployment<\/strong>: A managed \u201cstack\u201d of infrastructure defined by Terraform.<\/li>\n<li><strong>Source<\/strong>: Where Terraform configuration is retrieved from (commonly Cloud Storage; other sources may be supported\u2014verify in official docs).<\/li>\n<li><strong>Execution identity<\/strong>: A service account used by Infrastructure Manager to call Google Cloud APIs via Terraform providers.<\/li>\n<li><strong>Operations\/Revisions<\/strong>: The actions that run (plan\/apply\/delete), their status, and their logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Managed control-plane service (Google Cloud API) that orchestrates Terraform executions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (how it\u2019s organized)<\/h3>\n\n\n\n<p>Infrastructure Manager resources are typically:\n&#8211; <strong>Project-scoped<\/strong> (you create deployments in a Google Cloud project).\n&#8211; <strong>Location-scoped<\/strong> (many Google Cloud control-plane services require a \u201clocation\u201d like a region; Infrastructure Manager commonly uses a location field).<br\/>\n  Verify exact location behavior and supported locations here:<br\/>\n  https:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Infrastructure Manager sits in the provisioning layer:\n&#8211; It uses Terraform to call <strong>Google Cloud APIs<\/strong> (Compute Engine, Cloud Storage, IAM, VPC, GKE, etc.).\n&#8211; It leverages <strong>IAM<\/strong> for authorization and <strong>Cloud Audit Logs<\/strong> for governance.\n&#8211; It complements CI\/CD (Cloud Build, GitHub Actions, GitLab CI) by providing a managed execution target for Terraform-based deployments, rather than relying on ad-hoc runners.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Infrastructure Manager?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardization<\/strong>: Consistent, repeatable provisioning across teams and environments.<\/li>\n<li><strong>Audit readiness<\/strong>: Centralized record of changes, who initiated them, and what was changed.<\/li>\n<li><strong>Reduced tool sprawl<\/strong>: Less reliance on bespoke Terraform runners, scripts, and manual state handling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed Terraform execution<\/strong>: Avoid \u201cworks on my machine\u201d differences in Terraform runtime environments.<\/li>\n<li><strong>Clear deployment lifecycle<\/strong>: Track deployments and apply changes as managed operations.<\/li>\n<li><strong>Separation of duties<\/strong>: Developers can propose changes; a controlled system identity applies them.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operational visibility<\/strong>: Easier to locate logs and diagnose failed runs compared to Terraform on a laptop.<\/li>\n<li><strong>Repeatability<\/strong>: Same workflow for dev\/test\/prod with parameterization and consistent policies.<\/li>\n<li><strong>Safer day-2 changes<\/strong>: Updates are applied as explicit, logged operations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege<\/strong>: Use a dedicated execution service account with only the roles needed for the resources in a deployment.<\/li>\n<li><strong>Central IAM control<\/strong>: Control who can create\/update deployments vs who can approve or run them (depending on how you structure IAM and process).<\/li>\n<li><strong>Audit logs<\/strong>: Integrates with Google Cloud auditability patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Team scaling<\/strong>: A platform team can offer Infrastructure Manager as a paved road for Terraform-based provisioning.<\/li>\n<li><strong>Environment scaling<\/strong>: Standard modules and deployments can be rolled out across many projects.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Infrastructure Manager when:\n&#8211; You are standardizing Terraform for Google Cloud.\n&#8211; You want managed execution, consistent identity, and auditable deployment operations.\n&#8211; You\u2019re building a platform engineering model with guardrails and repeatable patterns.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:\n&#8211; You need Terraform features or workflows not supported by Infrastructure Manager\u2019s current integration model (for example, specific backends, custom plugins, or niche provider behaviors\u2014verify current support).\n&#8211; Your organization is already heavily invested in a mature Terraform platform (Terraform Cloud\/Enterprise, self-managed runners with strict controls) and Infrastructure Manager doesn\u2019t add enough value.\n&#8211; You require cross-cloud provisioning where the primary control plane must remain outside Google Cloud (Infrastructure Manager is Google Cloud\u2013centric).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Infrastructure Manager used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services and insurance (strong audit and change controls)<\/li>\n<li>Healthcare and life sciences (compliance and traceability)<\/li>\n<li>Public sector (governance, least privilege)<\/li>\n<li>SaaS and tech companies (repeatable environments, multi-project setups)<\/li>\n<li>Retail and media (fast environment provisioning for campaigns and scaling)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams providing \u201cgolden paths\u201d<\/li>\n<li>DevOps\/SRE teams standardizing infrastructure workflows<\/li>\n<li>Security engineering teams requiring controlled provisioning identities<\/li>\n<li>Application teams that need reliable environment creation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Networking foundations (VPC, subnets, firewall rules, Cloud NAT\u2014note: NAT has cost)<\/li>\n<li>Identity foundations (service accounts, IAM bindings)<\/li>\n<li>Storage (Cloud Storage buckets, IAM policies)<\/li>\n<li>Compute and runtime (Compute Engine, GKE, Cloud Run\u2014runtime costs apply)<\/li>\n<li>Data platforms (BigQuery datasets, Pub\/Sub topics\u2014service-specific costs apply)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures and contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-project landing zones (shared VPC, centralized logging, security projects)<\/li>\n<li>Environment-per-branch or environment-per-tenant patterns (with careful quota\/cost controls)<\/li>\n<li>Standard \u201cblueprints\u201d for product teams<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: Use Infrastructure Manager to spin up consistent environments quickly with tight cleanup.<\/li>\n<li><strong>Production<\/strong>: Use it to enforce repeatable, reviewed changes and strong audit trails, typically with promotion workflows (e.g., apply to dev \u2192 stage \u2192 prod using the same module and different variables).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Infrastructure Manager fits well.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Project bootstrap (baseline resources)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Every new Google Cloud project needs consistent baseline configuration.<\/li>\n<li><strong>Why it fits<\/strong>: Terraform modules can define baseline IAM, logging sinks, buckets, and network scaffolding.<\/li>\n<li><strong>Example<\/strong>: Create a \u201cproject baseline\u201d deployment that sets labels, creates a logs bucket\/sink, and configures foundational IAM bindings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Standard VPC and subnet provisioning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: VPC and subnet creation is error-prone when done manually.<\/li>\n<li><strong>Why it fits<\/strong>: Terraform code expresses network topology as versioned code.<\/li>\n<li><strong>Example<\/strong>: A platform team publishes a module that creates a VPC, subnets per region, and firewall rules; app teams consume it via Infrastructure Manager.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Repeatable Cloud Storage bucket patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams need buckets with consistent settings (uniform access, retention policies, labels).<\/li>\n<li><strong>Why it fits<\/strong>: Terraform modules enforce consistent bucket policy patterns.<\/li>\n<li><strong>Example<\/strong>: Provision per-team buckets with uniform bucket-level access and standardized IAM bindings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) IAM service accounts and role bindings<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Least-privilege IAM setup is complex and often inconsistent.<\/li>\n<li><strong>Why it fits<\/strong>: Terraform expresses IAM as code, enabling reviews and change tracking.<\/li>\n<li><strong>Example<\/strong>: Create service accounts for workloads and bind specific roles to specific resource scopes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Shared services in a hub-and-spoke org<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Many projects need shared services (DNS, artifact repos, logging).<\/li>\n<li><strong>Why it fits<\/strong>: Central deployments can provision and manage shared resources.<\/li>\n<li><strong>Example<\/strong>: A \u201cshared-services\u201d deployment manages Artifact Registry repositories and organization-wide logging exports.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Environment provisioning for app teams (dev\/stage\/prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: App teams need consistent infra across environments.<\/li>\n<li><strong>Why it fits<\/strong>: Same Terraform module with different variables per environment.<\/li>\n<li><strong>Example<\/strong>: One module creates a Cloud Run service, service account, and IAM; separate Infrastructure Manager deployments exist per environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Disaster recovery (DR) infrastructure setup<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: DR environments are often out of sync with production.<\/li>\n<li><strong>Why it fits<\/strong>: Terraform ensures DR resources exist and match desired configuration.<\/li>\n<li><strong>Example<\/strong>: A deployment provisions standby networking, minimal compute, and storage replication settings (service-specific).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Security baseline enforcement<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams forget baseline controls (audit sinks, labels, logging).<\/li>\n<li><strong>Why it fits<\/strong>: Infrastructure Manager deployments can serve as \u201cenforced baseline\u201d code.<\/li>\n<li><strong>Example<\/strong>: A security deployment ensures required labels exist and logging export sinks are configured.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Multi-project rollout of standard modules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Rolling out changes to dozens of projects is difficult.<\/li>\n<li><strong>Why it fits<\/strong>: Reuse modules with consistent variables and controlled execution.<\/li>\n<li><strong>Example<\/strong>: A central pipeline triggers Infrastructure Manager applies across multiple projects with project-specific parameters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Migration from manual provisioning to IaC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Existing resources are unmanaged; changes are risky.<\/li>\n<li><strong>Why it fits<\/strong>: Infrastructure Manager provides a managed workflow to adopt Terraform.<br\/>\n<strong>Caveat<\/strong>: Terraform import workflows may require careful handling\u2014verify Infrastructure Manager\u2019s import support in official docs.<\/li>\n<li><strong>Example<\/strong>: Start with a new baseline module for new resources, then progressively import and manage existing ones.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Compliance evidence generation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Auditors need proof of controlled change management.<\/li>\n<li><strong>Why it fits<\/strong>: Operations, logs, and deployment history provide evidence trails.<\/li>\n<li><strong>Example<\/strong>: Produce evidence of who triggered an apply, which service account executed it, and the resulting changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Internal platform \u201ccatalog\u201d of blueprints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams build custom stacks inconsistently.<\/li>\n<li><strong>Why it fits<\/strong>: Offer a small set of blessed Terraform blueprints and deploy them through Infrastructure Manager.<\/li>\n<li><strong>Example<\/strong>: A \u201cGKE standard cluster\u201d blueprint and \u201cCloud Run standard service\u201d blueprint.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability can change (GA vs preview, region availability, source integrations). Verify the latest in official docs:<br\/>\nhttps:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Managed Terraform deployments (deployments and lifecycle)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you define deployments that map to Terraform configurations and manage their lifecycle through Google Cloud.<\/li>\n<li><strong>Why it matters<\/strong>: Brings Terraform into a managed, consistent operational model.<\/li>\n<li><strong>Practical benefit<\/strong>: Less drift in how teams run Terraform; fewer \u201csnowflake\u201d workflows.<\/li>\n<li><strong>Caveat<\/strong>: Terraform feature parity depends on the service\u2019s supported workflow (sources, providers, backends). Verify supported Terraform versions and provider behavior.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Controlled execution identity (service account execution)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Runs provisioning using a designated service account.<\/li>\n<li><strong>Why it matters<\/strong>: Strong security boundary between who requests a deployment and what permissions the deployment engine has.<\/li>\n<li><strong>Practical benefit<\/strong>: Implement least privilege and separation of duties.<\/li>\n<li><strong>Caveat<\/strong>: Misconfigured IAM is the #1 cause of failed applies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with IAM and policy controls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Google Cloud IAM for access to create\/update deployments and to control execution permissions.<\/li>\n<li><strong>Why it matters<\/strong>: Central governance, consistent with the rest of Google Cloud.<\/li>\n<li><strong>Practical benefit<\/strong>: Use IAM roles and organization policies to reduce risk.<\/li>\n<li><strong>Caveat<\/strong>: Organization Policy constraints can block resource creation; failures may look like Terraform errors but are policy-related.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational visibility (logs, status, auditability)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Surfaces deployment operations status and logs through Google Cloud operational tooling.<\/li>\n<li><strong>Why it matters<\/strong>: Makes troubleshooting and audits easier than scattered local Terraform logs.<\/li>\n<li><strong>Practical benefit<\/strong>: Centralized observability; easier incident response.<\/li>\n<li><strong>Caveat<\/strong>: Log content can contain sensitive resource identifiers; apply log access controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Source-based configuration (repeatable inputs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Points deployments at a defined source for Terraform configuration.<\/li>\n<li><strong>Why it matters<\/strong>: Reproducibility\u2014same source + same variables produces the same desired state.<\/li>\n<li><strong>Practical benefit<\/strong>: Promotes GitOps-style workflows and code review.<\/li>\n<li><strong>Caveat<\/strong>: Ensure source integrity and access controls; avoid embedding secrets in Terraform code.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Revisioned changes (history of applies)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Tracks successive updates as operations\/revisions.<\/li>\n<li><strong>Why it matters<\/strong>: You can see what changed and when.<\/li>\n<li><strong>Practical benefit<\/strong>: Easier rollback decision-making and forensic analysis.<\/li>\n<li><strong>Caveat<\/strong>: Rollback is not always automatic; \u201crollback\u201d in Terraform is typically applying a prior configuration version, not an instant revert.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">API-first and CLI support<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Manage deployments via API\/CLI (and Console).<\/li>\n<li><strong>Why it matters<\/strong>: Enables CI\/CD automation and repeatable operational runbooks.<\/li>\n<li><strong>Practical benefit<\/strong>: Integrate into pipelines and platform tooling.<\/li>\n<li><strong>Caveat<\/strong>: CLI command groups and flags can change; always check <code>gcloud<\/code> reference for your installed version.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>At a high level:\n1. You store Terraform configuration in an approved source.\n2. You create an Infrastructure Manager deployment referencing that source and specifying an execution service account.\n3. Infrastructure Manager runs Terraform operations (plan\/apply\/update\/delete) using Google-managed orchestration.\n4. Terraform provider calls Google Cloud resource APIs to create\/update\/delete resources.\n5. Logs and operation results are accessible through Google Cloud Logging and the Infrastructure Manager API.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow (request\/data\/control planes)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: Infrastructure Manager API (create deployment, trigger apply, view status).<\/li>\n<li><strong>Execution plane<\/strong>: Managed Terraform runner invoked by the service (details abstracted).<\/li>\n<li><strong>Data plane<\/strong>: The resources you provision (VPCs, buckets, clusters, etc.), plus any source artifacts and state storage mechanisms (implementation details vary; verify how Infrastructure Manager stores\/handles state in your chosen workflow).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations (depending on your organization\u2019s workflow):\n&#8211; <strong>IAM<\/strong>: for controlling who can administer deployments and what the execution identity can do.\n&#8211; <strong>Cloud Storage<\/strong>: often used for storing Terraform configuration packages (and sometimes state in Terraform workflows; verify Infrastructure Manager\u2019s state handling).\n&#8211; <strong>Cloud Logging &amp; Cloud Audit Logs<\/strong>: for operational logs and audit records.\n&#8211; <strong>Cloud Build \/ CI systems<\/strong>: for triggering deployment updates and promoting changes across environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud APIs for the resources Terraform will manage (e.g., <code>compute.googleapis.com<\/code>, <code>storage.googleapis.com<\/code>).<\/li>\n<li>Identity APIs (IAM) and Resource Manager APIs for permissions and project metadata.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Caller authentication<\/strong>: Users or CI systems authenticate to Google Cloud (OAuth, workload identity federation, etc.) and call Infrastructure Manager API.<\/li>\n<li><strong>Authorization<\/strong>: IAM roles on the project and on Infrastructure Manager resources (deployments).<\/li>\n<li><strong>Execution<\/strong>: Infrastructure Manager uses the specified service account (execution identity) to run Terraform provider calls to resource APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Infrastructure Manager is a control-plane service. The resources it creates can be in your VPCs and subnets as defined by Terraform.<\/li>\n<li>If your Terraform configuration creates private resources, ensure required networking (subnets, routes, NAT) exists and is modeled in code.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Audit Logs<\/strong> to see who triggered changes.<\/li>\n<li>Use <strong>Cloud Logging<\/strong> for operation logs; consider log retention and access.<\/li>\n<li>Apply <strong>labels<\/strong> and consistent naming through Terraform to support cost allocation and governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Engineer \/ CI Pipeline] --&gt;|API\/CLI| IM[Infrastructure Manager API]\n  IM --&gt;|runs Terraform| TF[Managed Terraform Execution]\n  TF --&gt;|calls| GCP[Google Cloud Resource APIs]\n  GCP --&gt; RES[Created Resources\\n(VPC, Buckets, IAM, etc.)]\n  IM --&gt; LOGS[Cloud Logging \/ Audit Logs]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph CI[CI\/CD]\n    PR[Pull Request + Code Review]\n    PIPE[Pipeline (Cloud Build \/ GitHub Actions)]\n  end\n\n  subgraph SRC[Source Control]\n    GIT[Git Repository\\nTerraform Modules]\n    REL[Version Tags \/ Releases]\n  end\n\n  subgraph GOV[Governance]\n    IAM[IAM (Least Privilege)]\n    ORG[Org Policies]\n    AUD[Cloud Audit Logs]\n    LOG[Cloud Logging]\n  end\n\n  subgraph IMPL[Provisioning]\n    IM[Infrastructure Manager\\nDeployments per env\/location]\n    SA[Execution Service Account]\n  end\n\n  subgraph ENVS[Google Cloud Environments]\n    DEV[Dev Project]\n    STG[Stage Project]\n    PRD[Prod Project]\n  end\n\n  PR --&gt; PIPE --&gt;|promote| IM\n  GIT --&gt; REL --&gt; IM\n  IM --&gt;|uses| SA\n  SA --&gt;|Terraform provider calls| DEV\n  SA --&gt;|Terraform provider calls| STG\n  SA --&gt;|Terraform provider calls| PRD\n\n  IAM --&gt; IM\n  ORG --&gt; IM\n  IM --&gt; AUD\n  IM --&gt; LOG\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account and at least one Google Cloud <strong>project<\/strong>.<\/li>\n<li><strong>Billing enabled<\/strong> on the project (some resources you might provision incur costs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions\/IAM roles<\/h3>\n\n\n\n<p>You need two permission sets:\n1. Permissions to <strong>manage Infrastructure Manager deployments<\/strong> (admin\/operator roles for the service).\n2. Permissions for the <strong>execution service account<\/strong> that will create\/update resources.<\/p>\n\n\n\n<p>Because IAM roles evolve, verify current required roles in official docs. Start here:<br\/>\nhttps:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n\n\n\n<p>Practical minimum for the lab in this tutorial (creating a Cloud Storage bucket via Terraform):\n&#8211; Your user: permissions to create service accounts, grant IAM roles, create storage buckets for source, and manage Infrastructure Manager deployments.\n&#8211; Execution service account: permissions to create and manage the target resources (e.g., <code>roles\/storage.admin<\/code> for bucket creation). Prefer narrower roles in real environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Infrastructure provisioning may create billable resources (Compute, NAT, GKE nodes, etc.).<\/li>\n<li>The lab below uses Cloud Storage, which can be very low-cost but not always free (storage and operations pricing applies).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Shell<\/strong> (recommended) or local machine with:<\/li>\n<li><code>gcloud<\/code> CLI installed and authenticated<\/li>\n<li><code>gsutil<\/code> available (included with Cloud SDK)<\/li>\n<li>Optional: Git client (if you use Git-based sources in your workflow).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Infrastructure Manager uses a <strong>location<\/strong> value for deployments in many cases. Supported locations can change.<\/li>\n<li>Verify supported locations in docs before standardizing:<br\/>\n  https:\/\/cloud.google.com\/infrastructure-manager\/docs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Potential quota\/limit areas:\n&#8211; Infrastructure Manager API quotas (requests, concurrent operations).\n&#8211; Terraform-managed resource quotas (e.g., Compute Engine CPUs, IP addresses).\n&#8211; Cloud Storage bucket limits and naming constraints (global namespace).<\/p>\n\n\n\n<p>Always check:\n&#8211; Service quotas: https:\/\/cloud.google.com\/docs\/quota\n&#8211; Product-specific quotas for resources you deploy.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs<\/h3>\n\n\n\n<p>You must enable:\n&#8211; Infrastructure Manager API (exact API service name can vary; enable it from the Console if unsure).\n&#8211; APIs for the resources you provision (e.g., Cloud Storage API).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (what you pay for)<\/h3>\n\n\n\n<p>Pricing for Infrastructure Manager can be nuanced because:\n&#8211; Some managed control-plane services have <strong>no direct cost<\/strong> and you pay only for the resources created.\n&#8211; Some services add charges for operations\/executions, storage, or requests.<\/p>\n\n\n\n<p>To avoid guessing, verify the current pricing model directly in official sources:\n&#8211; Infrastructure Manager docs: https:\/\/cloud.google.com\/infrastructure-manager\/docs\n&#8211; Google Cloud Pricing: https:\/\/cloud.google.com\/pricing\n&#8211; Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<p>If Google provides a dedicated pricing page for Infrastructure Manager in your region\/edition, use that as the primary reference (search within official Google Cloud pricing pages).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Typical pricing dimensions (what drives cost)<\/h3>\n\n\n\n<p>Even if Infrastructure Manager itself has minimal direct charges, your total cost is driven by:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Resources provisioned by Terraform<\/strong>\n   &#8211; Compute Engine VMs, disks, load balancers\n   &#8211; Cloud NAT, VPN, Interconnect\n   &#8211; GKE clusters and node pools\n   &#8211; BigQuery, Pub\/Sub, Cloud SQL, etc.<\/p>\n<\/li>\n<li>\n<p><strong>Cloud Storage<\/strong>\n   &#8211; If you store Terraform configuration bundles or artifacts in Cloud Storage.\n   &#8211; Storage capacity, operations, and network egress (if applicable).<\/p>\n<\/li>\n<li>\n<p><strong>Logging<\/strong>\n   &#8211; Cloud Logging ingestion and retention can generate cost at scale (especially verbose deployment logs).<\/p>\n<\/li>\n<li>\n<p><strong>Networking \/ data transfer<\/strong>\n   &#8211; Cross-region egress, NAT usage, load balancer traffic, etc.\n   &#8211; Terraform itself doesn\u2019t transfer much data, but the deployed architecture might.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<p>Cloud Storage and other services have their own free tiers\/always-free usage in some cases, but coverage varies by region and product. Verify current free tier rules:\n&#8211; https:\/\/cloud.google.com\/free<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud NAT<\/strong> is often created in \u201cprivate\u201d architectures and can become a surprise cost driver.<\/li>\n<li><strong>Load balancers<\/strong> and <strong>public IPs<\/strong> can add fixed and variable charges.<\/li>\n<li><strong>Logging volume<\/strong> from frequent applies across many projects can add up.<\/li>\n<li><strong>CI\/CD<\/strong> runners and artifact storage costs (if you implement pipelines around Infrastructure Manager).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>low-cost resources<\/strong> in dev\/test; turn off or destroy after use.<\/li>\n<li>Use <strong>labels<\/strong> (cost allocation) on all resources through Terraform.<\/li>\n<li>Use separate projects per environment to isolate blast radius and cost accounting.<\/li>\n<li>Avoid creating expensive always-on resources in tutorials (large VMs, NAT, large clusters).<\/li>\n<li>Set log retention and sinks thoughtfully; don\u2019t export everything indefinitely.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (qualitative)<\/h3>\n\n\n\n<p>A starter deployment that only creates:\n&#8211; One Cloud Storage bucket\n&#8211; A few IAM bindings and service accounts<br\/>\n\u2026typically incurs minimal cost, largely tied to Cloud Storage usage and operations. Exact cost depends on region, storage class, and request volume\u2014verify in the Cloud Storage pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, Infrastructure Manager often manages:\n&#8211; VPC + NAT + load balancers + GKE\/Compute<br\/>\nThe bulk of cost is almost always in:\n&#8211; Compute runtime (nodes\/VMs)\n&#8211; Network egress \/ load balancing\n&#8211; Logging volume<br\/>\nInfrastructure Manager becomes an enabler rather than the direct cost center; focus optimization on the deployed architecture.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab provisions a <strong>single Cloud Storage bucket<\/strong> using Terraform executed by <strong>Infrastructure Manager<\/strong>. It\u2019s designed to be safe and low-cost.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable a basic Infrastructure Manager workflow in a Google Cloud project.<\/li>\n<li>Store Terraform configuration in Cloud Storage.<\/li>\n<li>Create an Infrastructure Manager deployment to apply the Terraform and create a bucket.<\/li>\n<li>Validate and then clean up.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare your project and tooling.\n2. Create a source bucket to store Terraform config.\n3. Create an execution service account and grant least-privilege permissions.\n4. Upload Terraform configuration to Cloud Storage.\n5. Create and apply an Infrastructure Manager deployment.\n6. Validate the bucket exists.\n7. Update the deployment once (optional).\n8. Clean up (delete deployment and buckets).<\/p>\n\n\n\n<blockquote>\n<p>Important: Command groups and flags can evolve. If a command differs in your environment, use:<\/p>\n<ul>\n<li><code>gcloud help<\/code><\/li>\n<li><code>gcloud infra-manager --help<\/code> (or the relevant command group)<\/li>\n<li>Official docs: https:\/\/cloud.google.com\/infrastructure-manager\/docs<\/li>\n<\/ul>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set your project and confirm authentication<\/h3>\n\n\n\n<p>In <strong>Cloud Shell<\/strong>, run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth list\ngcloud config list project\n<\/code><\/pre>\n\n\n\n<p>Set your project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\ngcloud config set project \"${PROJECT_ID}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; <code>gcloud config list project<\/code> shows your target project.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the Google Cloud Console, confirm you\u2019re in the right project.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs<\/h3>\n\n\n\n<p>Infrastructure Manager requires its API enabled, plus APIs for resources you manage.<\/p>\n\n\n\n<p>If you know the exact service name for the Infrastructure Manager API in your environment, enable it with <code>gcloud services enable ...<\/code>. If you are not sure, enable it in the Console:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Console \u2192 <strong>APIs &amp; Services<\/strong> \u2192 <strong>Enable APIs and services<\/strong><\/li>\n<li>Search for <strong>Infrastructure Manager<\/strong> and enable the API.<\/li>\n<li>Also ensure <strong>Cloud Storage<\/strong> and <strong>IAM<\/strong> APIs are enabled.<\/li>\n<\/ul>\n\n\n\n<p>Official docs for setup and API enabling:\n&#8211; https:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; APIs show as enabled in the Console.<\/p>\n\n\n\n<p><strong>Common error<\/strong>\n&#8211; <code>PERMISSION_DENIED: Permission denied to enable service<\/code><br\/>\n  Fix: ask a project owner\/admin to enable APIs or grant you permissions.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a Cloud Storage bucket to store Terraform source<\/h3>\n\n\n\n<p>Create a globally unique bucket name:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export RAND_SUFFIX=\"$(date +%s)\"\nexport TF_SOURCE_BUCKET=\"${PROJECT_ID}-im-src-${RAND_SUFFIX}\"\nexport LOCATION=\"us-central1\"   # choose a region appropriate for you\n<\/code><\/pre>\n\n\n\n<p>Create the bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil mb -p \"${PROJECT_ID}\" -l \"${LOCATION}\" \"gs:\/\/${TF_SOURCE_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Bucket is created successfully.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls -b \"gs:\/\/${TF_SOURCE_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create an execution service account (least privilege)<\/h3>\n\n\n\n<p>Create a dedicated service account that Infrastructure Manager will use to apply Terraform.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export IM_SA_NAME=\"im-executor\"\nexport IM_SA_EMAIL=\"${IM_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com\"\n\ngcloud iam service-accounts create \"${IM_SA_NAME}\" \\\n  --display-name=\"Infrastructure Manager execution SA\"\n<\/code><\/pre>\n\n\n\n<p>Grant it permissions to create <strong>Cloud Storage buckets<\/strong> in this project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects add-iam-policy-binding \"${PROJECT_ID}\" \\\n  --member=\"serviceAccount:${IM_SA_EMAIL}\" \\\n  --role=\"roles\/storage.admin\"\n<\/code><\/pre>\n\n\n\n<p>Also allow it to read the Terraform source bucket objects. You can do that at the bucket level (recommended) rather than project-wide:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil iam ch \\\n  \"serviceAccount:${IM_SA_EMAIL}:objectViewer\" \\\n  \"gs:\/\/${TF_SOURCE_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; IAM bindings are updated without error.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud iam service-accounts describe \"${IM_SA_EMAIL}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Security note<\/strong>\n&#8211; For real environments, avoid broad roles like <code>roles\/storage.admin<\/code> unless necessary. Prefer narrower roles and resource-level bindings. This lab uses Storage Admin for simplicity.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create Terraform configuration locally in Cloud Shell<\/h3>\n\n\n\n<p>Create a working directory:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p ~\/im-lab\/tf\ncd ~\/im-lab\/tf\n<\/code><\/pre>\n\n\n\n<p>Create <code>main.tf<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-hcl\">terraform {\n  required_version = \"&gt;= 1.3.0\"\n  required_providers {\n    google = {\n      source  = \"hashicorp\/google\"\n      version = \"&gt;= 4.0\"\n    }\n  }\n}\n\nprovider \"google\" {\n  project = var.project_id\n  region  = var.location\n}\n\nresource \"google_storage_bucket\" \"demo_bucket\" {\n  name                        = var.bucket_name\n  location                    = var.location\n  uniform_bucket_level_access = true\n\n  labels = {\n    managed_by = \"infrastructure-manager\"\n    purpose    = \"tutorial\"\n  }\n}\n<\/code><\/pre>\n\n\n\n<p>Create <code>variables.tf<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-hcl\">variable \"project_id\" {\n  type        = string\n  description = \"Google Cloud project ID\"\n}\n\nvariable \"location\" {\n  type        = string\n  description = \"Bucket location\/region\"\n}\n\nvariable \"bucket_name\" {\n  type        = string\n  description = \"Globally unique bucket name\"\n}\n<\/code><\/pre>\n\n\n\n<p>Create <code>outputs.tf<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-hcl\">output \"bucket_name\" {\n  value = google_storage_bucket.demo_bucket.name\n}\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You have a minimal Terraform configuration that creates a bucket.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">ls -la\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Upload Terraform configuration to Cloud Storage<\/h3>\n\n\n\n<p>Infrastructure Manager commonly uses a packaged source (for example, a ZIP archive in Cloud Storage). Packaging requirements can vary\u2014verify the expected source format in docs.<\/p>\n\n\n\n<p>Create an archive:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cd ~\/im-lab\nzip -r tf-src.zip tf\n<\/code><\/pre>\n\n\n\n<p>Upload it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil cp tf-src.zip \"gs:\/\/${TF_SOURCE_BUCKET}\/sources\/tf-src.zip\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The archive is present in your source bucket.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls \"gs:\/\/${TF_SOURCE_BUCKET}\/sources\/\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create an Infrastructure Manager deployment<\/h3>\n\n\n\n<p>Choose a deployment name and an Infrastructure Manager location (this may or may not be the same as your bucket location; follow official docs for supported locations):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export DEPLOYMENT_NAME=\"im-bucket-lab\"\nexport IM_LOCATION=\"us-central1\"  # verify supported locations for Infrastructure Manager\nexport TARGET_BUCKET=\"${PROJECT_ID}-im-target-${RAND_SUFFIX}\"\n<\/code><\/pre>\n\n\n\n<p>Now create the deployment.<\/p>\n\n\n\n<p>Because <code>gcloud<\/code> command syntax can change, use the official docs and <code>gcloud<\/code> help to confirm the exact flags for:\n&#8211; Source (GCS object)\n&#8211; Execution service account\n&#8211; Input variables<\/p>\n\n\n\n<p>Start by exploring the command group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud infra-manager deployments --help\ngcloud infra-manager deployments create --help\n<\/code><\/pre>\n\n\n\n<p>In many environments, the creation flow looks like:\n&#8211; Create the deployment pointing to the source\n&#8211; Apply it with variables<\/p>\n\n\n\n<p>If your <code>gcloud<\/code> supports passing Terraform inputs as variables\/parameters at apply time, run an apply similar to:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Verify exact flags in your environment; adjust accordingly\ngcloud infra-manager deployments create \"${DEPLOYMENT_NAME}\" \\\n  --location=\"${IM_LOCATION}\" \\\n  --service-account=\"projects\/${PROJECT_ID}\/serviceAccounts\/${IM_SA_EMAIL}\" \\\n  --gcs-source=\"gs:\/\/${TF_SOURCE_BUCKET}\/sources\/tf-src.zip\"\n<\/code><\/pre>\n\n\n\n<p>Then apply\/update with input values (flag names vary by version):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Verify in official docs \/ gcloud help how to pass Terraform variables.\ngcloud infra-manager deployments apply \"${DEPLOYMENT_NAME}\" \\\n  --location=\"${IM_LOCATION}\" \\\n  --inputs=\"project_id=${PROJECT_ID},location=${LOCATION},bucket_name=${TARGET_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p>If your environment uses a different flag schema (for example, separate flags for inputs, or a file of inputs), follow the official guidance:\n&#8211; https:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Infrastructure Manager starts an operation that runs Terraform to create a Cloud Storage bucket.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\nList deployments and describe the deployment:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud infra-manager deployments list --location=\"${IM_LOCATION}\"\ngcloud infra-manager deployments describe \"${DEPLOYMENT_NAME}\" --location=\"${IM_LOCATION}\"\n<\/code><\/pre>\n\n\n\n<p>You should see a status indicating success once the operation completes (status fields vary).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8 (Optional): Update the deployment<\/h3>\n\n\n\n<p>A safe update is to change labels (non-destructive). Edit <code>main.tf<\/code> and add an extra label:<\/p>\n\n\n\n<pre><code class=\"language-hcl\">labels = {\n  managed_by = \"infrastructure-manager\"\n  purpose    = \"tutorial\"\n  env        = \"dev\"\n}\n<\/code><\/pre>\n\n\n\n<p>Re-zip and upload:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cd ~\/im-lab\nzip -r tf-src.zip tf\ngsutil cp tf-src.zip \"gs:\/\/${TF_SOURCE_BUCKET}\/sources\/tf-src.zip\"\n<\/code><\/pre>\n\n\n\n<p>Apply again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud infra-manager deployments apply \"${DEPLOYMENT_NAME}\" \\\n  --location=\"${IM_LOCATION}\" \\\n  --inputs=\"project_id=${PROJECT_ID},location=${LOCATION},bucket_name=${TARGET_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A new operation runs and updates the bucket labels.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil label get \"gs:\/\/${TARGET_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Confirm the bucket exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls -b \"gs:\/\/${TARGET_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p>Confirm it has uniform bucket-level access enabled (one way is to inspect bucket metadata):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls -L -b \"gs:\/\/${TARGET_BUCKET}\" | sed -n '1,120p'\n<\/code><\/pre>\n\n\n\n<p>Also validate deployment status in Infrastructure Manager:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud infra-manager deployments describe \"${DEPLOYMENT_NAME}\" --location=\"${IM_LOCATION}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Error: <code>PERMISSION_DENIED<\/code> during apply<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Execution service account lacks permissions (common).<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Ensure the execution service account has the correct roles for the resources being created.\n&#8211; For this lab, confirm:\n  &#8211; Project IAM binding for <code>roles\/storage.admin<\/code>\n  &#8211; Source bucket objectViewer binding<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Error: Bucket name already exists<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Cloud Storage bucket names are global.<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Change <code>TARGET_BUCKET<\/code> to a new globally unique value and re-apply.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Error: API not enabled<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Required API not enabled (Infrastructure Manager API, Storage API, IAM API).<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Enable in Console \u2192 APIs &amp; Services.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Error: Organization Policy constraint blocks creation<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Org policies (e.g., restrictions on bucket locations, public access prevention requirements).<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Review Organization Policy constraints for the project\/folder\/org and update Terraform configuration accordingly.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Error: Deployment location invalid<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Infrastructure Manager may support only certain locations.<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Verify supported locations in official docs and change <code>IM_LOCATION<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing cost and clutter, delete resources after the lab.<\/p>\n\n\n\n<p>1) Delete the Infrastructure Manager deployment.<\/p>\n\n\n\n<p>Command syntax for deleting and whether it deletes underlying resources can vary. Check:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud infra-manager deployments delete --help\n<\/code><\/pre>\n\n\n\n<p>Then run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud infra-manager deployments delete \"${DEPLOYMENT_NAME}\" \\\n  --location=\"${IM_LOCATION}\" \\\n  --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Verify<\/strong> whether the underlying bucket is removed. If it is not automatically deleted, delete it manually:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil rm -r \"gs:\/\/${TARGET_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p>2) Delete the Terraform source bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil rm -r \"gs:\/\/${TF_SOURCE_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p>3) (Optional) Remove the execution service account if you created it only for the lab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud iam service-accounts delete \"${IM_SA_EMAIL}\" --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; No lab buckets remain, and the deployment is gone.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>small, composable modules<\/strong> rather than one huge Terraform root module.<\/li>\n<li>Separate \u201cfoundation\u201d (networking, IAM baseline) from \u201cworkload\u201d (app-specific) deployments.<\/li>\n<li>Prefer <strong>multi-project<\/strong> architecture for production (separate dev\/stage\/prod projects) to reduce blast radius.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use a <strong>dedicated execution service account per environment<\/strong> (or per deployment class).<\/li>\n<li>Grant least privilege:<\/li>\n<li>Prefer resource-level IAM (bucket-level) over project-wide roles.<\/li>\n<li>Avoid primitive roles (Owner\/Editor) except in isolated sandboxes.<\/li>\n<li>Restrict who can:<\/li>\n<li>Create deployments<\/li>\n<li>Update sources\/inputs<\/li>\n<li>Trigger applies<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Label everything (<code>labels<\/code> in Terraform) for cost allocation and chargeback.<\/li>\n<li>Keep dev\/test deployments small and ephemeral.<\/li>\n<li>Avoid always-on expensive components (NAT, load balancers, large clusters) unless necessary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep Terraform state manageable by splitting deployments by domain (network, IAM, app stack).<\/li>\n<li>Avoid frequent full-environment applies if only a subset changes; structure modules accordingly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat Terraform code as production code:<\/li>\n<li>code review<\/li>\n<li>version pinning for providers<\/li>\n<li>staged rollouts<\/li>\n<li>Use a promotion process: apply to dev \u2192 stage \u2192 prod using the same module version.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize logs:<\/li>\n<li>Ensure deployment operation logs and audit logs are accessible to SRE\/platform teams.<\/li>\n<li>Document runbooks:<\/li>\n<li>common failure modes (IAM, quota, org policy)<\/li>\n<li>rollback approach (re-apply previous version)<\/li>\n<li>Track change history:<\/li>\n<li>tie Infrastructure Manager operations to change requests\/tickets in regulated environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standard naming conventions:<\/li>\n<li>include project, environment, purpose<\/li>\n<li>Standard labels:<\/li>\n<li><code>env<\/code>, <code>owner<\/code>, <code>cost_center<\/code>, <code>app<\/code>, <code>managed_by<\/code><\/li>\n<li>Consider org policy guardrails:<\/li>\n<li>location restrictions<\/li>\n<li>public access prevention<\/li>\n<li>allowed service account usage<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Control-plane access is governed by IAM on the project and Infrastructure Manager resources.<\/li>\n<li>Execution is performed by a service account:<\/li>\n<li>Treat it like a privileged automation identity.<\/li>\n<li>Rotate keys only if you use keys (prefer keyless identities; Infrastructure Manager typically uses service account impersonation rather than long-lived keys).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud encrypts data at rest and in transit by default for most managed services.<\/li>\n<li>If your Terraform sources are in Cloud Storage:<\/li>\n<li>Use uniform bucket-level access<\/li>\n<li>Consider CMEK if required by policy (verify compatibility and organizational requirements).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Infrastructure Manager is a control plane; your deployed resources can be public or private.<\/li>\n<li>Prevent accidental exposure:<\/li>\n<li>avoid public IPs by default<\/li>\n<li>avoid overly permissive firewall rules<\/li>\n<li>enforce private service access patterns where required<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<p>Avoid putting secrets in:\n&#8211; Terraform code\n&#8211; Terraform variables committed to source control\n&#8211; Logs<\/p>\n\n\n\n<p>Recommended patterns:\n&#8211; Use Secret Manager for secrets storage and retrieval (integrate through runtime, not in plain text).\n&#8211; If Terraform must reference secrets, use secure references and keep state exposure in mind. Review your Terraform\/state handling model carefully (verify Infrastructure Manager\u2019s state storage and access patterns in official docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Cloud Audit Logs to track:<\/li>\n<li>Who created\/updated deployments<\/li>\n<li>Who triggered applies<\/li>\n<li>Which service account executed changes<\/li>\n<li>Restrict access to logs if they contain sensitive identifiers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce code review and approval workflows for production applies.<\/li>\n<li>Use separate projects\/accounts for separation of duties.<\/li>\n<li>Document and standardize IAM role assignments for deployment operators.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Using broad roles (Owner\/Editor) for the execution service account.<\/li>\n<li>Storing secrets in Terraform variables and leaking them through state\/logs.<\/li>\n<li>Allowing too many people to trigger applies in production.<\/li>\n<li>Not protecting the Terraform source artifact (anyone who can change source can change infrastructure).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a \u201cplatform provisioning\u201d project pattern:<\/li>\n<li>controlled execution identities<\/li>\n<li>enforced code review<\/li>\n<li>centralized logging<\/li>\n<li>Use organization policies as guardrails.<\/li>\n<li>Use separate deployments for baseline vs workloads to reduce blast radius.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>These points are common in managed Terraform\/IaC services; verify Infrastructure Manager-specific behaviors in official docs:<br\/>\nhttps:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n<\/blockquote>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Location constraints<\/strong>: Deployments often require a supported location; not all regions may be available.<\/li>\n<li><strong>Source packaging requirements<\/strong>: You may need to package Terraform configuration in a specific archive structure.<\/li>\n<li><strong>Terraform version\/provider support<\/strong>: The service may pin or restrict supported Terraform versions or provider behaviors. Verify supported versions.<\/li>\n<li><strong>State handling<\/strong>: Understand where state is stored, who can access it, and how it\u2019s protected. This impacts security and operations.<\/li>\n<li><strong>IAM complexity<\/strong>: Two layers of IAM (caller and execution identity) can be confusing.<\/li>\n<li><strong>Org policies<\/strong>: Organization Policy constraints can block creates\/updates; troubleshoot by checking policy violations.<\/li>\n<li><strong>Quota failures<\/strong>: Applies can fail due to resource quotas (CPU, IPs, API rate limits).<\/li>\n<li><strong>Idempotency expectations<\/strong>: Terraform is declarative, but some resources have non-trivial update semantics (re-creation vs in-place update).<\/li>\n<li><strong>Deletion semantics<\/strong>: Deleting a deployment may or may not automatically delete underlying resources depending on configuration and service behavior\u2014verify before relying on it.<\/li>\n<li><strong>Drift management<\/strong>: If humans change resources outside Terraform, expect drift and potentially surprising diffs on next apply.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">How Infrastructure Manager compares<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Infrastructure Manager (Google Cloud)<\/strong><\/td>\n<td>Terraform-based provisioning with Google-managed orchestration<\/td>\n<td>Managed execution, IAM integration, auditability, consistent deployment model<\/td>\n<td>Support constraints (versions\/sources), location requirements, requires learning new operational model<\/td>\n<td>You want managed Terraform operations tightly integrated with Google Cloud governance<\/td>\n<\/tr>\n<tr>\n<td><strong>Terraform CLI + Remote State (self-managed)<\/strong><\/td>\n<td>Teams already skilled with Terraform and want full flexibility<\/td>\n<td>Maximum flexibility; choose any backend; custom tooling<\/td>\n<td>You must manage runners, credentials, state access, auditing, and standardization<\/td>\n<td>Small teams or mature DevOps shops with established patterns<\/td>\n<\/tr>\n<tr>\n<td><strong>Terraform Cloud \/ Terraform Enterprise<\/strong><\/td>\n<td>Enterprise Terraform platform across clouds<\/td>\n<td>Policy-as-code (Sentinel), runs, workspace model, strong governance<\/td>\n<td>Additional vendor\/platform cost and operations; external platform dependency<\/td>\n<td>Multi-cloud enterprises standardizing Terraform at scale<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Build + Terraform in CI<\/strong><\/td>\n<td>Simple pipeline-driven Terraform with minimal new services<\/td>\n<td>Familiar CI workflow, can be locked down with SA impersonation<\/td>\n<td>Still need state strategy, secrets handling, approvals, and runner hygiene<\/td>\n<td>You want lightweight automation without a dedicated IaC service<\/td>\n<\/tr>\n<tr>\n<td><strong>Config Connector \/ Config Controller (Google Cloud\/Kubernetes)<\/strong><\/td>\n<td>Kubernetes-native resource management (GitOps)<\/td>\n<td>Kubernetes reconciliation model, GitOps workflows<\/td>\n<td>Not Terraform; requires Kubernetes control plane; different skills<\/td>\n<td>Platform teams already all-in on Kubernetes\/GitOps<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CloudFormation (other cloud)<\/strong><\/td>\n<td>AWS-native IaC<\/td>\n<td>Deep AWS integration<\/td>\n<td>Not for Google Cloud; different ecosystem<\/td>\n<td>Only if deploying primarily on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Resource Manager \/ Bicep (other cloud)<\/strong><\/td>\n<td>Azure-native IaC<\/td>\n<td>Deep Azure integration<\/td>\n<td>Not for Google Cloud<\/td>\n<td>Only if deploying primarily on Azure<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated bank landing zone rollout<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A bank must provision dozens of projects with consistent networking, logging, IAM baselines, and strict audit trails.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>A platform team maintains Terraform modules for:<ul>\n<li>project baseline (labels, logging sinks)<\/li>\n<li>network baseline (VPC\/subnets\/firewalls)<\/li>\n<li>security baseline (service accounts, IAM bindings)<\/li>\n<\/ul>\n<\/li>\n<li>Infrastructure Manager deployments exist per environment (dev\/stage\/prod) and per business unit.<\/li>\n<li>Execution service accounts are tightly scoped; production applies require change approvals.<\/li>\n<li><strong>Why Infrastructure Manager was chosen<\/strong><\/li>\n<li>Managed Terraform execution aligned with Google Cloud IAM and audit requirements.<\/li>\n<li>Consistent deployment operations and logs for compliance evidence.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Faster project provisioning with fewer configuration errors.<\/li>\n<li>Clearer audit trails and improved separation of duties.<\/li>\n<li>Reduced reliance on local Terraform runs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: standard app environment provisioning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup wants repeatable dev\/stage\/prod provisioning without building a complex Terraform platform.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>A small Terraform module creates:<ul>\n<li>a Cloud Storage bucket for app assets<\/li>\n<li>service account + minimal IAM<\/li>\n<li>optional Cloud Run service (future)<\/li>\n<\/ul>\n<\/li>\n<li>Infrastructure Manager manages the deployment per environment.<\/li>\n<li><strong>Why Infrastructure Manager was chosen<\/strong><\/li>\n<li>Reduces need to manage Terraform runners and state handling manually.<\/li>\n<li>Encourages better hygiene (code-based changes, auditable operations) early.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Consistent environments and simpler onboarding.<\/li>\n<li>Safer changes with visible operation history.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Infrastructure Manager the same as Terraform Cloud?<\/strong><br\/>\nNo. Terraform Cloud is a HashiCorp-managed platform. Infrastructure Manager is a Google Cloud service that runs Terraform-based deployments within Google Cloud\u2019s control plane and IAM model.<\/p>\n\n\n\n<p>2) <strong>Does Infrastructure Manager replace Terraform CLI?<\/strong><br\/>\nIt doesn\u2019t replace Terraform as a tool; it provides a managed way to execute Terraform workflows. You still write Terraform configurations.<\/p>\n\n\n\n<p>3) <strong>Do I still need to manage Terraform state?<\/strong><br\/>\nYou must understand how state is handled in your Infrastructure Manager workflow. The service abstracts some details, but state location, access control, and security are still critical. Verify current state behavior in official docs.<\/p>\n\n\n\n<p>4) <strong>Can Infrastructure Manager deploy resources outside Google Cloud?<\/strong><br\/>\nInfrastructure Manager is designed for Google Cloud provisioning. Terraform can manage many providers, but Infrastructure Manager support and policy constraints are Google Cloud\u2013centric. Verify cross-provider support before relying on it.<\/p>\n\n\n\n<p>5) <strong>What identity creates the resources? My user account or a service account?<\/strong><br\/>\nTypically the execution <strong>service account<\/strong> performs resource creation. Your user identity calls the Infrastructure Manager API, but the execution identity needs permissions to create resources.<\/p>\n\n\n\n<p>6) <strong>How do I implement least privilege for the execution service account?<\/strong><br\/>\nStart by listing resources the deployment manages, then grant the narrowest roles at the narrowest scope possible (resource-level where available). Avoid broad project-wide roles in production.<\/p>\n\n\n\n<p>7) <strong>How do I promote changes from dev to prod?<\/strong><br\/>\nUse versioned Terraform modules and a promotion pipeline. Apply the same module version with environment-specific inputs to dev, then stage, then prod.<\/p>\n\n\n\n<p>8) <strong>Does Infrastructure Manager provide a \u201cplan\u201d preview?<\/strong><br\/>\nInfrastructure Manager workflows are Terraform-based; there is typically an equivalent of plan\/apply in managed operations. Verify the exact \u201cpreview\u201d or \u201cplan\u201d support and commands in official docs.<\/p>\n\n\n\n<p>9) <strong>Where do I see logs for failed deployments?<\/strong><br\/>\nUse the Infrastructure Manager deployment\/operation details and Cloud Logging. Also consult Cloud Audit Logs to see who triggered actions.<\/p>\n\n\n\n<p>10) <strong>Can I use private modules?<\/strong><br\/>\nThis depends on supported sources (Cloud Storage, Git, Artifact Registry, etc.) and access methods. Verify current supported private module workflows in official docs.<\/p>\n\n\n\n<p>11) <strong>How do I handle secrets in Terraform with Infrastructure Manager?<\/strong><br\/>\nAvoid plaintext secrets in code and variables. Prefer Secret Manager and runtime injection patterns. Review how Terraform state is stored and who can access it.<\/p>\n\n\n\n<p>12) <strong>What causes the most common failures?<\/strong><br\/>\nIAM permission issues, org policy constraints, API not enabled, quotas, and invalid resource parameters.<\/p>\n\n\n\n<p>13) <strong>Can I import existing resources into an Infrastructure Manager deployment?<\/strong><br\/>\nTerraform import is a specialized workflow; Infrastructure Manager support may differ from local Terraform. Verify import capabilities and recommended adoption approaches in official docs.<\/p>\n\n\n\n<p>14) <strong>Is Infrastructure Manager suitable for production?<\/strong><br\/>\nYes, when you design it with proper IAM, logging, approvals, and module hygiene. Confirm your required features and region support.<\/p>\n\n\n\n<p>15) <strong>How do I prevent accidental deletion of production resources?<\/strong><br\/>\nUse strict IAM, change approvals, separate projects, protective org policies, and consider Terraform lifecycle safeguards. Also ensure deletion semantics for deployments are well understood and documented.<\/p>\n\n\n\n<p>16) <strong>How do I structure deployments for a large org?<\/strong><br\/>\nSplit by domain (foundation vs workloads), use a module registry pattern, standardize labels, and enforce guardrails with IAM and org policies.<\/p>\n\n\n\n<p>17) <strong>Do I need Cloud Build to use Infrastructure Manager?<\/strong><br\/>\nNo. Cloud Build is optional for CI\/CD automation. You can trigger deployments manually via Console\/CLI\/API.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Infrastructure Manager<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>https:\/\/cloud.google.com\/infrastructure-manager\/docs<\/td>\n<td>Primary reference for concepts, supported workflows, locations, and setup<\/td>\n<\/tr>\n<tr>\n<td>Official tutorials \/ quickstarts<\/td>\n<td>https:\/\/cloud.google.com\/infrastructure-manager\/docs (see Tutorials\/Quickstarts sections)<\/td>\n<td>Step-by-step guides aligned to current product behavior<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud IAM docs<\/td>\n<td>https:\/\/cloud.google.com\/iam\/docs<\/td>\n<td>Essential for securing execution service accounts and access control<\/td>\n<\/tr>\n<tr>\n<td>Cloud Logging docs<\/td>\n<td>https:\/\/cloud.google.com\/logging\/docs<\/td>\n<td>Learn how to find and analyze deployment logs<\/td>\n<\/tr>\n<tr>\n<td>Cloud Audit Logs docs<\/td>\n<td>https:\/\/cloud.google.com\/logging\/docs\/audit<\/td>\n<td>Governance and compliance auditing of deployment actions<\/td>\n<\/tr>\n<tr>\n<td>Cloud Storage pricing<\/td>\n<td>https:\/\/cloud.google.com\/storage\/pricing<\/td>\n<td>Costs for storing Terraform sources\/artifacts and (potentially) related objects<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud pricing overview<\/td>\n<td>https:\/\/cloud.google.com\/pricing<\/td>\n<td>Broader pricing navigation for services your Terraform will provision<\/td>\n<\/tr>\n<tr>\n<td>Pricing calculator<\/td>\n<td>https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Estimate costs for deployed infrastructure<\/td>\n<\/tr>\n<tr>\n<td>Quotas overview<\/td>\n<td>https:\/\/cloud.google.com\/docs\/quota<\/td>\n<td>Understand quotas that may block deployments<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud Architecture Center<\/td>\n<td>https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures you can translate into Terraform blueprints<\/td>\n<\/tr>\n<tr>\n<td>Terraform documentation<\/td>\n<td>https:\/\/developer.hashicorp.com\/terraform\/docs<\/td>\n<td>Core Terraform concepts (state, modules, providers) that apply to Infrastructure Manager<\/td>\n<\/tr>\n<tr>\n<td>Google provider docs (Terraform)<\/td>\n<td>https:\/\/registry.terraform.io\/providers\/hashicorp\/google\/latest\/docs<\/td>\n<td>Resource-level Terraform docs for Google Cloud provider behavior<\/td>\n<\/tr>\n<tr>\n<td>gcloud CLI reference<\/td>\n<td>https:\/\/cloud.google.com\/sdk\/gcloud\/reference<\/td>\n<td>Verify current <code>gcloud<\/code> syntax for infrastructure manager commands<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Beginners to advanced DevOps\/SRE\/platform engineers<\/td>\n<td>DevOps, CI\/CD, cloud automation, Infrastructure as code, Terraform practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students and working professionals<\/td>\n<td>SCM, DevOps fundamentals, tooling ecosystems<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations and DevOps practitioners<\/td>\n<td>CloudOps, operational readiness, monitoring, automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform engineers, operations teams<\/td>\n<td>Reliability engineering, operational best practices, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation, observability-driven operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify offerings)<\/td>\n<td>Learners seeking trainer-led or curated content<\/td>\n<td>https:\/\/www.rajeshkumar.xyz<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify course catalog)<\/td>\n<td>Individuals and teams learning DevOps\/IaC<\/td>\n<td>https:\/\/www.devopstrainer.in<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps services\/training (verify offerings)<\/td>\n<td>Teams needing short-term coaching or implementation support<\/td>\n<td>https:\/\/www.devopsfreelancer.com<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify offerings)<\/td>\n<td>Operations teams needing practical help<\/td>\n<td>https:\/\/www.devopssupport.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog)<\/td>\n<td>Architecture, CI\/CD, IaC implementation, operational readiness<\/td>\n<td>Designing Terraform module standards; setting up secure execution identities; governance and logging patterns<\/td>\n<td>https:\/\/www.cotocus.com<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify offerings)<\/td>\n<td>DevOps transformation, tooling implementation, enablement<\/td>\n<td>Building an IaC operating model; CI\/CD integration; team training on Terraform + Google Cloud<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service catalog)<\/td>\n<td>DevOps\/IaC advisory, implementation support<\/td>\n<td>Infrastructure as code rollout; pipeline hardening; audit-ready provisioning workflows<\/td>\n<td>https:\/\/www.devopsconsulting.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Infrastructure Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals:<\/li>\n<li>projects, billing, IAM, service accounts<\/li>\n<li>VPC basics and resource hierarchy (org\/folder\/project)<\/li>\n<li>Terraform fundamentals:<\/li>\n<li>providers, resources, modules, variables, outputs<\/li>\n<li>plan\/apply lifecycle<\/li>\n<li>state and drift concepts<\/li>\n<li>Operational basics:<\/li>\n<li>Cloud Logging and Cloud Audit Logs<\/li>\n<li>quotas and limits<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Infrastructure Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Terraform module engineering:<\/li>\n<li>versioning strategy, module registries, testing<\/li>\n<li>Platform engineering patterns:<\/li>\n<li>golden paths, templates, guardrails<\/li>\n<li>Security engineering for IaC:<\/li>\n<li>least privilege at scale, org policies, secret management<\/li>\n<li>CI\/CD integration:<\/li>\n<li>automated promotion workflows, approvals, policy checks<\/li>\n<li>Governance:<\/li>\n<li>cost allocation, labeling standards, compliance reporting<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Cloud Security Engineer<\/li>\n<li>Solutions Architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Infrastructure Manager itself typically appears as part of broader Google Cloud skills rather than a standalone certification topic. Consider:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional DevOps Engineer<br\/>\nVerify the latest certification blueprints: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201cproject baseline\u201d module (labels, IAM, logging sinks) and deploy to a sandbox project.<\/li>\n<li>Create a network blueprint (VPC + subnets + firewall rules) with separate dev\/stage\/prod deployments.<\/li>\n<li>Implement a CI pipeline that updates an Infrastructure Manager deployment only after code review.<\/li>\n<li>Add governance: enforce labels and approved regions using organization policies (in a test org).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Infrastructure as code (IaC)<\/strong>: Managing infrastructure through versioned code rather than manual changes.<\/li>\n<li><strong>Terraform<\/strong>: A declarative IaC tool that uses providers to manage infrastructure resources.<\/li>\n<li><strong>Provider<\/strong>: Terraform plugin that talks to an API (e.g., the Google Cloud provider).<\/li>\n<li><strong>Module<\/strong>: Reusable Terraform package of resources and variables.<\/li>\n<li><strong>State<\/strong>: Terraform\u2019s record of managed resources and their attributes, used to compute changes.<\/li>\n<li><strong>Drift<\/strong>: When real infrastructure changes outside Terraform, diverging from the desired configuration.<\/li>\n<li><strong>Deployment (Infrastructure Manager)<\/strong>: A managed representation of your Terraform-defined infrastructure stack.<\/li>\n<li><strong>Execution service account<\/strong>: The service account used by Infrastructure Manager to call Google Cloud APIs to create\/update resources.<\/li>\n<li><strong>IAM (Identity and Access Management)<\/strong>: Google Cloud\u2019s access control system for permissions and identities.<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: Records of administrative and data access actions in Google Cloud.<\/li>\n<li><strong>Cloud Logging<\/strong>: Central service for storing and querying logs across Google Cloud services.<\/li>\n<li><strong>Org Policy<\/strong>: Organization-level constraints that restrict what can be created\/changed in Google Cloud.<\/li>\n<li><strong>Label<\/strong>: Key\/value metadata applied to resources for organization, filtering, and cost allocation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Infrastructure Manager is Google Cloud\u2019s managed <strong>Infrastructure as code<\/strong> service for deploying and managing Google Cloud resources using <strong>Terraform<\/strong>. It matters because it standardizes Terraform execution with Google Cloud IAM, operational logging, and auditable deployment operations\u2014reducing the risks of ad-hoc local runs and inconsistent automation.<\/p>\n\n\n\n<p>From an architecture perspective, it fits as a provisioning control plane for Terraform-defined \u201cdeployments,\u201d integrating with IAM (least privilege execution identities), Logging\/Audit Logs (visibility and compliance), and your existing CI\/CD tooling (promotion workflows). Cost is primarily driven by the infrastructure you provision and operational byproducts like logs and storage artifacts; always validate the current pricing model and focus optimization on the deployed resources. Security success depends on tight IAM for the execution service account, strong source controls, and careful secrets handling.<\/p>\n\n\n\n<p>Use Infrastructure Manager when you want managed Terraform provisioning aligned to Google Cloud governance. Next step: read the official docs and implement a small blueprint (network + IAM baseline) in a sandbox project, then evolve it into a promoted dev\/stage\/prod workflow.<\/p>\n\n\n\n<p>Official docs to continue: https:\/\/cloud.google.com\/infrastructure-manager\/docs<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Infrastructure as code<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,61],"tags":[],"class_list":["post-708","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-infrastructure-as-code"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=708"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/708\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}