{"id":537,"date":"2026-04-14T10:30:54","date_gmt":"2026-04-14T10:30:54","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-service-catalog-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/"},"modified":"2026-04-14T10:30:54","modified_gmt":"2026-04-14T10:30:54","slug":"google-cloud-service-catalog-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-service-catalog-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/","title":{"rendered":"Google Cloud Service Catalog Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Access and resource management"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Access and resource management<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Google Cloud <strong>Service Catalog<\/strong> is a governed, self-service way for platform teams to offer <strong>approved, repeatable cloud \u201cproducts\u201d<\/strong> (for example: a standard Cloud Storage bucket, a Cloud Run service baseline, a VPC pattern, or a GKE cluster blueprint) to internal teams\u2014while keeping security, cost controls, and organizational policy in place.<\/p>\n\n\n\n<p>In simple terms: <strong>Service Catalog lets you publish \u201cgolden path\u201d infrastructure and application templates and let others deploy them safely<\/strong> without needing deep expertise or elevated permissions for every resource type.<\/p>\n\n\n\n<p>Technically, Service Catalog acts as a <strong>curation and access-control layer<\/strong> around deployable solutions (often Infrastructure-as-Code based). It integrates with Google Cloud identity (Cloud IAM), resource hierarchy (organization\/folders\/projects), audit logging, and the provisioning mechanism used by the underlying solution (commonly Google Cloud\u2019s Terraform-based provisioning via <strong>Infrastructure Manager<\/strong>, depending on what your organization has enabled). The exact provisioning back end and UI flows can evolve\u2014<strong>verify the current Service Catalog documentation for your tenant<\/strong>.<\/p>\n\n\n\n<p>The problem it solves: as Google Cloud usage grows, teams struggle with:\n&#8211; <strong>Inconsistent architectures<\/strong> (every project provisions resources differently)\n&#8211; <strong>Security drift<\/strong> (public buckets, overly broad IAM, missing CMEK, missing logging)\n&#8211; <strong>Slow delivery<\/strong> (central cloud teams become ticket queues)\n&#8211; <strong>Unpredictable cost<\/strong> (unbounded SKUs and uncontrolled resource shapes)<\/p>\n\n\n\n<p>Service Catalog addresses these by enabling <strong>standardized, controlled, auditable self-service provisioning<\/strong>.<\/p>\n\n\n\n<blockquote>\n<p>Naming and availability note: Google Cloud has offered \u201cService Catalog\u201d capabilities in the console; in some organizations it may appear as a distinct product entry, or as part of a broader platform\/self-service provisioning experience. If you don\u2019t see it in the console navigation, <strong>verify availability, organization policy constraints, and GA\/Preview status in official docs<\/strong> and your Google Cloud Organization settings.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Service Catalog?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose (practical definition)<\/h3>\n\n\n\n<p>Service Catalog in Google Cloud is intended to help platform and security teams:\n&#8211; <strong>Curate<\/strong> a set of approved internal cloud solutions (\u201cproducts\u201d)\n&#8211; <strong>Control access<\/strong> to who can discover and deploy those solutions\n&#8211; <strong>Standardize deployments<\/strong> through versioned, repeatable templates\n&#8211; <strong>Improve governance<\/strong> with consistent labels\/tags, logging, IAM boundaries, and audit trails<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (what you should expect)<\/h3>\n\n\n\n<p>While exact feature sets can vary by release and tenant configuration, the common capabilities associated with Service Catalog are:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Catalogs<\/strong>: groupings of deployable \u201cproducts\u201d for an organization or environment (for example: \u201cDeveloper Productivity\u201d, \u201cNetworking Baselines\u201d, \u201cData Platforms\u201d).<\/li>\n<li><strong>Products \/ Solutions<\/strong>: deployable items that represent an approved template (for example: \u201cPrivate GCS bucket (CMEK)\u201d, \u201cCloud Run service with load balancing\u201d, \u201cStandard VPC (3 subnets + firewall)\u201d).<\/li>\n<li><strong>Versioning<\/strong>: publish new versions of a product as the underlying template evolves.<\/li>\n<li><strong>IAM-based access<\/strong>: use Cloud IAM to control who can view\/deploy\/manage catalogs and products.<\/li>\n<li><strong>Provisioning integration<\/strong>: deployments are typically executed by an underlying provisioning system (commonly Terraform-based provisioning through Google Cloud Infrastructure Manager in many Google Cloud patterns). <strong>Verify the current provisioning back end supported by Service Catalog in your environment.<\/strong><\/li>\n<li><strong>Auditability<\/strong>: actions are visible via Cloud Audit Logs (Admin Activity \/ Data Access depending on API and configuration).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>Conceptually, Service Catalog involves:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Component<\/th>\n<th>What it represents<\/th>\n<th>Typical owner<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Catalog<\/td>\n<td>A collection of approved products<\/td>\n<td>Platform team \/ Cloud Center of Excellence<\/td>\n<\/tr>\n<tr>\n<td>Product (Solution)<\/td>\n<td>A deployable template users can launch<\/td>\n<td>Platform team + security reviewer<\/td>\n<\/tr>\n<tr>\n<td>Product version<\/td>\n<td>A specific immutable release of the product<\/td>\n<td>Platform team (via release process)<\/td>\n<\/tr>\n<tr>\n<td>Parameters<\/td>\n<td>Inputs users can provide at deploy time<\/td>\n<td>Product author<\/td>\n<\/tr>\n<tr>\n<td>Deployment \/ Instance<\/td>\n<td>A launched copy in a target project<\/td>\n<td>Application team \/ environment owner<\/td>\n<\/tr>\n<tr>\n<td>IAM policies<\/td>\n<td>Who can see\/deploy\/administer<\/td>\n<td>Platform\/security<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>Service Catalog is primarily a <strong>governance and self-service provisioning<\/strong> service:\n&#8211; Not a compute service\n&#8211; Not a networking service\n&#8211; Not an ITSM tool by itself\n&#8211; Not a CMDB<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (project\/org\/regional)<\/h3>\n\n\n\n<p>Service Catalog\u2019s governance and IAM model typically align to the <strong>Google Cloud resource hierarchy<\/strong> (Organization \u2192 Folders \u2192 Projects). The catalog and product visibility is usually managed at an organizational scope (or shared scope) and deployments occur into <strong>projects<\/strong>.<\/p>\n\n\n\n<p>For geographic scope:\n&#8211; The \u201ccatalog\u201d experience is generally <strong>global<\/strong> (a control-plane experience)\n&#8211; The resources you deploy are <strong>regional\/zonal\/global depending on the product template<\/strong><\/p>\n\n\n\n<p>Because Google Cloud evolves quickly, <strong>verify the current \u201clocation\u201d behavior<\/strong> (global vs regional control plane) in the official documentation for Service Catalog and the provisioning back end you use.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Service Catalog typically sits at the intersection of:\n&#8211; <strong>Access and resource management<\/strong>: Cloud IAM, organization policies, resource hierarchy, audit logs\n&#8211; <strong>Infrastructure provisioning<\/strong>: Infrastructure Manager (Terraform), or other Google Cloud deployment mechanisms depending on product type\n&#8211; <strong>Governance<\/strong>: labels\/tags, policy constraints, security posture management\n&#8211; <strong>Operations<\/strong>: standardized logging\/monitoring defaults, consistent break-glass patterns<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Service Catalog?<\/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>Faster time-to-value<\/strong>: teams deploy standard stacks in minutes instead of waiting for tickets.<\/li>\n<li><strong>Reduced rework<\/strong>: fewer \u201csnowflake\u201d deployments means fewer redesigns and migrations.<\/li>\n<li><strong>Cost predictability<\/strong>: approved products can enforce cost guardrails (regions, sizes, autoscaling limits, logging retention defaults).<\/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>Standardization<\/strong>: turn reference architectures into reusable internal products.<\/li>\n<li><strong>Repeatability<\/strong>: versioned templates reduce configuration drift across projects\/environments.<\/li>\n<li><strong>Safer defaults<\/strong>: embed encryption, private networking, and logging by default.<\/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>Lower ops overhead<\/strong>: fewer bespoke patterns to support.<\/li>\n<li><strong>Self-service with controls<\/strong>: developers can provision without being handed broad IAM roles.<\/li>\n<li><strong>Clear ownership<\/strong>: product owners maintain templates; consumers own deployments.<\/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>Policy-by-design<\/strong>: products can incorporate org policies, secure baselines, and required telemetry.<\/li>\n<li><strong>Least privilege<\/strong>: allow deployment of approved patterns without granting broad resource-creation powers.<\/li>\n<li><strong>Audit trail<\/strong>: catalog publishing and deployments are auditable.<\/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>Scales governance, not just infrastructure<\/strong>: the platform team can support many teams without linear headcount growth.<\/li>\n<li><strong>Promotes scalable architectures<\/strong>: products can enforce autoscaling-friendly defaults and SLO-driven patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Service Catalog<\/h3>\n\n\n\n<p>Choose Service Catalog when you need:\n&#8211; Multiple teams provisioning in Google Cloud with a need for <strong>consistency<\/strong>\n&#8211; A platform team delivering <strong>golden paths<\/strong> and reusable building blocks\n&#8211; Strong governance requirements (regulated industries, shared enterprise orgs)\n&#8211; A way to separate <strong>product authoring<\/strong> from <strong>product consumption<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose Service Catalog<\/h3>\n\n\n\n<p>Service Catalog may not be the right fit if:\n&#8211; You only have one small team and minimal governance needs (simple Terraform modules may suffice)\n&#8211; You need a full ITSM workflow (approvals, CMDB, request management) as the primary interface\u2014consider integrating an ITSM platform and keeping Service Catalog as the provisioning layer\n&#8211; Your templates are changing too rapidly without version discipline (you\u2019ll create breaking changes and erode trust)\n&#8211; You require advanced policy constraints like complex rule engines that the current Service Catalog feature set may not provide (compare with AWS Service Catalog constraint system; <strong>verify current Google Cloud capabilities<\/strong>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Service Catalog 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 (policy enforcement, auditability)<\/li>\n<li>Healthcare and life sciences (regulated data controls)<\/li>\n<li>Retail and e-commerce (repeatable app platform patterns)<\/li>\n<li>Media and gaming (standardized project bootstrapping)<\/li>\n<li>Public sector (consistent compliance controls)<\/li>\n<li>SaaS and technology (platform engineering and self-service)<\/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 (Internal Developer Platform)<\/li>\n<li>Cloud Center of Excellence (CCoE)<\/li>\n<li>Security engineering and governance teams<\/li>\n<li>SRE\/operations teams<\/li>\n<li>DevOps teams supporting many application squads<\/li>\n<li>Data platform teams providing standardized analytics stacks<\/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>Standard application runtime baselines (Cloud Run, GKE)<\/li>\n<li>Data platform building blocks (buckets, datasets, Pub\/Sub)<\/li>\n<li>Networking foundations (VPC, subnets, firewall policies)<\/li>\n<li>Identity foundations (service accounts, workload identity patterns)<\/li>\n<li>Shared services (logging sinks, monitoring dashboards)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-project landing zones<\/li>\n<li>Hub-and-spoke networks<\/li>\n<li>Multi-tenant organizations with folders per BU<\/li>\n<li>Regulated \u201cguardrail-first\u201d environments<\/li>\n<li>CI\/CD-driven infrastructure with controlled self-service entry points<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: publish stable, security-reviewed versions; enforce strict access; use separate provisioning identities; change control.<\/li>\n<li><strong>Dev\/Test<\/strong>: faster iteration; broader access; shorter lifecycle; more frequent versions.<\/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 Service Catalog use cases that fit the <strong>Access and resource management<\/strong> category (governed provisioning and controlled access).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Standard project bootstrap (\u201clanding zone lite\u201d)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: New projects get created without baseline logging, labels, budgets, or org policy alignment.<\/li>\n<li><strong>Why Service Catalog fits<\/strong>: Offer a \u201cProject Bootstrap\u201d product that provisions baseline resources and configuration consistently.<\/li>\n<li><strong>Scenario<\/strong>: A team launches \u201cNew Microservice Project Baseline\u201d to create logging sinks, monitoring alerts, and standard IAM groups in a new dev project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Approved Cloud Storage bucket patterns (private, CMEK, retention)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams create public buckets or skip retention and encryption requirements.<\/li>\n<li><strong>Why it fits<\/strong>: Provide bucket products with safe defaults and parameterized names\/locations.<\/li>\n<li><strong>Scenario<\/strong>: \u201cRegulated Bucket (CMEK + retention)\u201d is the only approved path for storing PHI data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Cloud Run service baseline (IAM, ingress, logging)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Inconsistent Cloud Run security posture (unauthenticated access, public ingress).<\/li>\n<li><strong>Why it fits<\/strong>: Publish a baseline service that enforces authentication and sets ingress rules.<\/li>\n<li><strong>Scenario<\/strong>: Developers deploy a \u201cPrivate Cloud Run API\u201d template that automatically uses a service account and private networking pattern.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Network foundations (VPC + subnet layout)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Ad hoc subnets and firewall rules create routing complexity and security gaps.<\/li>\n<li><strong>Why it fits<\/strong>: Provide a governed VPC product with predefined regions, CIDRs, and firewall policy references.<\/li>\n<li><strong>Scenario<\/strong>: A BU deploys \u201cStandard VPC (prod)\u201d that creates subnets in approved regions and attaches hierarchical firewall policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) GKE cluster blueprint with guardrails<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams create clusters with weak node security, no workload identity, or insufficient logging.<\/li>\n<li><strong>Why it fits<\/strong>: Offer a cluster product with workload identity, logging\/monitoring, and node security settings baked in.<\/li>\n<li><strong>Scenario<\/strong>: Platform publishes \u201cGKE Autopilot &#8211; Standard\u201d and \u201cGKE Standard &#8211; Regulated\u201d.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Data platform building blocks (Pub\/Sub topics, BigQuery datasets)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Data resources are created without naming conventions, labels, or IAM boundaries.<\/li>\n<li><strong>Why it fits<\/strong>: Provide products that apply consistent dataset IAM and retention defaults.<\/li>\n<li><strong>Scenario<\/strong>: \u201cBigQuery Dataset (PII)\u201d creates a dataset with restricted IAM groups and default table expiration policies (where applicable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Centralized logging sink + SIEM export<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Security cannot guarantee that critical logs are exported and retained.<\/li>\n<li><strong>Why it fits<\/strong>: Publish a product that configures sinks to a central logging project and exports to SIEM.<\/li>\n<li><strong>Scenario<\/strong>: Each project deploys \u201cSecurity Log Sink\u201d that routes Admin Activity logs to a central project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Service account + workload identity federation pattern<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams create long-lived keys or inconsistent CI\/CD identities.<\/li>\n<li><strong>Why it fits<\/strong>: Provide a standard identity product with correct IAM bindings.<\/li>\n<li><strong>Scenario<\/strong>: \u201cGitHub Actions Identity (WIF)\u201d creates a workload identity pool\/provider and a service account with narrowly scoped permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Standardized Cloud SQL instance (private IP, backups, flags)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams deploy databases without backups, maintenance windows, or private networking.<\/li>\n<li><strong>Why it fits<\/strong>: Encapsulate approved database configurations.<\/li>\n<li><strong>Scenario<\/strong>: \u201cCloud SQL Postgres &#8211; Standard\u201d configures private IP and backup policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Environment replication (dev\/stage\/prod consistency)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Environments differ widely; prod issues can\u2019t be reproduced.<\/li>\n<li><strong>Why it fits<\/strong>: Publish the same product with environment-specific parameter constraints.<\/li>\n<li><strong>Scenario<\/strong>: A team deploys identical \u201cService Stack\u201d products to dev\/stage\/prod with only size and project differing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Budget + alerting package<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Projects accrue cost without alerts, leading to surprises.<\/li>\n<li><strong>Why it fits<\/strong>: Provide a product that sets budgets and notifications (often via Billing and Pub\/Sub integrations).<\/li>\n<li><strong>Scenario<\/strong>: \u201cProject Budget Alerts\u201d posts budget notifications to a shared Slack\/Teams integration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Secure secret storage baseline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Secrets are stored in source code or shared drives.<\/li>\n<li><strong>Why it fits<\/strong>: Publish a \u201cSecret Manager baseline\u201d product with IAM group bindings and rotation reminders.<\/li>\n<li><strong>Scenario<\/strong>: A team deploys \u201cSecret Manager &#8211; App Baseline\u201d that creates secret placeholders and grants access to runtime identities.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Because Service Catalog capabilities can vary by release and organization setup, the features below focus on the stable conceptual set used in governed self-service. <strong>Verify exact feature names and availability in the official Service Catalog docs for your tenant.<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Catalog management<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Create catalogs as curated collections of approved products.<\/li>\n<li><strong>Why it matters<\/strong>: Separates \u201ceverything possible\u201d from \u201cwhat\u2019s approved here\u201d.<\/li>\n<li><strong>Practical benefit<\/strong>: Different catalogs per environment (dev vs prod) or per business unit.<\/li>\n<li><strong>Caveats<\/strong>: Catalog scoping and sharing across folders\/orgs can be constrained\u2014verify how catalogs inherit IAM and visibility.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Product publishing (solutions\/templates)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Define a deployable product backed by an approved template\/blueprint.<\/li>\n<li><strong>Why it matters<\/strong>: Converts reference architectures into consumable self-service items.<\/li>\n<li><strong>Practical benefit<\/strong>: Developers deploy known-good patterns without learning every resource API.<\/li>\n<li><strong>Caveats<\/strong>: Product types supported depend on the provisioning back end (commonly Terraform). Unsupported resources require template updates or alternative tooling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Versioning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Manage versions of products; users deploy a specific version.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents \u201cmoving target\u201d templates and supports controlled rollouts.<\/li>\n<li><strong>Practical benefit<\/strong>: Roll back to previous version when a new release introduces issues.<\/li>\n<li><strong>Caveats<\/strong>: Versioning discipline is essential; breaking changes should require a new major version and clear deprecation guidance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Parameterization and inputs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows users to provide inputs (names, regions, sizes) at deploy time.<\/li>\n<li><strong>Why it matters<\/strong>: Balances standardization with necessary flexibility.<\/li>\n<li><strong>Practical benefit<\/strong>: One bucket template can support many buckets with consistent controls.<\/li>\n<li><strong>Caveats<\/strong>: Too many parameters recreate complexity; too few create template sprawl.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM-based access control<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls who can view catalogs\/products and who can deploy\/manage them.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents unauthorized provisioning paths and limits blast radius.<\/li>\n<li><strong>Practical benefit<\/strong>: Developers can deploy \u201capproved VPC\u201d without being allowed to create arbitrary VPCs in any project.<\/li>\n<li><strong>Caveats<\/strong>: Underlying provisioning identities still need permissions to create resources; design carefully to avoid privilege escalation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Deployment tracking and auditability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Track who launched what and when; integrate with audit logs.<\/li>\n<li><strong>Why it matters<\/strong>: Required for governance, incident response, and compliance.<\/li>\n<li><strong>Practical benefit<\/strong>: You can answer \u201cwho created this bucket and via which template version?\u201d<\/li>\n<li><strong>Caveats<\/strong>: Logging availability depends on API logging category; some details may be in the provisioning system logs (for example Terraform run logs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with Google Cloud governance constructs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works alongside Organization Policy, IAM, folder structure, labels\/tags, and (optionally) VPC Service Controls.<\/li>\n<li><strong>Why it matters<\/strong>: Guardrails should apply regardless of provisioning path.<\/li>\n<li><strong>Practical benefit<\/strong>: Even if a product template tries to create a public bucket, Org Policy can block it.<\/li>\n<li><strong>Caveats<\/strong>: Don\u2019t rely solely on templates for security; enforce guardrails at org\/folder\/project level.<\/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 architecture<\/h3>\n\n\n\n<p>At a high level, Service Catalog provides:\n1. A <strong>control plane<\/strong> for defining catalogs\/products and enforcing access controls.\n2. A <strong>deployment path<\/strong> that triggers an underlying provisioning engine to create resources in a target project using a controlled identity.\n3. An <strong>audit and operations trail<\/strong> across Cloud Audit Logs, provisioning run logs, and created resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (typical)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Platform team publishes a product (template + parameters + version) into a catalog.<\/li>\n<li>User with deploy permissions selects product and submits a deployment request (inputs + target project).<\/li>\n<li>Service Catalog triggers the underlying provisioning system (commonly Terraform runs).<\/li>\n<li>Provisioning identity (service account) calls Google Cloud APIs to create\/update resources.<\/li>\n<li>Audit logs record admin activities; created resources inherit labels\/tags and policies.<\/li>\n<li>User views deployment status and outputs; operations teams monitor resulting resources.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services (common)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud IAM<\/strong>: who can publish\/deploy; what the provisioning identity can do.<\/li>\n<li><strong>Resource Manager<\/strong>: projects\/folders\/org; policy inheritance.<\/li>\n<li><strong>Organization Policy Service<\/strong>: enforce constraints (no public IPs, restrict regions, etc.).<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: record who changed catalog\/published versions and who deployed.<\/li>\n<li><strong>Infrastructure Manager (Terraform)<\/strong>: commonly used provisioning engine (verify in your environment).<\/li>\n<li><strong>Cloud Logging\/Monitoring<\/strong>: logs and metrics for deployed resources and provisioning runs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The specific Google Cloud APIs required by the template (Storage, Compute, Run, GKE, SQL, etc.)<\/li>\n<li>A provisioning engine API if used (for example Infrastructure Manager)<\/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>Users authenticate with <strong>Google identity<\/strong> (Google Workspace \/ Cloud Identity).<\/li>\n<li>Authorization is <strong>Cloud IAM<\/strong> at catalog\/product level and at target project\/resource level.<\/li>\n<li>Provisioning often uses a <strong>service account<\/strong> to create resources, rather than end-user credentials (recommended for consistency and least privilege).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>Service Catalog itself is a control-plane experience. Network exposure concerns are mainly about:\n&#8211; The deployed resources (public vs private networking)\n&#8211; How the provisioning engine reaches APIs (generally Google APIs via Google-controlled endpoints)\n&#8211; Whether your org uses <strong>Private Google Access<\/strong>, <strong>VPC Service Controls<\/strong>, or <strong>restricted.googleapis.com<\/strong><\/p>\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>Ensure <strong>Cloud Audit Logs<\/strong> are retained and exported (especially Admin Activity logs).<\/li>\n<li>Use consistent labels\/tags to attribute cost and ownership (<code>env<\/code>, <code>app<\/code>, <code>cost_center<\/code>, <code>data_classification<\/code>).<\/li>\n<li>Treat product templates as code: code review, change management, testing environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer \/ Requestor] --&gt;|Select product + inputs| SC[Service Catalog]\n  SC --&gt;|Trigger deployment| PE[Provisioning Engine\\n(e.g., Terraform via Infrastructure Manager)]\n  PE --&gt;|Uses Service Account| APIs[Google Cloud APIs]\n  APIs --&gt; R[Resources in target project\\n(buckets, services, networks)]\n  SC --&gt; Logs[Cloud Audit Logs]\n  PE --&gt; RunLogs[Provisioning run logs]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    subgraph Platform[Platform Folder \/ Shared Services]\n      Repo[Template source repo\\n(Git-based)]\n      CI[CI pipeline\\n(validate\/scan\/test)]\n      Catalog[Service Catalog\\nCatalogs + Products]\n      SecLogs[Central Logging Project\\nSinks + retention]\n      SCC[Security Command Center\\n(optional)]\n    end\n\n    subgraph BU1[Business Unit Folder]\n      subgraph Prod[Prod Projects]\n        AppProj[App Project]\n        NetProj[Network Project]\n        Res[Deployed resources\\n(private buckets, VPC, Cloud Run, etc.)]\n      end\n    end\n  end\n\n  Repo --&gt; CI --&gt; Catalog\n  User[App team] --&gt;|Deploy approved product| Catalog\n  Catalog --&gt; PE2[Provisioning Engine\\n(central SA + policy)]\n  PE2 --&gt; AppProj\n  PE2 --&gt; NetProj\n  AppProj --&gt; Res\n\n  Catalog --&gt; Audit[Cloud Audit Logs]\n  Audit --&gt; SecLogs\n  AppProj --&gt; Audit\n  NetProj --&gt; Audit\n  SecLogs --&gt; SCC\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Because the exact enablement and role names can vary, treat this list as a practical checklist and <strong>verify the precise IAM roles and required APIs in official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account \/ organization requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with access to an Organization (recommended for real governance patterns).<\/li>\n<li>At least one Google Cloud project for:<\/li>\n<li>Platform\/admin work (catalog authoring)<\/li>\n<li>Target deployments (consumer project)<\/li>\n<li>Ability to use Cloud IAM and Resource Manager features.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>For a <strong>lab<\/strong>, the simplest approach is:\n&#8211; <strong>Project Owner<\/strong> on the admin project and the target project (in a sandbox environment only).<\/p>\n\n\n\n<p>For <strong>production<\/strong>, split duties:\n&#8211; Service Catalog administrators: permissions to create catalogs\/products and manage IAM on those artifacts (<strong>verify the exact predefined roles<\/strong> available for Service Catalog).\n&#8211; Provisioning identity (service account): least-privilege roles needed to create the specific resources in the target project(s).\n&#8211; End users: permission to deploy a product, and possibly view deployment status\/outputs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A billing account attached to target projects.<\/li>\n<li>Budget alerts recommended for cost control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI \/ SDK \/ tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud SDK (<code>gcloud<\/code>) for verification and cleanup: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>(Optional) <code>gsutil<\/code> or <code>gcloud storage<\/code> for Cloud Storage checks.<\/li>\n<li>(Optional) Git client if you store templates in a repo.<\/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>Service Catalog control plane is typically not \u201cregional\u201d in the same way as compute services.<\/li>\n<li>Deployed resources are regional\/zonal depending on what you provision.<\/li>\n<li><strong>Verify Service Catalog availability<\/strong> in your tenant and whether any features are restricted by region or org policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Quotas depend on:<\/li>\n<li>The underlying APIs (Storage, Compute, Run, etc.)<\/li>\n<li>The provisioning engine (if it has request limits)<\/li>\n<li>Start with a small resource (like a bucket) to avoid quota complexity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IAM, Resource Manager<\/li>\n<li>APIs for resources you will deploy (for this lab: Cloud Storage)<\/li>\n<li>Provisioning engine API if required by your Service Catalog product type (<strong>verify<\/strong>)<\/li>\n<\/ul>\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>In many Google Cloud setups, <strong>Service Catalog itself does not represent a large direct cost driver<\/strong>; the primary costs come from:\n&#8211; <strong>The resources deployed<\/strong> via the catalog (compute, storage, networking, logging ingestion, etc.)\n&#8211; <strong>The provisioning mechanism<\/strong> (if it has billable components\u2014<strong>verify current pricing<\/strong> for the provisioning engine used in your environment)<\/p>\n\n\n\n<p>Because Google Cloud packaging and SKUs change, <strong>verify Service Catalog pricing in official sources<\/strong>:\n&#8211; Google Cloud Pricing overview: https:\/\/cloud.google.com\/pricing\n&#8211; Pricing calculator: https:\/\/cloud.google.com\/products\/calculator\n&#8211; Search for Service Catalog pricing (official): https:\/\/cloud.google.com\/search?q=Service%20Catalog%20pricing<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to consider<\/h3>\n\n\n\n<p>Even if Service Catalog has no standalone SKU, your \u201ccatalog product\u201d can incur:\n&#8211; <strong>Compute<\/strong>: Cloud Run, GKE, Compute Engine, Cloud SQL, etc.\n&#8211; <strong>Storage<\/strong>: buckets, disks, databases, backups\n&#8211; <strong>Networking<\/strong>: load balancers, NAT, egress, inter-region traffic\n&#8211; <strong>Observability<\/strong>:\n  &#8211; Cloud Logging ingestion and retention\n  &#8211; Cloud Monitoring metrics volume\n  &#8211; Export sinks to BigQuery or Pub\/Sub (those services also cost)\n&#8211; <strong>Security<\/strong>:\n  &#8211; KMS keys\/operations (if CMEK is used)\n  &#8211; SCC tier (if enabled)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many Google Cloud products have free tiers (e.g., some Cloud Run, Cloud Storage free usage tiers in some regions), but these vary.<\/li>\n<li>Do not assume a deployment is free\u2014<strong>check the calculator<\/strong> for your specific design.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (common \u201csurprises\u201d)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Logging<\/strong>: high-volume logs from GKE\/Load Balancers exported to BigQuery.<\/li>\n<li><strong>Egress<\/strong>: internet egress or cross-region replication.<\/li>\n<li><strong>Overprovisioning<\/strong>: large default machine types in templates.<\/li>\n<li><strong>Backups\/retention<\/strong>: long retention on logs, backups, and object storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CI pipelines for template testing (Cloud Build minutes, artifact storage).<\/li>\n<li>Policy and security tooling (SCC tier, third-party SIEM).<\/li>\n<li>Operational overhead: on-call and maintenance for the runtime chosen.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If templates create global load balancers, Cloud NAT, or cross-region resources, you may incur:<\/li>\n<li>load balancer forwarding rules and data processing costs<\/li>\n<li>NAT gateway costs<\/li>\n<li>inter-region egress<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost with Service Catalog<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Publish \u201cright-sized\u201d defaults (smallest viable instance sizes, autoscaling enabled).<\/li>\n<li>Provide environment-specific products (dev vs prod) so dev doesn\u2019t deploy prod-grade expensive stacks.<\/li>\n<li>Enforce labels\/tags for cost allocation and automate budget creation.<\/li>\n<li>Add guardrails: restrict regions, restrict machine families, restrict public IPs (Org Policy).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (safe)<\/h3>\n\n\n\n<p>A minimal lab product that creates:\n&#8211; One Cloud Storage bucket in a single region\n&#8211; Basic logging (default)\n\u2026is typically low cost, mostly driven by:\n&#8211; stored GB-month\n&#8211; operations (requests)\n&#8211; any optional KMS usage (if you add CMEK)<\/p>\n\n\n\n<p>Use the calculator and input:\n&#8211; Storage: 1\u20135 GB\n&#8211; Operations: low request volume\n&#8211; Data egress: near zero<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>A production catalog product like \u201cGKE cluster + load balancer + NAT + logging sinks\u201d requires modeling:\n&#8211; node pools (vCPU\/RAM), autoscaling bounds\n&#8211; load balancer processing\n&#8211; NAT usage\n&#8211; log ingestion volumes and export destinations\n&#8211; backup\/retention and DR<\/p>\n\n\n\n<p>For production, treat each product version as a costed \u201cSKU bundle\u201d and publish expected cost ranges in internal documentation.<\/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 builds a small, realistic Service Catalog product: <strong>\u201cStandard Private GCS Bucket\u201d<\/strong> that creates a Cloud Storage bucket with uniform bucket-level access and labels.<\/p>\n\n\n\n<p>Because Service Catalog\u2019s UI and supported back ends can change, this lab uses a <strong>conservative approach<\/strong>:\n&#8211; Use the Google Cloud Console for Service Catalog steps\n&#8211; Use <code>gcloud<\/code> for verification and cleanup\n&#8211; Use a Terraform template because it is a common provisioning format in Google Cloud platforms (often via Infrastructure Manager). <strong>Verify your tenant\u2019s supported template types and repository integrations in official docs.<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a simple, reusable bucket template<\/li>\n<li>Publish it as a Service Catalog product<\/li>\n<li>Deploy it into a target project<\/li>\n<li>Validate creation and auditability<\/li>\n<li>Clean up safely<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create (or choose) two projects: an <strong>admin project<\/strong> and a <strong>target project<\/strong>\n2. Create a Terraform template for a Cloud Storage bucket\n3. Publish the template as a <strong>Service Catalog product<\/strong>\n4. Deploy the product to the target project\n5. Validate the bucket and labels\n6. Delete the deployment and remove the catalog artifacts<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Prepare projects and identities<\/h3>\n\n\n\n<p><strong>What you\u2019ll do<\/strong>\n&#8211; Choose a sandbox Google Cloud project to host catalog admin actions (Admin Project).\n&#8211; Choose a sandbox Google Cloud project where you will deploy the product (Target Project).\n&#8211; Ensure billing is enabled on the target project.<\/p>\n\n\n\n<p><strong>Console actions<\/strong>\n1. In Google Cloud Console, open <strong>Resource Manager<\/strong> and confirm you have:\n   &#8211; An <strong>Admin Project<\/strong>\n   &#8211; A <strong>Target Project<\/strong>\n2. Confirm <strong>Billing<\/strong> is linked to the Target Project.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You have a target project where new resources can be created without impacting production.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\nRun:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project TARGET_PROJECT_ID\ngcloud billing projects describe TARGET_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<p>If billing is not enabled, the command will indicate the billing status or fail due to permissions.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create the Terraform template (bucket blueprint)<\/h3>\n\n\n\n<p>You need a small Terraform module that:\n&#8211; Creates a bucket with uniform bucket-level access\n&#8211; Applies labels\n&#8211; Uses variables for <code>project_id<\/code>, <code>bucket_name<\/code>, <code>location<\/code>, and labels<\/p>\n\n\n\n<p>Create a local folder:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir service-catalog-gcs-bucket\ncd service-catalog-gcs-bucket\n<\/code><\/pre>\n\n\n\n<p>Create <code>versions.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;= 5.0\"\n    }\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  description = \"Target Google Cloud project ID.\"\n  type        = string\n}\n\nvariable \"bucket_name\" {\n  description = \"Globally unique bucket name.\"\n  type        = string\n}\n\nvariable \"location\" {\n  description = \"Bucket location\/region (e.g., us-central1).\"\n  type        = string\n  default     = \"us-central1\"\n}\n\nvariable \"labels\" {\n  description = \"Labels to apply to the bucket.\"\n  type        = map(string)\n  default     = {\n    managed_by = \"service-catalog\"\n  }\n}\n<\/code><\/pre>\n\n\n\n<p>Create <code>main.tf<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-hcl\">provider \"google\" {\n  project = var.project_id\n}\n\nresource \"google_storage_bucket\" \"this\" {\n  name                        = var.bucket_name\n  location                    = var.location\n  uniform_bucket_level_access = true\n\n  labels = var.labels\n\n  # Safe defaults for many orgs (adjust to your requirements)\n  public_access_prevention = \"enforced\"\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.this.name\n}\n\noutput \"bucket_url\" {\n  value = \"gs:\/\/${google_storage_bucket.this.name}\"\n}\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You have a Terraform module that can create a private bucket with labels.<\/p>\n\n\n\n<p><strong>Verification (optional local)<\/strong>\nIf you want to validate syntax locally (without applying):<\/p>\n\n\n\n<pre><code class=\"language-bash\">terraform init\nterraform validate\n<\/code><\/pre>\n\n\n\n<p>This does not create any cloud resources.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Host the template in a repository accessible to your provisioning back end<\/h3>\n\n\n\n<p>Service Catalog typically needs a template source location that the provisioning engine can fetch. Common patterns include:\n&#8211; A Git repository (GitHub \/ GitLab \/ Cloud Source Repositories)\n&#8211; An artifact or storage location supported by the provisioning engine<\/p>\n\n\n\n<p><strong>Important<\/strong>: Supported sources can differ by organization and feature status. <strong>Verify in official docs what Service Catalog supports in your tenant.<\/strong><\/p>\n\n\n\n<p><strong>One practical approach (GitHub)<\/strong>\n1. Create a private GitHub repository (for example: <code>service-catalog-gcs-bucket<\/code>).\n2. Commit and push the Terraform files.<\/p>\n\n\n\n<pre><code class=\"language-bash\">git init\ngit add .\ngit commit -m \"Initial bucket template\"\ngit branch -M main\ngit remote add origin https:\/\/github.com\/YOUR_ORG\/service-catalog-gcs-bucket.git\ngit push -u origin main\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The template is in a versioned repo you can reference when creating the product.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Confirm you can browse the repo and see <code>main.tf<\/code>, <code>variables.tf<\/code>, <code>outputs.tf<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Service Catalog catalog<\/h3>\n\n\n\n<p><strong>Console actions<\/strong>\n1. In Google Cloud Console, search for <strong>Service Catalog<\/strong>.\n2. Open <strong>Service Catalog<\/strong>.\n3. Create a new <strong>Catalog<\/strong>:\n   &#8211; Name: <code>platform-basics<\/code>\n   &#8211; Description: \u201cApproved foundational products for sandbox\u201d\n4. Configure IAM for the catalog:\n   &#8211; Grant yourself admin access for the lab.\n   &#8211; Optionally grant a test user\/group \u201cviewer\u201d access.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A catalog exists and is visible in Service Catalog.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; You can open the catalog and see it listed.\n&#8211; If you granted a second identity viewer permissions, they can see the catalog but not manage it.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create a Service Catalog product backed by the template<\/h3>\n\n\n\n<p><strong>Console actions<\/strong>\n1. In your <code>platform-basics<\/code> catalog, choose <strong>Create product<\/strong> (wording may vary).\n2. Set:\n   &#8211; Product name: <code>standard-private-gcs-bucket<\/code>\n   &#8211; Display name: \u201cStandard Private GCS Bucket\u201d\n   &#8211; Description: \u201cCreates a private Cloud Storage bucket with uniform bucket-level access and labels.\u201d\n3. Select the product source type (depends on what your Service Catalog supports):\n   &#8211; If you see an option for Terraform\/Infrastructure Manager blueprint: choose it.\n   &#8211; Point it to the Git repo and path (root) that contains the Terraform code.\n4. Define product parameters:\n   &#8211; <code>project_id<\/code> (string)\n   &#8211; <code>bucket_name<\/code> (string)\n   &#8211; <code>location<\/code> (string, default <code>us-central1<\/code>)\n   &#8211; <code>labels<\/code> (map)\n5. Create a <strong>version<\/strong>:\n   &#8211; Version: <code>1.0.0<\/code>\n   &#8211; Release notes: \u201cInitial release.\u201d<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A product appears in the catalog with a deployable version.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Open the product and confirm version <code>1.0.0<\/code> is available.\n&#8211; Confirm parameters appear as expected.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Configure the provisioning identity (service account) safely<\/h3>\n\n\n\n<p>Most governed provisioning systems use a service account to perform resource creation. The \u201cright\u201d setup depends on the Service Catalog provisioning model in your tenant.<\/p>\n\n\n\n<p><strong>Lab-safe approach<\/strong>\n&#8211; Use a dedicated service account in the <strong>Target Project<\/strong> (or in a shared tooling project) that has only the permissions needed to create buckets.<\/p>\n\n\n\n<p>Create a service account:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project TARGET_PROJECT_ID\ngcloud iam service-accounts create sc-provisioner \\\n  --display-name=\"Service Catalog Provisioner (Lab)\"\n<\/code><\/pre>\n\n\n\n<p>Grant minimal permissions to create buckets (project-level). For a bucket-only product, a common role is <code>roles\/storage.admin<\/code> (broad) or a narrower custom role. For a lab, use <code>roles\/storage.admin<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects add-iam-policy-binding TARGET_PROJECT_ID \\\n  --member=\"serviceAccount:sc-provisioner@TARGET_PROJECT_ID.iam.gserviceaccount.com\" \\\n  --role=\"roles\/storage.admin\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A service account exists and can create Cloud Storage buckets in the target project.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In IAM, confirm the binding exists.<\/p>\n\n\n\n<p><strong>Caveat<\/strong>\nYour Service Catalog provisioning engine must be configured to use this service account (or another controlled identity). The exact configuration point depends on Service Catalog implementation. <strong>Verify in your Service Catalog docs\/UI where to set the runtime\/provisioning service account.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Deploy the product into the target project<\/h3>\n\n\n\n<p><strong>Console actions<\/strong>\n1. In Service Catalog, open the product \u201cStandard Private GCS Bucket\u201d.\n2. Click <strong>Deploy<\/strong> (or <strong>Launch<\/strong>).\n3. Choose:\n   &#8211; Target project: <code>TARGET_PROJECT_ID<\/code>\n   &#8211; Version: <code>1.0.0<\/code>\n4. Fill parameters:\n   &#8211; <code>project_id<\/code>: <code>TARGET_PROJECT_ID<\/code>\n   &#8211; <code>bucket_name<\/code>: a globally unique name, for example <code>YOURNAME-sc-lab-&lt;random&gt;<\/code>\n   &#8211; <code>location<\/code>: <code>us-central1<\/code> (or your preferred region)\n   &#8211; <code>labels<\/code>: add something like <code>{ \"env\": \"lab\", \"owner\": \"yourname\" }<\/code>\n5. Submit the deployment.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Deployment begins; after completion, a bucket is created in the target project.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\nCheck the bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project TARGET_PROJECT_ID\ngcloud storage buckets describe gs:\/\/YOUR_BUCKET_NAME\n<\/code><\/pre>\n\n\n\n<p>Confirm properties:\n&#8211; <code>uniformBucketLevelAccess<\/code> enabled\n&#8211; labels present\n&#8211; <code>publicAccessPrevention<\/code> enforced (if supported by your org\/policy)<\/p>\n\n\n\n<p>Also list buckets:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage buckets list --project=TARGET_PROJECT_ID\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>Use this checklist:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Bucket exists<\/strong> in target project:\n   &#8211; <code>gcloud storage buckets describe ...<\/code> succeeds.<\/li>\n<li><strong>Labels are present<\/strong> and match input.<\/li>\n<li><strong>Public access prevention<\/strong> is enforced (unless blocked\/overridden by policy).<\/li>\n<li><strong>Audit trail<\/strong> exists:\n   &#8211; In Cloud Console, open <strong>Logging \u2192 Logs Explorer<\/strong>\n   &#8211; Filter for Cloud Storage admin activity in the target project\n   &#8211; Look for <code>storage.buckets.create<\/code> entries and identify the principal (often a service account used by provisioning)<\/li>\n<\/ol>\n\n\n\n<p>Example Logs Explorer query (adjust as needed):<\/p>\n\n\n\n<pre><code class=\"language-text\">resource.type=\"gcs_bucket\"\nprotoPayload.methodName=\"storage.buckets.create\"\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<p>Common issues you may hit:<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">1) \u201cPermission denied\u201d during deployment<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Provisioning identity lacks permissions in the target project.<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Identify which identity is performing the API calls (Audit Logs will show the principal).\n&#8211; Grant the minimum required permissions (for this lab: bucket create).\n&#8211; Re-run deployment.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">2) Bucket name already taken<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Cloud Storage bucket names are globally unique.<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Use a new name with randomness:\n  &#8211; <code>yourname-sc-lab-$(date +%s)<\/code> (Linux\/macOS)\n  &#8211; or append a random string.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">3) Organization Policy blocks creation (expected in many enterprises)<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Org Policy constraints (for example region restrictions, uniform access requirements, public access prevention, CMEK requirements) block resource creation.<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Align the product template to policy (recommended).\n&#8211; Or test in a sandbox folder\/project where policies are relaxed.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4) Service Catalog UI doesn\u2019t offer the template type\/source you expected<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Your tenant\u2019s Service Catalog feature set differs, or a feature is not enabled.<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Verify:\n  &#8211; Service Catalog availability and permissions\n  &#8211; Supported provisioning back ends and supported template sources\n&#8211; Use official docs for the currently supported authoring workflow.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">5) Deployment completes but resources are not in expected project<\/h4>\n\n\n\n<p><strong>Cause<\/strong>\n&#8211; Incorrect <code>project_id<\/code> parameter value or provider configuration.<\/p>\n\n\n\n<p><strong>Fix<\/strong>\n&#8211; Ensure <code>project_id<\/code> is passed correctly and matches the target project.\n&#8211; Review provisioning run logs\/outputs (where available).<\/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:<\/p>\n\n\n\n<p>1) <strong>Delete the deployed bucket<\/strong>\nIf your deployment engine supports destroying the deployment from Service Catalog, do that first (preferred), because it keeps state consistent.<\/p>\n\n\n\n<p>If you must delete manually:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project TARGET_PROJECT_ID\ngcloud storage rm -r gs:\/\/YOUR_BUCKET_NAME\n<\/code><\/pre>\n\n\n\n<p>2) <strong>Delete the deployment record<\/strong>\n&#8211; In Service Catalog (or the underlying provisioning engine UI), delete\/destroy the deployment\/instance if it exists.<\/p>\n\n\n\n<p>3) <strong>Remove IAM bindings and delete service account<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects remove-iam-policy-binding TARGET_PROJECT_ID \\\n  --member=\"serviceAccount:sc-provisioner@TARGET_PROJECT_ID.iam.gserviceaccount.com\" \\\n  --role=\"roles\/storage.admin\"\n\ngcloud iam service-accounts delete sc-provisioner@TARGET_PROJECT_ID.iam.gserviceaccount.com\n<\/code><\/pre>\n\n\n\n<p>4) <strong>Delete the product and catalog<\/strong>\n&#8211; In Service Catalog, delete product <code>standard-private-gcs-bucket<\/code>\n&#8211; Delete catalog <code>platform-basics<\/code><\/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>Design each product around a <strong>clear contract<\/strong>: purpose, inputs, outputs, limits, and versioning.<\/li>\n<li>Prefer <strong>small, composable products<\/strong> over giant \u201cdo everything\u201d templates.<\/li>\n<li>Use environment-specific variants: <code>dev<\/code>, <code>stage<\/code>, <code>prod<\/code> to enforce different sizing and controls.<\/li>\n<li>Treat products as <strong>APIs<\/strong>: stability matters. Use semantic versioning and deprecation policies.<\/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 dedicated <strong>provisioning service account<\/strong> per catalog or per product family.<\/li>\n<li>Grant least privilege:<\/li>\n<li>Prefer custom roles for narrowly scoped provisioning.<\/li>\n<li>Avoid <code>Owner<\/code>\/<code>Editor<\/code> except in sandbox labs.<\/li>\n<li>Use groups (Google Groups \/ Cloud Identity groups) for access, not individual users.<\/li>\n<li>Separate responsibilities:<\/li>\n<li>Catalog admins (publish)<\/li>\n<li>Security reviewers (approve)<\/li>\n<li>Consumers (deploy)<\/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>Embed cost controls:<\/li>\n<li>default small sizes<\/li>\n<li>autoscaling caps<\/li>\n<li>budget products or required labels<\/li>\n<li>Enforce labels\/tags for chargeback:<\/li>\n<li><code>cost_center<\/code>, <code>app<\/code>, <code>env<\/code>, <code>owner<\/code>, <code>data_classification<\/code><\/li>\n<li>Publish \u201ccost notes\u201d with each product:<\/li>\n<li>expected monthly range<\/li>\n<li>major cost drivers<\/li>\n<li>Avoid building products that always turn on expensive options \u201cjust in case\u201d.<\/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>Pick defaults that scale:<\/li>\n<li>autoscaling-friendly compute settings<\/li>\n<li>regional choices aligned with latency and user base<\/li>\n<li>Use appropriate storage classes and lifecycle policies for bucket products (where required).<\/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>For stateful products (databases, queues), include:<\/li>\n<li>backups<\/li>\n<li>multi-zone\/regional settings where required<\/li>\n<li>maintenance windows<\/li>\n<li>Provide outputs that make operations easier:<\/li>\n<li>resource names<\/li>\n<li>URLs<\/li>\n<li>service account identities<\/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 and metrics where possible.<\/li>\n<li>Ensure every product includes operational metadata:<\/li>\n<li>labels\/tags<\/li>\n<li>alerting hooks (where appropriate)<\/li>\n<li>Maintain a product runbook:<\/li>\n<li>how to deploy<\/li>\n<li>how to upgrade<\/li>\n<li>how to roll back<\/li>\n<li>how to delete safely<\/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>Standardize naming:<\/li>\n<li>prefix resources with app\/team\/env<\/li>\n<li>avoid random names except where global uniqueness forces it (buckets)<\/li>\n<li>Enforce consistent labels, and validate them in template tests.<\/li>\n<li>Align products to folder-level policies:<\/li>\n<li>region constraints<\/li>\n<li>public access prevention<\/li>\n<li>CMEK requirements<\/li>\n<li>allowed services<\/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>Service Catalog access is governed by <strong>Cloud IAM<\/strong>.<\/li>\n<li>The key security decision is <strong>who provisions resources<\/strong>:<\/li>\n<li>End-user identity (more direct accountability, but usually requires broader permissions)<\/li>\n<li>Provisioning service account (preferred for least privilege and consistency)<\/li>\n<\/ul>\n\n\n\n<p>Recommendation:\n&#8211; Use a provisioning service account with tightly scoped permissions.\n&#8211; Ensure audit logs capture the end-user requestor as well as the provisioning principal (where supported).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many resources are encrypted at rest by default in Google Cloud.<\/li>\n<li>For regulated workloads, design product variants with:<\/li>\n<li><strong>CMEK<\/strong> via Cloud KMS (keys, rotation, IAM on keys)<\/li>\n<li>Ensure templates can\u2019t bypass encryption requirements.<\/li>\n<li>Verify org policies related to encryption where applicable.<\/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>\u201cSelf-service\u201d can accidentally become \u201cself-exposure\u201d if templates create:<\/li>\n<li>public IPs<\/li>\n<li>public buckets<\/li>\n<li>open firewall rules<\/li>\n<li>Enforce guardrails at multiple layers:<\/li>\n<li>Organization Policy constraints<\/li>\n<li>secure defaults in templates<\/li>\n<li>security review before publishing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not accept secrets as plain-text template parameters.<\/li>\n<li>Use Secret Manager and reference secrets at runtime.<\/li>\n<li>Ensure provisioning run logs do not print secrets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and export audit logs to a central project.<\/li>\n<li>Monitor for:<\/li>\n<li>catalog changes (publishing, IAM changes)<\/li>\n<li>deployments of sensitive products<\/li>\n<li>For regulated environments, set retention and immutability controls where required.<\/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>Map products to compliance controls:<\/li>\n<li>logging enabled<\/li>\n<li>encryption requirements<\/li>\n<li>least privilege IAM<\/li>\n<li>network segmentation<\/li>\n<li>Treat product templates and releases as controlled artifacts (change management).<\/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 a single highly privileged provisioning service account for everything.<\/li>\n<li>Allowing broad \u201cdeploy\u201d permissions to production catalogs.<\/li>\n<li>Publishing templates without security review and automated checks.<\/li>\n<li>Relying on templates alone without org policies.<\/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>Build a \u201cpromotion pipeline\u201d for products:<\/li>\n<li>dev catalog \u2192 staging catalog \u2192 prod catalog<\/li>\n<li>Require:<\/li>\n<li>code review<\/li>\n<li>policy validation tests<\/li>\n<li>security scanning (Terraform lint, policy checks)<\/li>\n<li>Maintain an emergency rollback plan:<\/li>\n<li>older product version remains available<\/li>\n<li>clear remediation steps for impacted deployments<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Service Catalog\u2019s exact implementation and maturity can vary, confirm the specifics in official docs for your tenant. Common limitations and gotchas in catalog-driven provisioning include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Feature availability varies<\/strong>: Some orgs may have Service Catalog but not all template types\/source integrations enabled.<\/li>\n<li><strong>Not an ITSM system<\/strong>: It doesn\u2019t replace request\/approval workflows by itself (though it can be integrated with external systems).<\/li>\n<li><strong>IAM complexity<\/strong>: You must manage:<\/li>\n<li>catalog\/product access<\/li>\n<li>target project permissions<\/li>\n<li>provisioning identity permissions<\/li>\n<li><strong>Policy conflicts<\/strong>: Org Policy constraints can block product deployments. This is good for security, but can surprise users if products aren\u2019t aligned.<\/li>\n<li><strong>Global uniqueness constraints<\/strong>: Some resources (Cloud Storage buckets) require globally unique names; templates must handle naming strategy.<\/li>\n<li><strong>Template drift<\/strong>: If users modify deployed resources outside the provisioning system, you can get drift. Decide whether you allow manual edits.<\/li>\n<li><strong>Upgrades are non-trivial<\/strong>: New product versions don\u2019t automatically upgrade existing deployments unless your process supports it (depends on provisioning engine).<\/li>\n<li><strong>Quotas<\/strong>: Underlying services have quotas; many failed deployments are quota-related.<\/li>\n<li><strong>Logging costs<\/strong>: Standardized products that \u201cturn on all logs\u201d can increase logging spend dramatically.<\/li>\n<li><strong>Cross-project deployments<\/strong>: Products that span projects (network in one, apps in another) are more complex and require careful IAM and dependency ordering.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Service Catalog is one option in a broader space: self-service provisioning, governed templates, and platform engineering.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Infrastructure Manager (Terraform)<\/strong> without a catalog: great for platform teams, but less of a curated \u201cstorefront\u201d for end users.<\/li>\n<li><strong>Cloud Marketplace \/ Private Catalog<\/strong>: oriented to third-party and marketplace solutions; not always the same as internal IaC product catalogs. (Terminology can be confusing\u2014verify your exact Google Cloud feature set.)<\/li>\n<li><strong>Custom portal<\/strong> (Backstage, internal UI) triggering Terraform pipelines: maximum flexibility, more engineering effort.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Service Catalog<\/strong>: mature, with constraint and governance features; deep AWS integration.<\/li>\n<li><strong>Azure<\/strong>: patterns include Azure Managed Applications, Azure Marketplace private offers, and template specs (feature availability evolves).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Backstage + Scaffolder templates<\/strong>: developer experience, extensible; you build the guardrails.<\/li>\n<li><strong>Terraform Enterprise \/ Terraform Cloud private module registry<\/strong>: great for module reuse and governance; not necessarily a \u201ccatalog storefront\u201d unless you build one.<\/li>\n<li><strong>ServiceNow<\/strong> integration: ITSM request workflows; provisioning can call Terraform\/Cloud APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/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>Google Cloud Service Catalog<\/strong><\/td>\n<td>Governed self-service for approved solutions in Google Cloud<\/td>\n<td>Central catalog experience, IAM integration, auditability, standardized products<\/td>\n<td>Feature set and integrations may vary; depends on supported provisioning back ends<\/td>\n<td>You want curated \u201cgolden path\u201d provisioning with Google Cloud-native access control<\/td>\n<\/tr>\n<tr>\n<td>Infrastructure Manager (Terraform) alone<\/td>\n<td>Platform teams managing IaC directly<\/td>\n<td>Strong IaC workflow, Terraform compatibility<\/td>\n<td>Less \u201cstorefront\u201d UX for non-IaC users<\/td>\n<td>Your consumers are IaC-capable teams, or you already have a portal<\/td>\n<\/tr>\n<tr>\n<td>Cloud Marketplace \/ Private Catalog<\/td>\n<td>Curating third-party\/vendor solutions<\/td>\n<td>Vendor integration, procurement\/licensing workflows<\/td>\n<td>Not designed for bespoke internal templates (depends on feature)<\/td>\n<td>You primarily need controlled access to marketplace offerings<\/td>\n<\/tr>\n<tr>\n<td>AWS Service Catalog<\/td>\n<td>AWS-centric enterprises<\/td>\n<td>Mature governance constraints, portfolio model<\/td>\n<td>AWS-only; different ecosystem<\/td>\n<td>Your workloads are mainly on AWS and you need strong guardrails<\/td>\n<\/tr>\n<tr>\n<td>Backstage + CI\/CD + Terraform<\/td>\n<td>Platform engineering orgs<\/td>\n<td>Highly customizable developer portal<\/td>\n<td>You build\/maintain everything; governance is on you<\/td>\n<td>You need a bespoke IDP and have engineering capacity<\/td>\n<\/tr>\n<tr>\n<td>Terraform Cloud\/Enterprise<\/td>\n<td>Large Terraform shops<\/td>\n<td>Policy as code, private modules, drift detection features<\/td>\n<td>Not a native \u201ccatalog storefront\u201d by default<\/td>\n<td>You standardize on Terraform governance and want strong policy controls<\/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 financial services)<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\n&#8211; Hundreds of teams deploy workloads across many Google Cloud projects.\n&#8211; Security incidents occurred due to public buckets and overly broad IAM.\n&#8211; The cloud platform team is overloaded with tickets for \u201ccreate me a VPC \/ bucket \/ cluster\u201d.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Service Catalog provides:\n  &#8211; \u201cRegulated Bucket (CMEK + retention)\u201d\n  &#8211; \u201cGKE Standard &#8211; Regulated\u201d\n  &#8211; \u201cCloud Run Private Service\u201d\n  &#8211; \u201cProject Bootstrap &#8211; Prod\u201d\n&#8211; Catalogs segmented by environment:\n  &#8211; <code>dev-catalog<\/code>, <code>prod-catalog<\/code>\n&#8211; Provisioning via controlled service accounts with least privilege.\n&#8211; Folder-level Organization Policies enforce:\n  &#8211; region restrictions\n  &#8211; public access prevention\n  &#8211; CMEK requirements for certain folders\n&#8211; Central audit log export to a security logging project; alerts in SIEM.<\/p>\n\n\n\n<p><strong>Why Service Catalog was chosen<\/strong>\n&#8211; Enables self-service while enforcing approved patterns.\n&#8211; Integrates with Cloud IAM and audit logging.\n&#8211; Reduces platform ticket load while improving governance.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; 30\u201360% reduction in time to provision standard infrastructure\n&#8211; Fewer policy violations and faster compliance evidence collection\n&#8211; Better cost attribution through mandatory labels and budgets<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (growing SaaS)<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\n&#8211; Small SRE team supports multiple product squads.\n&#8211; Teams keep reinventing Terraform for the same patterns; reliability issues due to inconsistent defaults.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; A small Service Catalog with ~10 products:\n  &#8211; Cloud Run baseline\n  &#8211; Pub\/Sub topic\/subscription baseline\n  &#8211; Private bucket baseline\n  &#8211; Cloud SQL baseline\n&#8211; A lightweight release process:\n  &#8211; Git repo with templates\n  &#8211; code review + basic validation\n  &#8211; versioned product releases<\/p>\n\n\n\n<p><strong>Why Service Catalog was chosen<\/strong>\n&#8211; Gives developers a consistent, fast path for provisioning without learning every detail.\n&#8211; Reduces the operational burden on SREs.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Faster onboarding for new engineers\n&#8211; More consistent reliability and observability\n&#8211; Predictable platform patterns as the org grows<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Service Catalog the same as Cloud Marketplace?<\/strong><br\/>\nNot necessarily. Cloud Marketplace focuses on third-party and Google-provided solutions and procurement flows. Service Catalog is typically about <strong>internal, approved products<\/strong> for self-service provisioning. Google Cloud naming and navigation can vary\u2014verify your tenant\u2019s feature set in official docs.<\/p>\n\n\n\n<p>2) <strong>Is Service Catalog an ITSM tool?<\/strong><br\/>\nNo. It\u2019s a cloud provisioning\/governance layer, not a ticketing\/approval\/CMDB system. It can complement ITSM tools.<\/p>\n\n\n\n<p>3) <strong>Do I need Terraform to use Service Catalog?<\/strong><br\/>\nNot always, but many catalog provisioning systems rely on IaC templates. If your tenant uses Infrastructure Manager-backed products, Terraform is a common format. <strong>Verify supported template types<\/strong>.<\/p>\n\n\n\n<p>4) <strong>How does Service Catalog enforce security?<\/strong><br\/>\nPrimarily through:\n&#8211; IAM control over who can deploy what\n&#8211; secure defaults in templates\n&#8211; organization policies that block noncompliant configurations\n&#8211; audit logging of actions<\/p>\n\n\n\n<p>5) <strong>Can I restrict who can deploy production products?<\/strong><br\/>\nYes\u2014use separate catalogs for prod and restrict IAM to approved groups.<\/p>\n\n\n\n<p>6) <strong>How do I prevent users from editing resources after deployment?<\/strong><br\/>\nYou generally can\u2019t fully prevent edits without strict IAM and governance. Many organizations:\n&#8211; restrict direct edit permissions\n&#8211; use drift detection processes\n&#8211; treat manual edits as exceptions<\/p>\n\n\n\n<p>7) <strong>How do upgrades work when I publish a new product version?<\/strong><br\/>\nOften, existing deployments do not automatically upgrade. Upgrading requires a managed process (depends on the provisioning engine and how deployments are tracked). Plan versioning and migration guidance.<\/p>\n\n\n\n<p>8) <strong>What\u2019s the biggest operational benefit?<\/strong><br\/>\nReducing platform team ticket load while improving consistency\u2014self-service with guardrails.<\/p>\n\n\n\n<p>9) <strong>What\u2019s the biggest risk?<\/strong><br\/>\nAccidentally creating a \u201cone-click blast radius\u201d if you grant broad deploy permissions or use an overprivileged provisioning identity.<\/p>\n\n\n\n<p>10) <strong>Can Service Catalog deploy across multiple projects?<\/strong><br\/>\nSome products may span multiple projects (network + app projects), but it increases complexity. You need careful IAM, dependency management, and clear ownership boundaries.<\/p>\n\n\n\n<p>11) <strong>How do I track who requested a deployment?<\/strong><br\/>\nUse Cloud Audit Logs and the deployment records. Ensure your logging\/export pipeline retains logs long enough for audit needs.<\/p>\n\n\n\n<p>12) <strong>How do I ensure cost allocation?<\/strong><br\/>\nEnforce labels\/tags and consider a \u201cbudget + alerts\u201d product. You can also enforce labeling via policy and template validation.<\/p>\n\n\n\n<p>13) <strong>Can I integrate with CI\/CD?<\/strong><br\/>\nYes conceptually: templates should be built and tested via CI, then published as new product versions. The publishing mechanism depends on Service Catalog APIs\/automation support (verify in docs).<\/p>\n\n\n\n<p>14) <strong>Is Service Catalog suitable for beginners?<\/strong><br\/>\nConsumers can be beginners (deploying approved products), but authors\/publishers should understand IAM, org policy, and the provisioning toolchain.<\/p>\n\n\n\n<p>15) <strong>What if Service Catalog isn\u2019t available in my organization?<\/strong><br\/>\nSome features may be restricted, in preview, or not enabled. Alternatives include Infrastructure Manager directly, Terraform pipelines, or an internal developer portal.<\/p>\n\n\n\n<p>16) <strong>How do I keep product templates compliant as policies evolve?<\/strong><br\/>\nMaintain a policy-driven test suite and update templates proactively. Also rely on org policies as the ultimate enforcement layer.<\/p>\n\n\n\n<p>17) <strong>Should I create one catalog or many?<\/strong><br\/>\nStart small (one or two catalogs), then split by environment or domain as governance needs grow.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Service Catalog<\/h2>\n\n\n\n<p>Because Google Cloud product URLs can change as services evolve, include both direct links (where known) and official search links.<\/p>\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 docs (search)<\/td>\n<td>Google Cloud search: Service Catalog docs \u2014 https:\/\/cloud.google.com\/search?q=Service%20Catalog%20documentation<\/td>\n<td>Safest starting point to find the current official documentation entry and latest workflows<\/td>\n<\/tr>\n<tr>\n<td>Official pricing (search)<\/td>\n<td>Google Cloud search: Service Catalog pricing \u2014 https:\/\/cloud.google.com\/search?q=Service%20Catalog%20pricing<\/td>\n<td>Helps confirm whether there is a standalone SKU or if billing is only for underlying resources<\/td>\n<\/tr>\n<tr>\n<td>Pricing calculator<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Estimate costs for the resources your catalog products deploy<\/td>\n<\/tr>\n<tr>\n<td>IAM fundamentals<\/td>\n<td>Cloud IAM documentation \u2014 https:\/\/cloud.google.com\/iam\/docs<\/td>\n<td>Required to design least-privilege catalog access and provisioning identities<\/td>\n<\/tr>\n<tr>\n<td>Resource hierarchy<\/td>\n<td>Resource Manager overview \u2014 https:\/\/cloud.google.com\/resource-manager\/docs<\/td>\n<td>Understanding org\/folder\/project structure is key to catalog scoping and governance<\/td>\n<\/tr>\n<tr>\n<td>Org Policy<\/td>\n<td>Organization Policy documentation \u2014 https:\/\/cloud.google.com\/resource-manager\/docs\/organization-policy\/overview<\/td>\n<td>Enforce guardrails that apply to catalog deployments<\/td>\n<\/tr>\n<tr>\n<td>Audit logging<\/td>\n<td>Cloud Audit Logs documentation \u2014 https:\/\/cloud.google.com\/logging\/docs\/audit<\/td>\n<td>Track catalog and deployment activities for security and compliance<\/td>\n<\/tr>\n<tr>\n<td>Terraform on Google Cloud<\/td>\n<td>Terraform on Google Cloud (search) \u2014 https:\/\/cloud.google.com\/search?q=Terraform%20Google%20Cloud%20best%20practices<\/td>\n<td>Useful for designing safe, reusable templates behind products<\/td>\n<\/tr>\n<tr>\n<td>Infrastructure Manager (search)<\/td>\n<td>Google Cloud search: Infrastructure Manager \u2014 https:\/\/cloud.google.com\/search?q=Infrastructure%20Manager%20Google%20Cloud<\/td>\n<td>If your Service Catalog uses Infrastructure Manager, this is the key provisioning back end<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud Skills Boost<\/td>\n<td>Google Cloud Skills Boost catalog \u2014 https:\/\/www.cloudskillsboost.google<\/td>\n<td>Hands-on labs for IAM\/governance and provisioning-adjacent topics<\/td>\n<\/tr>\n<tr>\n<td>Official YouTube<\/td>\n<td>Google Cloud Tech (YouTube) \u2014 https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Talks and demos related to platform engineering, governance, and provisioning patterns<\/td>\n<\/tr>\n<tr>\n<td>Architecture Center<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures you can convert into catalog products<\/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>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, cloud operations, IaC, governance patterns<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>DevOps\/SCM learners, release engineers<\/td>\n<td>SCM, CI\/CD, automation, DevOps foundations<\/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 ops practitioners, administrators<\/td>\n<td>Cloud operations, monitoring, cost, security basics<\/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, operations engineers<\/td>\n<td>Reliability engineering, SLOs, operations<\/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 + analytics practitioners<\/td>\n<td>AIOps concepts, observability, automation<\/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 current offerings)<\/td>\n<td>Students, engineers looking for practical guidance<\/td>\n<td>https:\/\/www.rajeshkumar.xyz<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify specifics)<\/td>\n<td>DevOps engineers, beginners to intermediate<\/td>\n<td>https:\/\/www.devopstrainer.in<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps support\/training (verify specifics)<\/td>\n<td>Teams needing short-term help or coaching<\/td>\n<td>https:\/\/www.devopsfreelancer.com<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and learning resources (verify specifics)<\/td>\n<td>Ops teams, DevOps practitioners<\/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<\/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>Platform engineering, IaC, governance<\/td>\n<td>Build internal golden-path products; set up IAM and org policy guardrails; implement cost controls<\/td>\n<td>https:\/\/www.cotocus.com<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training<\/td>\n<td>DevOps transformation, platform enablement<\/td>\n<td>Create a catalog publishing pipeline; define template standards; train teams on safe self-service<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify service scope)<\/td>\n<td>CI\/CD, cloud operations, automation<\/td>\n<td>Implement multi-environment catalogs; integrate audit logging exports; define operational runbooks<\/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 Service Catalog<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals: projects, billing, APIs<\/li>\n<li>Cloud IAM: roles, service accounts, IAM conditions (where applicable)<\/li>\n<li>Resource hierarchy: org\/folder\/project and inheritance<\/li>\n<li>Organization Policy basics<\/li>\n<li>Terraform fundamentals (if your catalog uses Terraform-based provisioning)<\/li>\n<li>Logging and audit logs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Service Catalog<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering \/ Internal Developer Platforms (IDPs)<\/li>\n<li>Policy as code patterns (OPA, policy validation pipelines)<\/li>\n<li>Advanced governance:<\/li>\n<li>centralized logging architecture<\/li>\n<li>Security Command Center operations<\/li>\n<li>VPC Service Controls design<\/li>\n<li>SRE practices for standardized platforms:<\/li>\n<li>SLOs for platform products<\/li>\n<li>runbooks and error budgets<\/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>Platform Engineer<\/li>\n<li>Cloud Architect<\/li>\n<li>DevOps Engineer<\/li>\n<li>SRE<\/li>\n<li>Cloud Security Engineer \/ Security Architect<\/li>\n<li>Governance\/Risk\/Compliance (technical) roles<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Service Catalog is not typically a standalone certification topic, but it aligns strongly with:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud Security Engineer\n&#8211; Professional Cloud DevOps Engineer<\/p>\n\n\n\n<p>(Verify current certification listings on Google Cloud\u2019s official certification site.)<\/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 Bootstrap\u201d product that applies baseline labels, log sinks, and IAM groups.<\/li>\n<li>Create dev\/prod variants of a Cloud Run service baseline with different scaling limits.<\/li>\n<li>Create a \u201cSecure Bucket\u201d product with lifecycle rules, retention policy, and CMEK.<\/li>\n<li>Implement a promotion pipeline: template repo \u2192 validation \u2192 publish version \u2192 notify consumers.<\/li>\n<li>Add cost visibility: enforce labels and auto-create a budget per project.<\/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>Access and resource management<\/strong>: Controls and processes for managing identities, permissions, policies, and resource hierarchy in Google Cloud.<\/li>\n<li><strong>Catalog<\/strong>: A curated collection of deployable products in Service Catalog.<\/li>\n<li><strong>Product (Solution)<\/strong>: A deployable template published for internal self-service.<\/li>\n<li><strong>Version<\/strong>: A specific release of a product\/template, intended to be stable and reproducible.<\/li>\n<li><strong>Provisioning identity<\/strong>: The service account or principal that actually calls Google Cloud APIs to create resources.<\/li>\n<li><strong>Least privilege<\/strong>: Granting only the permissions needed to complete a task and nothing more.<\/li>\n<li><strong>Organization Policy<\/strong>: Constraint-based guardrails applied at org\/folder\/project to restrict configurations (e.g., allowed regions).<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: Logs that record administrative actions and access events across Google Cloud services.<\/li>\n<li><strong>IaC (Infrastructure as Code)<\/strong>: Managing infrastructure through declarative code (e.g., Terraform).<\/li>\n<li><strong>Drift<\/strong>: When real resources differ from what the template\/state expects due to manual changes.<\/li>\n<li><strong>CMEK<\/strong>: Customer-Managed Encryption Keys, typically using Cloud KMS.<\/li>\n<li><strong>Uniform bucket-level access<\/strong>: Cloud Storage setting that disables object ACLs and uses IAM-only access control.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Google Cloud <strong>Service Catalog<\/strong> is a practical way to deliver <strong>governed self-service provisioning<\/strong>\u2014a key part of <strong>Access and resource management<\/strong> for organizations that want speed without sacrificing security.<\/p>\n\n\n\n<p>It matters because it helps platform teams publish <strong>approved, versioned \u201cgolden path\u201d products<\/strong> while controlling who can deploy them and ensuring deployments remain auditable and policy-compliant. The biggest cost drivers typically come not from the catalog itself, but from the <strong>resources deployed<\/strong> (compute, storage, networking, and especially logging\/export patterns). Security success depends on <strong>least-privilege provisioning identities<\/strong>, strong <strong>organization policies<\/strong>, and disciplined <strong>versioning and review<\/strong>.<\/p>\n\n\n\n<p>Use Service Catalog when you need standardized, auditable self-service across many teams and projects. If you only need basic IaC reuse, consider simpler alternatives like Infrastructure Manager or Terraform pipelines without a storefront.<\/p>\n\n\n\n<p>Next step: confirm your tenant\u2019s current Service Catalog capabilities in the official docs (including supported template sources and provisioning back ends), then expand the lab product into a small internal catalog of 5\u201310 foundational building blocks (project bootstrap, bucket baseline, Cloud Run baseline, logging sink baseline, and budget alerts).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Access and resource management<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[52,51],"tags":[],"class_list":["post-537","post","type-post","status-publish","format-standard","hentry","category-access-and-resource-management","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/537","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=537"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/537\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=537"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=537"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=537"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}