Google Cloud Service Usage Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Access and resource management

by

Category

Access and resource management

1. Introduction

What this service is
Service Usage is a Google Cloud control-plane service that lets you view, enable, and disable Google Cloud APIs and services for a project, and inspect and manage certain service quotas (where supported).

Simple explanation (one paragraph)
In Google Cloud, most capabilities (like Compute Engine, Cloud Storage, BigQuery, or Cloud Run) are exposed through APIs. Service Usage is the place where you turn those APIs “on” or “off” for a project and confirm what’s enabled. It also helps you understand and, in some cases, adjust how much of a service your project is allowed to consume (quotas).

Technical explanation (one paragraph)
Service Usage provides an API (serviceusage.googleapis.com) and corresponding Console and gcloud workflows that operate on resources like projects/{project}/services/{service}. It returns service states (enabled/disabled), supports batch enabling, supports disabling with optional dependency handling, and exposes “consumer quota” endpoints for listing quota metrics and managing quota overrides (subject to service support and permissions). It integrates with IAM for authorization and Cloud Audit Logs for governance.

What problem it solves
Without a centralized mechanism, controlling which APIs are active in a project becomes inconsistent and risky: engineers may enable APIs ad hoc, security teams may lose visibility, and operations teams may encounter failures caused by missing or accidentally disabled APIs. Service Usage solves this by providing a standard, auditable way to manage API activation and (where applicable) quota configuration—an essential part of Access and resource management on Google Cloud.

Service name status note: The current product and API are commonly referred to as Service Usage and the Service Usage API. It is an active Google Cloud service. Verify the latest naming and capabilities in the official docs: https://cloud.google.com/service-usage/docs

2. What is Service Usage?

Official purpose

Service Usage is designed to help Google Cloud customers manage the usage of Google Cloud services in their projects by: – Enabling/disabling services (APIs) – Listing enabled/available services – Understanding and managing service usage limits (quotas) where supported

Official documentation entry point: https://cloud.google.com/service-usage/docs

Core capabilities

  • Enable services/APIs on a per-project basis (including batch enable).
  • Disable services/APIs (optionally addressing dependent services, depending on method).
  • Discover which services are enabled and which are available for a project.
  • Quota visibility: list consumer quota metrics and current limits for supported services.
  • Quota override management (for supported quotas): configure overrides to cap or adjust usage limits (subject to service rules and permissions).

Major components

  • Service Usage API (serviceusage.googleapis.com)
  • REST and client libraries
  • Long-running operations for enable/disable and batch operations
  • Google Cloud Console integration
  • “APIs & Services” and API Library rely on Service Usage behind the scenes
  • gcloud CLI integration
  • gcloud services ... commands for enable/disable/list
  • gcloud services quotas ... commands for quota inspection and some overrides

gcloud reference: https://cloud.google.com/sdk/gcloud/reference/services

Service type

  • Control plane / management plane service
  • Not a data processing service; it governs whether other services can be called and what quotas apply.

Scope (regional/global/project-scoped)

  • Project-scoped for enabling/disabling APIs: you enable a service for a specific Google Cloud project.
  • The Service Usage control plane itself is global in the sense that you do not deploy it into a region or zone.
  • Quota and service state are associated with a project’s service consumer relationship.

How it fits into the Google Cloud ecosystem

Service Usage sits at the intersection of: – IAM (Identity and Access Management): who can enable/disable services and modify quotas – Resource Manager: projects as the core boundary for service consumption – Cloud Audit Logs: audit trails for service enablement/disablement and quota changes – Service Infrastructure: the underlying platform used by Google to deliver and meter APIs (Service Management and Service Control are related but distinct)

Practical takeaway: If your workload uses Google Cloud, you almost always use Service Usage—directly or indirectly—because APIs must be enabled for a project before use.

3. Why use Service Usage?

Business reasons

  • Governance and cost control: reduce accidental enablement of expensive APIs and limit runaway consumption through quotas.
  • Standardization: define an approved catalog of services and ensure projects start from a known baseline.
  • Auditability: provide evidence of change control for API activation.

Technical reasons

  • Deterministic deployments: infrastructure-as-code and CI/CD pipelines can ensure required APIs are enabled before creating resources.
  • Fewer “it worked in dev” surprises: consistent service enablement across environments.
  • Dependency management: some services require other APIs; Service Usage helps enable dependencies (often automatically or via prompts).

Operational reasons

  • Faster troubleshooting: quickly confirm if an API is disabled when errors like SERVICE_DISABLED occur.
  • Quota visibility: identify request rate limits and other constraints that can cause throttling.
  • Operational safety: disable unused APIs to reduce accidental use and noise.

Security/compliance reasons

  • Reduced attack surface: fewer enabled APIs can mean fewer ways to misuse credentials.
  • Policy enforcement: with Organization Policy constraints (where applicable), organizations can restrict which services are allowed to be enabled. (Verify exact constraint names and behavior in official docs.)

Scalability/performance reasons

  • Quota planning: knowing default limits helps you scale safely (e.g., request quotas, per-minute quotas).
  • Controlled rollout: gradually enable APIs and set conservative quotas for new teams/projects.

When teams should choose it

Use Service Usage when you need: – Repeatable project bootstrapping – Central visibility into enabled services – Programmatic API enablement/disablement – Quota inspection and (where supported) quota override management

When teams should not choose it

Service Usage is not the right tool for: – Fine-grained authorization of API calls at runtime (use IAM roles, service accounts, VPC Service Controls, API Gateway, etc.) – Monitoring usage cost directly (use Cloud Billing reports/exports) – Managing service-to-service networking (use VPC, Private Service Connect, etc.) – Producing your own managed APIs for external consumers (look at API Gateway, Cloud Endpoints, Apigee, and Service Management/Service Control)

4. Where is Service Usage used?

Industries

Service Usage is broadly applicable in any industry using Google Cloud, especially: – Financial services (strong governance and audit requirements) – Healthcare and life sciences (compliance-driven controls) – Retail/e-commerce (fast-changing environments with many projects) – Media/gaming (high scale and quota awareness) – SaaS and startups (rapid iteration with cost controls)

Team types

  • Platform engineering / cloud center of excellence (CCoE)
  • DevOps / SRE / operations
  • Security engineering / GRC teams
  • Application development teams
  • Data engineering teams
  • FinOps / cost management teams

Workloads and architectures

  • Microservices on Cloud Run / GKE
  • Data platforms on BigQuery / Dataflow
  • Event-driven systems (Pub/Sub)
  • ML pipelines (Vertex AI)
  • Enterprise landing zones (org/folder/project hierarchy)
  • Multi-project environments (per-team or per-environment isolation)

Real-world deployment contexts

  • Landing zone / project factory: new projects created with a baseline set of enabled APIs.
  • CI/CD guardrails: pipelines that refuse to deploy unless required APIs are enabled.
  • Incident response: identify whether an outage is caused by a disabled API or quota limit.
  • Security hardening: periodic review to disable unused APIs.

Production vs dev/test usage

  • Dev/test: frequent enabling/disabling during experimentation; more tolerant of changes.
  • Production: strict change control; enabling/disabling APIs should be reviewed because disabling can break workloads immediately.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Service Usage is central.

1) Project bootstrap (“API baseline”)

  • Problem: New projects start empty; engineers forget to enable required APIs.
  • Why Service Usage fits: Programmatically enable a standard set of APIs at project creation.
  • Example: A platform team creates a “web-app-prod” project and immediately enables Cloud Run, Artifact Registry, Cloud Build, Secret Manager, and Logging APIs.

2) CI/CD preflight checks

  • Problem: Deployments fail mid-pipeline because an API is disabled.
  • Why Service Usage fits: Check and enable APIs as a pipeline step.
  • Example: A Terraform pipeline runs gcloud services enable ... before applying infrastructure.

3) Reduce security exposure by disabling unused APIs

  • Problem: Too many enabled services increase risk and audit scope.
  • Why Service Usage fits: Inventory enabled APIs and disable the ones not needed.
  • Example: A security review finds Google Sheets API enabled in a production project with no usage; it is disabled.

4) Investigate SERVICE_DISABLED errors

  • Problem: Applications suddenly fail with “API has not been used in project before or it is disabled”.
  • Why Service Usage fits: Quickly verify the service enablement state.
  • Example: After a project migration, Pub/Sub calls fail—Service Usage shows pubsub.googleapis.com is disabled.

5) Controlled rollout of new capabilities

  • Problem: Teams want to adopt a new API, but leadership wants staged enablement.
  • Why Service Usage fits: Enable API only in sandbox first, then in dev, then production.
  • Example: Enable Vertex AI only for the ML sandbox project until governance is ready.

6) Quota visibility for scale planning

  • Problem: You need to know which quotas might throttle a launch.
  • Why Service Usage fits: List quota metrics and limits for critical services.
  • Example: Before a marketing event, the team checks API request quotas for a backend service.

7) Quota guardrails to prevent runaway cost

  • Problem: A bug can generate massive requests and unexpected charges.
  • Why Service Usage fits: Where supported, apply conservative quota overrides as circuit breakers.
  • Example: Cap a high-cost API’s requests/day so a bad deploy cannot explode usage.

8) Standardize service catalog across many projects

  • Problem: Different teams enable different APIs, complicating governance.
  • Why Service Usage fits: Enforce or validate a known list of enabled services.
  • Example: An org mandates only approved APIs can be enabled in production folders (often paired with Organization Policy).

9) M&A / migration: reconcile enabled services

  • Problem: Migrated workloads depend on APIs that are not enabled in the destination project.
  • Why Service Usage fits: Compare enabled services between source and destination projects.
  • Example: A script exports enabled services from old projects and applies the same set to new projects.

10) Troubleshoot quota-related errors (429 / RESOURCE_EXHAUSTED)

  • Problem: Requests are throttled with quota errors.
  • Why Service Usage fits: Inspect which quota metric is limiting you and current limits.
  • Example: Cloud Tasks enqueue calls return RESOURCE_EXHAUSTED; Service Usage helps identify the relevant quota metric.

11) Temporary lockdown during incident response

  • Problem: Suspected credential compromise and potential abuse of an API.
  • Why Service Usage fits: Disable the abused API quickly to stop further calls (with awareness of production impact).
  • Example: Disable a high-risk API in a compromised project while rotating credentials.

12) Environment parity checks

  • Problem: Dev and prod drift in enabled services, causing behavior differences.
  • Why Service Usage fits: Compare lists of enabled APIs and reconcile differences.
  • Example: Prod has Cloud Scheduler enabled; dev does not, causing tests to miss scheduled execution flows.

6. Core Features

Feature 1: List enabled services for a project

  • What it does: Shows services currently enabled in a project.
  • Why it matters: Your project can only call enabled services; this is the source of truth.
  • Practical benefit: Quick auditing and troubleshooting.
  • Limitations/caveats: Some services may be enabled by default or required; exact defaults can vary—verify in official docs.

Feature 2: List available services

  • What it does: Shows services that can be enabled for a project.
  • Why it matters: Helps discover service names like run.googleapis.com or storage.googleapis.com.
  • Practical benefit: Automations can validate service availability before enabling.
  • Limitations/caveats: Availability can depend on organization policies, billing status, region/service constraints, and permissions.

Feature 3: Enable a service (API)

  • What it does: Activates a service for a project so that API requests are allowed.
  • Why it matters: Most Google Cloud services must be enabled before use.
  • Practical benefit: Enables consistent infrastructure provisioning and application deployments.
  • Limitations/caveats:
  • Enablement is not always instantaneous; propagation may take time.
  • Enabling some services may require enabling dependencies.

Feature 4: Batch enable services

  • What it does: Enables multiple services in one operation.
  • Why it matters: Project bootstrapping often needs multiple APIs.
  • Practical benefit: Faster setup; fewer manual steps.
  • Limitations/caveats: Batch operations are still subject to permissions and dependency requirements.

Feature 5: Disable a service (API)

  • What it does: Deactivates a service for a project so API requests fail.
  • Why it matters: Reduces usage surface area and can stop unwanted consumption.
  • Practical benefit: Security hardening and cost control.
  • Limitations/caveats:
  • Disabling can immediately break production workloads.
  • Disabling an API does not necessarily delete existing resources created by that API; behavior varies by service—verify per-service docs.
  • Dependency handling must be considered; disabling a dependency can break other enabled services.

Feature 6: Dependency awareness when disabling

  • What it does: Some workflows allow disabling dependent services (or require you to address them).
  • Why it matters: Services can rely on others (e.g., build/deploy stacks).
  • Practical benefit: Avoid partial failures caused by leaving dependents in inconsistent states.
  • Limitations/caveats: Options vary by tool/command and service graph; validate with your chosen method (Console, gcloud, API).

Feature 7: Get service state and metadata

  • What it does: Retrieves a service’s state (enabled/disabled) and related details for a project.
  • Why it matters: Useful for programmatic checks and “preflight” validations.
  • Practical benefit: Automated deployment guardrails.
  • Limitations/caveats: Requires correct service name and permissions.

Feature 8: Quota visibility (consumer quota metrics)

  • What it does: Lists quota metrics and limits tied to a service for a project (where supported).
  • Why it matters: Quotas commonly cause production throttling.
  • Practical benefit: Faster troubleshooting and capacity planning.
  • Limitations/caveats: Not all quotas are adjustable; some are fixed, some require quota increase requests, and some are managed in newer quota experiences. Verify per service.

Feature 9: Quota override management (where supported)

  • What it does: Creates/updates quota overrides to adjust limits (commonly used to reduce limits as a safety control, or manage approved limits depending on service and permissions).
  • Why it matters: Prevent runaway usage; align limits with policy.
  • Practical benefit: “Circuit breaker” controls.
  • Limitations/caveats:
  • Not all quota metrics allow overrides.
  • Increasing limits often requires an approval process outside of overrides.
  • Google Cloud’s quota tooling evolves; verify whether a given quota should be managed via Service Usage or newer quota tooling in the Console for that service.

7. Architecture and How It Works

High-level architecture

Service Usage is a central control plane that governs whether a project is a consumer of a given Google Cloud service API. When you enable an API: 1. Service Usage records the enablement state for the project. 2. The target service’s infrastructure recognizes the project as an authorized consumer (subject to IAM, billing, org policy, and quotas). 3. Requests to the target service API become valid (again, subject to authz and quotas).

When you disable an API: 1. Service Usage marks it disabled for the project. 2. Calls to that API for that project typically fail with a “service disabled” error. 3. Existing resources are not necessarily removed; behavior depends on the service.

Request/control flow

  • Control plane path: Administrator or automation → Service Usage API → service enablement state stored/propagated → target service accepts/rejects calls.
  • Runtime data plane path: Application → target service API endpoint → enforcement checks:
  • Is the service enabled for the project?
  • Does the caller have IAM permission?
  • Are quotas exceeded?
  • Are there policy restrictions (e.g., VPC Service Controls perimeter, org policy restrictions)?

Integrations with related services

  • IAM: controls who can enable/disable services and modify quota overrides.
  • Cloud Resource Manager: project identification and hierarchy.
  • Organization Policy Service: can restrict which services may be enabled (constraint-based).
  • Cloud Audit Logs: records administrative actions for governance.
  • Infrastructure as Code:
  • Terraform google_project_service commonly enables APIs (uses Google APIs under the hood).
  • Other IaC tools (Pulumi, Config Connector) also need APIs enabled.

Dependency services

Service Usage doesn’t “run” inside your VPC; instead it orchestrates enablement for services that may have their own dependencies. In real deployments: – Your CI/CD system (Cloud Build, GitHub Actions, Jenkins) calls Service Usage. – Terraform/Deployment tools call Service Usage (directly or indirectly). – The application then calls the enabled service APIs.

Security/authentication model

  • Authentication: Typically OAuth 2.0 access tokens via:
  • User credentials (admin/operator)
  • Service accounts (CI/CD automation)
  • Authorization: IAM permissions such as:
  • Viewing service enablement
  • Enabling/disabling services
  • Viewing/managing quotas (where supported)

Common predefined roles (verify in IAM docs for latest): – roles/serviceusage.serviceUsageViewer – roles/serviceusage.serviceUsageAdmin

Networking model

  • Service Usage is a Google-managed API endpoint accessed over the public internet.
  • Access is typically via:
  • Google Cloud Console
  • gcloud CLI
  • REST calls to https://serviceusage.googleapis.com/
  • If you enforce restricted network egress, ensure your admin tooling can reach required Google APIs. For private access patterns, evaluate Google’s private access options and constraints (varies by API)—verify in official docs.

Monitoring/logging/governance

  • Cloud Audit Logs: Admin Activity logs track enable/disable operations and quota changes (where applicable).
  • Cloud Logging: central place to query these audit entries.
  • Cloud Monitoring: Service Usage itself isn’t typically “monitored” like a workload, but you can monitor:
  • automation failures
  • API errors returned from services due to disabled APIs or quota limits

Simple architecture diagram (Mermaid)

flowchart LR
  A[Admin / CI Pipeline] -->|gcloud / Console / REST| SU[Service Usage API]
  SU -->|Enable/Disable state| P[(Google Cloud Project)]
  App[Application] -->|Calls API| SVC[Target Google Cloud API\n(e.g., storage.googleapis.com)]
  SVC -->|Checks service enabled + IAM + quota| P

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Org[Organization / Governance]
    OP[Organization Policy\n(allowed services constraints)]
    IAM[IAM Roles & Service Accounts]
    AL[Cloud Audit Logs]
  end

  subgraph Delivery[Platform Engineering]
    Repo[Git Repo\nTerraform / Scripts]
    CI[CI/CD\nCloud Build / GitHub Actions]
  end

  subgraph Project[Google Cloud Project]
    SU[Service Usage\nEnable/Disable + Quotas]
    S1[Cloud Run API]
    S2[Artifact Registry API]
    S3[Cloud Storage API]
  end

  Repo --> CI
  CI -->|Auth as SA| IAM
  CI -->|Enable required APIs| SU
  OP -->|Restricts what can be enabled| SU
  SU --> S1
  SU --> S2
  SU --> S3
  SU --> AL

8. Prerequisites

Account/project requirements

  • A Google Cloud account with access to a Google Cloud project.
  • Ability to create projects (optional for this tutorial; you can use an existing project).

Permissions / IAM roles

At minimum, you need permissions to: – View services: typically roles/serviceusage.serviceUsageViewer – Enable/disable services: typically roles/serviceusage.serviceUsageAdmin

If you are using a service account for automation, grant the necessary roles to that service account at the project level.

Principle of least privilege: avoid granting broad roles like roles/owner just to manage APIs.

Billing requirements

  • Service Usage itself does not generally require billing to be enabled.
  • Many Google Cloud services require a billing account to create billable resources. Enabling an API alone usually does not incur charges, but using it may.
  • If you enable a paid API and then create resources, billing will apply per that service’s pricing.

Verify service prerequisites in their docs and pricing pages.

Tools needed

  • Google Cloud SDK (gcloud): https://cloud.google.com/sdk/docs/install
  • A terminal with:
  • gcloud
  • curl (optional, for direct REST calls)

Region availability

  • Service Usage is a global management service and not deployed to a region.
  • The services you enable may have regional constraints.

Quotas/limits

  • Service Usage operations can be subject to API rate limits and permissions.
  • Quota override support varies by service and metric.

Prerequisite services

  • In many projects, the Service Usage API is available by default. If you encounter errors indicating it is disabled, enable Service Usage API in the Console API Library:
  • https://console.cloud.google.com/apis/library/serviceusage.googleapis.com

9. Pricing / Cost

Pricing model (accurate overview)

  • Service Usage itself is generally provided at no additional cost as a management/control-plane API.
  • The services/APIs you enable may be billable based on their own pricing models.

Because pricing is primarily driven by downstream services, the key cost question is not “How much does Service Usage cost?” but rather: – Which APIs did you enable, and what usage do they incur?

Official starting points: – Service Usage docs: https://cloud.google.com/service-usage/docs – Google Cloud pricing overview: https://cloud.google.com/pricing – Google Cloud Pricing Calculator: https://cloud.google.com/products/calculator

Pricing dimensions

Service Usage does not typically expose SKUs you pay for directly. Cost drivers arise indirectly: 1. Downstream service usage: API requests, compute, storage, managed resources, etc. 2. Logging retention/volume: – Admin Activity audit logs are generally enabled by default for many services and are not billed the same way as data access logs; billing depends on log type and exports/retention. Verify Cloud Logging pricing details: https://cloud.google.com/logging/pricing 3. Automation overhead: – CI/CD steps that repeatedly query/enable services usually have negligible cost, but they can hit rate limits or produce logs.

Free tier

  • Service Usage does not have a typical “free tier” concept because it is not usually billed directly.
  • Many Google Cloud services have free tiers or always-free quotas; check each service’s pricing page.

Hidden or indirect costs to watch

  • Accidental enablement of expensive APIs and subsequent resource creation (e.g., deploying managed databases, running data processing jobs).
  • Dependency enablement: enabling one service might lead teams to enable several dependent services, expanding footprint.
  • Quota increases can enable higher throughput, which can increase spend if usage scales.

Network/data transfer implications

  • Enabling an API does not transfer your workload data.
  • Using enabled services may involve:
  • inter-region egress
  • internet egress
  • cross-service data movement
    These are billed per the downstream service and network pricing.

Example low-cost starter estimate

A realistic “starter” scenario: – You use Service Usage to enable a few APIs (e.g., Cloud Storage API, Cloud Run API), but you do not create billable resources. – Expected cost: typically $0 from Service Usage; downstream costs remain $0 if you do not use paid resources.

Example production cost considerations

In production, cost management becomes about: – Only enabling approved APIs – Setting guardrails (quotas where supported) – Monitoring usage and spend for enabled services (Billing reports/exports) – Periodic audits of enabled services to reduce sprawl

Cost optimization checklist: – Maintain an “approved services list” for production projects. – Use Organization Policy restrictions where applicable (verify official docs). – Use least privilege for who can enable services. – Add CI checks that prevent enabling unapproved APIs. – Regularly export enabled services list and review with security/FinOps.

10. Step-by-Step Hands-On Tutorial

Objective

Use Service Usage in Google Cloud to: 1. List enabled services in a project 2. Enable a Google Cloud API 3. Verify enablement via gcloud and direct REST calls 4. Inspect quota metrics for that service (read-only) 5. Clean up by disabling the service (or deleting the project)

This lab is designed to be safe and low-cost by avoiding creation of billable resources.

Lab Overview

You will: – Select or create a Google Cloud project – Use gcloud services to inventory APIs – Enable storage.googleapis.com (Cloud Storage API) as an example – Validate the service is enabled – View quota metrics (if available) – Disable the service to return the project to the prior state

Note: Cloud Storage itself can incur costs if you create buckets, store data, or generate requests. This lab does not create any buckets or objects.

Step 1: Set up gcloud and pick a project

1) Install and initialize gcloud (if not already): – Install: https://cloud.google.com/sdk/docs/install – Initialize:

gcloud init

2) Choose an existing project or create a new one.

To create a new project:

export PROJECT_ID="su-lab-$(date +%Y%m%d%H%M%S)"
gcloud projects create "$PROJECT_ID" --name="Service Usage Lab"

Set it as default:

gcloud config set project "$PROJECT_ID"

Fetch the project number (useful for some API calls):

export PROJECT_NUMBER="$(gcloud projects describe "$PROJECT_ID" --format='value(projectNumber)')"
echo "$PROJECT_NUMBER"

Expected outcome:
– You have a project ID selected in gcloud config. – You know the project number.

Step 2: Confirm you have the required permissions

If you lack permissions, you may see PERMISSION_DENIED errors when listing or enabling services.

Check your active identity:

gcloud auth list
gcloud config list account

Expected outcome:
– You can identify which user/service account is being used.

If you are in a managed environment, ask an administrator to grant one of: – roles/serviceusage.serviceUsageViewer (read-only) – roles/serviceusage.serviceUsageAdmin (enable/disable)

IAM roles reference (verify current roles and permissions):
https://cloud.google.com/iam/docs/understanding-roles

Step 3: List currently enabled services (API inventory)

List enabled services:

gcloud services list --enabled

For a cleaner, script-friendly output:

gcloud services list --enabled --format="value(config.name)" | sort

Save the enabled services to a file (useful for audits and change tracking):

gcloud services list --enabled --format="value(config.name)" | sort > enabled-services-before.txt
wc -l enabled-services-before.txt

Expected outcome:
– You see a list of enabled service names like iam.googleapis.com, cloudresourcemanager.googleapis.com, etc.
– You have an enabled-services-before.txt file capturing the baseline.

Step 4: Check whether the target API is already enabled

We’ll use the Cloud Storage API (storage.googleapis.com) as an example.

Check status:

gcloud services list --enabled --filter="config.name:storage.googleapis.com"

If nothing is returned, it is not enabled.

You can also query the service directly:

gcloud services describe storage.googleapis.com

Expected outcome:
– You confirm whether storage.googleapis.com is enabled already.

Step 5: Enable an API with Service Usage

Enable Cloud Storage API:

gcloud services enable storage.googleapis.com

Expected outcome:
– The command completes successfully. – The Storage API is now enabled for the project.

Verification:

gcloud services list --enabled --filter="config.name:storage.googleapis.com"

You should see storage.googleapis.com listed.

Step 6: Verify enablement via the Service Usage REST API (optional but recommended)

This step proves Service Usage is the control plane behind the scenes.

1) Get an access token:

export ACCESS_TOKEN="$(gcloud auth print-access-token)"

2) Call the Service Usage API to get the state.

Resource name format: – projects/{projectNumber}/services/{serviceName}
(Using project number is common in examples; project ID may also work in some contexts—verify if needed.)

Call:

curl -sS -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://serviceusage.googleapis.com/v1/projects/${PROJECT_NUMBER}/services/storage.googleapis.com" \
  | sed -e 's/{/{\n{/g' -e 's/,/,\n/g'

Look for: – "state": "ENABLED"

Expected outcome:
– The JSON response shows state as ENABLED.

If you see permission errors, confirm the caller has the right IAM role.

Step 7: Inspect quota metrics for the enabled service (read-only)

Quota surfaces differ by service. Some services expose several quota metrics; others expose fewer. This step is still useful to learn the workflow.

List quota metrics via gcloud:

gcloud services quotas list --service=storage.googleapis.com

To reduce output, you can format specific fields (the exact fields available can vary):

gcloud services quotas list --service=storage.googleapis.com --format="table(metric,limit.name,limit.values)"

If your gcloud version differs, run:

gcloud services quotas list --help

Expected outcome:
– You see quota metrics (if exposed) and current limits for the service.

If quotas do not appear as expected, or if a service manages quotas differently, verify per-service quota documentation and the current Google Cloud quota tooling. The Console “Quotas” UI may show details even when CLI output is limited.

Step 8: (Practical automation) Create a preflight script to ensure required APIs are enabled

Create a file named ensure-apis-enabled.sh:

cat > ensure-apis-enabled.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

REQUIRED_SERVICES=(
  "serviceusage.googleapis.com"
  "storage.googleapis.com"
)

echo "Project: $(gcloud config get-value project 2>/dev/null)"
echo "Checking required services..."

for svc in "${REQUIRED_SERVICES[@]}"; do
  if gcloud services list --enabled --format="value(config.name)" | grep -qx "$svc"; then
    echo "OK: $svc is enabled"
  else
    echo "Enabling: $svc"
    gcloud services enable "$svc"
  fi
done

echo "Done."
EOF

chmod +x ensure-apis-enabled.sh
./ensure-apis-enabled.sh

Expected outcome:
– The script reports enabled services and enables missing ones. – This is a common CI/CD building block for reliable deployments.

Validation

Run these checks:

1) Confirm Storage API enabled:

gcloud services list --enabled --filter="config.name:storage.googleapis.com"

2) Compare before/after service inventory:

gcloud services list --enabled --format="value(config.name)" | sort > enabled-services-after.txt
diff -u enabled-services-before.txt enabled-services-after.txt || true

Expected outcome:
– You see storage.googleapis.com as an added enabled service (if it wasn’t already enabled).

Troubleshooting

Common issues and fixes:

1) PERMISSION_DENIED when enabling or listing services – Cause: Your identity lacks Service Usage permissions. – Fix: Ask for roles/serviceusage.serviceUsageViewer (list) or roles/serviceusage.serviceUsageAdmin (enable/disable).

2) SERVICE_DISABLED when calling an API – Cause: The target API is disabled for the project. – Fix: Enable it:

gcloud services enable <service-name>

Then wait a minute and retry.

3) Enablement succeeded, but API calls still fail – Cause: Propagation delay or missing IAM permissions for the calling principal. – Fix: – Wait briefly and retry. – Verify the service account/user has the right roles for the target service (Service Usage only enables the API; it does not grant runtime permissions).

4) Dependencies block disable – Cause: Other services depend on the one you’re disabling. – Fix: – Review dependency warnings carefully. – Avoid disabling dependencies in production without an impact review. – Use the Console or API options carefully if you must disable dependent services (behavior differs by tool). Verify in official docs.

5) Quotas output is empty or confusing – Cause: Not all services expose quotas in the same way; tooling may vary. – Fix: Check the service-specific quota documentation and the Console Quotas page; verify current guidance in official docs.

Cleanup

Option A (recommended for this lab): disable the API you enabled:

gcloud services disable storage.googleapis.com

Verify:

gcloud services list --enabled --filter="config.name:storage.googleapis.com"

Expected outcome:
– No output for the filter (service disabled).

Option B (if you created a dedicated lab project): delete the project to remove everything:

gcloud projects delete "$PROJECT_ID"

Project deletion is irreversible and will delete all resources in the project. Use with care.

11. Best Practices

Architecture best practices

  • Treat API enablement as part of your platform “bootstrap” layer:
  • Create a baseline enabled-services set per environment (dev/test/prod).
  • Separate duties:
  • Platform automation can enable APIs; application teams consume them.
  • Design for dependency awareness:
  • Document which APIs are required for each platform capability (e.g., Cloud Run + Artifact Registry + Cloud Build).
  • Use infrastructure-as-code for consistent enablement:
  • Terraform google_project_service (or equivalent) is a common approach.

IAM/security best practices

  • Least privilege:
  • Grant roles/serviceusage.serviceUsageAdmin only to a small set of platform operators or CI/CD service accounts.
  • Grant roles/serviceusage.serviceUsageViewer broadly for visibility if appropriate.
  • Use separate service accounts for automation:
  • Make changes traceable and reduce reliance on user accounts.
  • Protect who can enable high-risk APIs:
  • Pair with Organization Policy restrictions where applicable (verify official docs and constraints).

Cost best practices

  • Approve and document which APIs are allowed in production.
  • Disable unused APIs periodically (with impact analysis).
  • Use quota guardrails where supported to prevent runaway usage.
  • Monitor spend for enabled services using Cloud Billing reports/exports rather than relying on enablement alone.

Performance best practices

  • Service Usage is not in the runtime path for your workload’s latency, but:
  • Quotas are. Keep quota limits and scaling plans aligned.
  • Validate that high-throughput services have adequate quota before launch.

Reliability best practices

  • Avoid disabling APIs in production without a rollback plan.
  • Use change management:
  • Treat enable/disable operations like configuration changes.
  • Automate verification:
  • Preflight checks in pipelines reduce production surprises.

Operations best practices

  • Keep an inventory of enabled services per project and review it:
  • Export the list regularly to a repository or asset inventory.
  • Centralize audit review:
  • Use Cloud Logging queries on audit logs for enable/disable actions.
  • Standard naming/tagging:
  • Use project labels and folder structure to reflect environment and ownership; it simplifies governance review.

Governance/tagging/naming best practices

  • Maintain:
  • Project naming conventions (app-env-region patterns if helpful)
  • Labels (owner, cost-center, data-classification)
  • Apply organization policies (where supported) to restrict service enablement in production folders.

12. Security Considerations

Identity and access model

  • Service Usage is governed by IAM.
  • You need separate permissions for:
  • Enabling/disabling services (control plane)
  • Using the enabled service’s APIs (runtime permissions)
  • Avoid conflating these:
  • Enabling storage.googleapis.com does not grant storage.objects.get or any data access.

Encryption

  • Service Usage is a management API; it does not store your application data.
  • Google API calls are encrypted in transit (HTTPS).
  • Data at rest concerns apply to downstream services (Cloud Storage, BigQuery, etc.).

Network exposure

  • Service Usage is reached via Google API endpoints.
  • If your organization restricts egress, ensure admin tooling can reach required Google APIs.
  • Consider organizational controls (proxy, egress controls) consistent with your governance model.

Secrets handling

  • Avoid embedding long-lived credentials in scripts.
  • Prefer:
  • Workload Identity / short-lived credentials where applicable
  • Service accounts with scoped IAM roles
  • Rotate keys if you must use service account keys; consider avoiding keys entirely where possible.

Audit/logging

  • Service enable/disable events should be captured in Cloud Audit Logs (Admin Activity).
  • Security teams should:
  • Monitor for unexpected enablement of sensitive APIs
  • Alert on changes in production projects/folders

Cloud Audit Logs overview: https://cloud.google.com/logging/docs/audit

Compliance considerations

Service Usage supports compliance indirectly through: – Auditability of changes – Enforceable governance (with org policy + IAM) – Reduced service surface area

Your compliance posture still depends on: – IAM policies – Downstream service configurations – Data residency and access logging requirements per service

Common security mistakes

  • Granting roles/owner to developers just so they can enable APIs.
  • Enabling broad sets of APIs “just in case”.
  • Disabling an API as a “security fix” without understanding production blast radius.
  • Assuming an enabled API is secure by default (many services require additional hardening).

Secure deployment recommendations

  • Create a controlled group for service enablement (platform team).
  • Use CI/CD service accounts with minimal required roles.
  • Use organization policies to restrict which services can be enabled in sensitive environments (verify constraints and behavior).
  • Review enabled services regularly and disable those not in use.

13. Limitations and Gotchas

Known limitations / nuances

  • Project-level enablement: Service Usage enable/disable is primarily per project; it’s not a per-resource toggle.
  • Propagation delay: After enabling, it can take time before the API is fully usable.
  • Disabling doesn’t necessarily delete resources: Many services keep resources intact; calls may fail. Cleanup behavior is service-specific—verify per-service docs.
  • Dependencies can be complex:
  • Disabling a foundational service can break multiple capabilities.
  • Dependency handling options differ between Console, gcloud, and API methods—verify your tool’s behavior.
  • Quota override support varies:
  • Not all quotas are overrideable.
  • Some increases require explicit quota increase requests.
  • Quota tooling in Google Cloud evolves; verify current recommended approach for quota management.

Quotas

  • Service Usage has its own API quotas/rate limits.
  • Target services have their own quotas.
  • Automation that repeatedly lists/enables services across many projects can hit rate limits—implement retries with backoff.

Regional constraints

  • Service Usage is global; region constraints come from the services you enable.

Pricing surprises

  • Enabling an API does not necessarily cost money, but:
  • It makes it easier to create billable resources.
  • If a pipeline automatically enables APIs, it can unintentionally expand your billable footprint.

Compatibility issues

  • Some older automation assumes a service is enabled by default; this may not hold in all environments.
  • Organization Policy restrictions may block enabling certain services even for admins.

Operational gotchas

  • “Fixing” an incident by disabling an API can cause wider outages if shared dependencies exist.
  • Multiple teams enabling/disabling APIs without coordination creates drift and instability—centralize control for production.

Migration challenges

  • When migrating projects or workloads:
  • Ensure required APIs are enabled in the new project(s).
  • Compare enabled services lists as part of migration checklists.

14. Comparison with Alternatives

Service Usage is the core Google Cloud mechanism for API enablement, but you often interact with it through other tools.

Alternatives in Google Cloud

  • Google Cloud Console API Library: UI for enabling/disabling services (uses Service Usage behind the scenes).
  • Terraform (google_project_service): declarative enablement; great for GitOps.
  • Config Connector / Kubernetes: manage GCP resources via KRM; still requires APIs enabled.
  • Organization Policy: restrict what can be enabled (governance layer, not a replacement).
  • Cloud Quotas tooling: quota management interface; may complement or supersede some Service Usage quota workflows depending on the service (verify current docs).

Alternatives in other clouds

  • Azure Resource Providers registration: Azure services often require registering providers (e.g., Microsoft.Compute) at the subscription level.
  • AWS: Many services are “available by default,” but governance is achieved through IAM policies, SCPs (AWS Organizations), and service control mechanisms. AWS has Service Quotas for quota visibility/management but not an exact equivalent of “enable API per project” because AWS service model differs.

Open-source/self-managed alternatives

There isn’t a true self-managed replacement for Service Usage because it is part of Google Cloud’s control plane. However, you can use: – Terraform/Pulumi wrappers to standardize enablement – Internal policy-as-code to validate allowed services lists

Comparison table

Option Best For Strengths Weaknesses When to Choose
Service Usage (API / gcloud) Programmatic control, scripting, automation Canonical control plane; auditable; integrates with IAM and audit logs Requires permissions; dependency/propagation nuances When you need reliable automation or troubleshooting around API enablement and quotas
Cloud Console API Library Manual operations, small teams, ad hoc enablement Easy UI; shows dependencies and helpful prompts Not ideal for consistent automation; can cause drift When you’re learning, prototyping, or doing occasional administrative changes
Terraform google_project_service GitOps/IaC-driven orgs Declarative, reviewable, consistent across environments State management complexity; must handle ordering/dependencies When you want API enablement to be code-reviewed and repeatable
Organization Policy (service restrictions) Central governance for large orgs Prevents unapproved services; supports compliance Not a tool to enable/disable directly; requires org-level governance setup When you must restrict what teams can enable in production
Azure provider registration Azure governance Similar intent (control service availability) Different cloud model; not portable conceptually When implementing the equivalent governance in Azure
AWS Service Quotas + IAM/SCPs AWS governance Strong quota visibility and org-level restrictions Doesn’t map 1:1 to per-project API enablement When implementing comparable controls in AWS ecosystems

15. Real-World Example

Enterprise example: regulated financial services landing zone

  • Problem: Hundreds of projects across dev/test/prod; auditors require proof that only approved services are used in production. Teams frequently request new services, and quota issues have caused outages during peak events.
  • Proposed architecture:
  • A “project factory” pipeline creates projects and immediately uses Service Usage to enable a baseline set of APIs.
  • Organization Policy restricts which services can be enabled in production folders (verify exact constraints in official docs).
  • A weekly job exports enabled services lists to a central repository for review.
  • Quota metrics are reviewed for critical APIs; quota changes follow change management.
  • Why Service Usage was chosen:
  • It is the canonical control-plane mechanism for API enablement.
  • Integrates with IAM and Cloud Audit Logs for traceability.
  • Works well with automation and IaC.
  • Expected outcomes:
  • Reduced audit findings (clear inventory and change history)
  • Fewer outages due to missing APIs or unexpected disablement
  • Improved cost control through reduced service sprawl and quota guardrails

Startup/small-team example: CI/CD reliability for a SaaS backend

  • Problem: A small team ships frequently. Deployments occasionally fail because a required API wasn’t enabled in a new environment project.
  • Proposed architecture:
  • A preflight script in CI uses Service Usage (via gcloud services enable) to ensure required APIs are enabled before Terraform applies.
  • Minimal set of APIs enabled: only what the stack needs.
  • Simple audit: enabled services list stored alongside infrastructure code.
  • Why Service Usage was chosen:
  • Quick to adopt without heavy governance overhead.
  • Eliminates a common class of deployment failures.
  • Expected outcomes:
  • Faster, more reliable deployments
  • Reduced “environment drift”
  • Better security posture by keeping enabled APIs minimal

16. FAQ

1) Is Service Usage the same as IAM?
No. IAM controls who can do what. Service Usage controls whether a service/API is enabled for a project. You typically need both: enable the API (Service Usage) and grant permissions (IAM).

2) Does enabling an API automatically grant permissions to use it?
No. Enablement only allows the API to be called for the project. Callers still need appropriate IAM permissions/roles for that service.

3) Does enabling an API incur cost immediately?
Usually, enabling alone does not incur charges. Costs start when you use the service (create resources, run jobs, make billable API calls). Always check the service’s pricing.

4) Why do I get SERVICE_DISABLED errors?
Commonly because the API is disabled for the project. Enable it via Service Usage (Console, gcloud, or REST) and retry after a short delay.

5) How long does it take for an API enablement to propagate?
Often seconds to minutes. If calls fail immediately after enabling, wait briefly and retry. If it persists, verify you enabled the correct API and the caller has IAM permissions.

6) Can I enable APIs at the organization or folder level?
API enablement is typically per project. Organizations/folders are used more for policy and governance. Verify current capabilities in official docs.

7) What is the difference between “available” and “enabled” services?
“Available” means a service can potentially be enabled for the project. “Enabled” means it is currently active and callable for that project.

8) Can I disable an API in production safely?
Only after impact analysis. Disabling can break workloads immediately. Prefer change management and staged rollout.

9) Does disabling an API delete resources created by that API?
Usually no, but behavior varies by service. Disabling often blocks API calls but may not remove existing resources. Verify per-service behavior.

10) What are dependent services?
Some services require other APIs to function. For example, a deployment workflow might rely on Cloud Build, Artifact Registry, and IAM APIs. Disabling a dependency can break the parent service’s workflows.

11) How do I find the correct service name (like run.googleapis.com)?
Use: – Cloud Console API Library – gcloud services list --available – Service documentation that lists the API endpoint name

12) Can Service Usage manage quotas for all services?
Quota visibility and overrides vary by service and quota metric. Some quotas are adjustable, some require quota increase requests, and some may be managed via newer quota tools. Verify in official docs.

13) What IAM role do I need to enable/disable services?
Typically roles/serviceusage.serviceUsageAdmin at the project level. Your org may use custom roles.

14) How do I audit who enabled a service?
Use Cloud Audit Logs (Admin Activity) in Cloud Logging and filter for Service Usage enable/disable actions.

15) Can I use Terraform instead of gcloud for enabling APIs?
Yes. Terraform’s google_project_service is commonly used so API enablement is code-reviewed and repeatable. Service Usage remains the underlying control-plane concept.

16) If an Organization Policy restricts services, can a project owner still enable blocked APIs?
Typically no—org policies can prevent enablement even for powerful roles. Exact behavior depends on policy configuration; verify in official docs.

17) What’s the safest way to manage service enablement across many projects?
Use a centralized platform process (project factory), IaC, restricted admin roles, organization policies, and periodic audits of enabled services.

17. Top Online Resources to Learn Service Usage

Resource Type Name Why It Is Useful
Official documentation Service Usage docs — https://cloud.google.com/service-usage/docs Canonical overview, concepts, and workflows
API reference Service Usage REST reference — https://cloud.google.com/service-usage/docs/reference/rest Exact resource names, methods, request/response schemas
CLI reference gcloud services command — https://cloud.google.com/sdk/gcloud/reference/services Practical CLI commands for enable/disable/list
Console entry point API Library — https://console.cloud.google.com/apis/library UI workflow used by many teams
IAM roles IAM roles overview — https://cloud.google.com/iam/docs/understanding-roles Understand role-based access needed for Service Usage
Audit logging Cloud Audit Logs — https://cloud.google.com/logging/docs/audit How to audit enable/disable changes
Pricing Google Cloud Pricing — https://cloud.google.com/pricing Understand that costs come from enabled services, not Service Usage itself
Cost estimation Pricing Calculator — https://cloud.google.com/products/calculator Estimate costs of services you enable and use
Quotas overview Quotas overview — https://cloud.google.com/docs/quota Background on quotas, limits, and best practices
Hands-on labs Google Cloud Skills Boost — https://www.cloudskillsboost.google/ Find guided labs related to enabling APIs, IAM, and project setup (search within the catalog)

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, SREs, platform teams, beginners to intermediate Google Cloud operations, DevOps, automation fundamentals (verify exact course outlines on site) check website https://www.devopsschool.com/
ScmGalaxy.com Students, DevOps practitioners DevOps and SCM/tooling foundations; may include cloud modules (verify) check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud ops engineers, sysadmins transitioning to cloud Cloud operations practices; Google Cloud basics (verify) check website https://www.cloudopsnow.in/
SreSchool.com SREs, reliability engineers, platform teams SRE practices, monitoring, incident response; may map to Google Cloud ops workflows (verify) check website https://www.sreschool.com/
AiOpsSchool.com Operations teams, platform teams, engineers exploring AIOps AIOps concepts; automation and ops analytics (verify) check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz Cloud/DevOps training content (verify offerings on site) Beginners to intermediate engineers https://rajeshkumar.xyz/
devopstrainer.in DevOps training and mentoring (verify offerings on site) DevOps engineers, students https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps help/training resources (verify offerings on site) Teams needing short-term expertise https://www.devopsfreelancer.com/
devopssupport.in DevOps support and training resources (verify offerings on site) Ops/DevOps teams https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify exact services on site) Platform engineering, cloud migrations, operational readiness Landing zone setup, CI/CD pipelines, governance automation (examples) https://cotocus.com/
DevOpsSchool.com DevOps consulting and training organization (verify service catalog on site) DevOps transformation, tooling adoption, cloud automation Build CI/CD standards, implement IaC, operational best practices (examples) https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting (verify exact services on site) DevOps strategy, implementation support Pipeline implementation, Kubernetes enablement, cloud ops practices (examples) https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Service Usage

To use Service Usage effectively, learn: – Google Cloud fundamentals: – Projects, folders, organizations – Billing accounts – IAM basics: – Roles, permissions, service accounts – Core operational tooling: – gcloud CLI – Cloud Console navigation – Basic cloud governance concepts: – least privilege – separation of duties – audit logs

What to learn after Service Usage

Once you understand API enablement, expand into: – Organization Policy and governance (service allow/deny restrictions) – Infrastructure as Code: – Terraform (including google_project_service) – Policy as code (where applicable) – Observability: – Cloud Logging (audit queries) – Cloud Monitoring – Cost management: – Billing exports, budgets, alerts – Service-specific operational readiness: – quotas, SLOs, capacity planning

Job roles that use it

  • Cloud engineer / platform engineer
  • DevOps engineer
  • SRE
  • Security engineer (cloud security/governance)
  • Cloud architect
  • FinOps analyst (service inventory + spend governance)

Certification path (if available)

Service Usage is not typically tested as a standalone product, but it is a practical skill within broader Google Cloud certifications. Consider: – Associate Cloud Engineer – Professional Cloud Architect – Professional Cloud DevOps Engineer
Verify current certification paths: https://cloud.google.com/learn/certification

Project ideas for practice

  • Build a “project bootstrapper” script:
  • Create project, apply labels, enable baseline APIs, write inventory file.
  • Implement a CI pipeline stage:
  • Preflight check: required APIs enabled before Terraform apply.
  • Build a compliance report:
  • Weekly export of enabled services; diff against approved list; alert on drift.
  • Incident drill:
  • Simulate SERVICE_DISABLED and quota errors in a sandbox and document runbooks.

22. Glossary

  • API (Application Programming Interface): A programmatic interface to a cloud service, typically via HTTPS endpoints.
  • Service (Google Cloud service): A Google-managed capability such as Cloud Storage, Cloud Run, BigQuery, etc., often accessed via an API like storage.googleapis.com.
  • Service enablement: Turning on a specific API for a project so that it can be used.
  • Service disablement: Turning off an API for a project so calls fail (often immediately).
  • Project: The primary isolation and billing boundary for resources and service consumption in Google Cloud.
  • IAM (Identity and Access Management): Google Cloud system that controls permissions for identities (users, service accounts).
  • Service account: A non-human identity used by applications and automation.
  • Quota: A limit on usage of a service (requests per minute, resources per project, etc.).
  • Quota override: An adjustment to quota limits (where supported), often used as a safety guardrail or to apply approved limits.
  • Cloud Audit Logs: Logs that record administrative actions and access events for Google Cloud resources and services.
  • Control plane: Management layer used to configure resources (enable APIs, set policies).
  • Data plane: Runtime layer where application traffic and data processing occur.

23. Summary

Service Usage in Google Cloud is a foundational Access and resource management service that controls which Google Cloud APIs are enabled for a project and provides visibility into service state and certain quota metrics/overrides. It matters because API enablement is a prerequisite for using most Google Cloud services, and because controlling enabled services improves security posture, operational reliability, and cost governance.

Key points to remember: – Cost: Service Usage itself is generally not a direct cost driver, but enabling APIs makes downstream spend possible. Control what’s enabled and monitor usage. – Security: Use IAM least privilege and audit logs; restrict who can enable APIs and consider organization-level policy restrictions where appropriate. – Operations: Automate enablement (CI/CD or IaC), inventory enabled services, and treat enable/disable actions as change-managed events—especially in production.

Next step: Implement API enablement as code (Terraform or scripted preflight checks) and learn how Organization Policy and audit logs combine with Service Usage for end-to-end governance.