Prepare and test your skills
Prepare and test your skills
Identity and Access Management (IAM) roles for service management control who can turn Google Cloud services on and who can use the resources those services create. Enabling an API activates that service inside one Google Cloud project, so new service accounts, quotas, and billable resources appear inside that project boundary. A developer therefore needs both permission to enable the service and separate service-specific roles to configure and use it afterward.
Roles to enable APIs are the IAM roles that grant permission to change a service from disabled to enabled in a project. The key permission is serviceusage.services.enable, which allows activation of services such as compute.googleapis.com or pubsub.googleapis.com. This permission is included in the Owner role (roles/owner) and in the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin) for admins who manage services without full project ownership.
| Task | Required role | Key permission |
|---|---|---|
| Enable APIs in a project | Owner (roles/owner) or Service Usage Admin (roles/serviceusage.serviceUsageAdmin) | serviceusage.services.enable |
| Create a new project | Project Creator (roles/resourcemanager.projectCreator) | resourcemanager.projects.create |
| Select an existing project | Any role already granted on that project | No additional permission |
The access flow runs from administrator to user to project: the administrator grants the role to the user on the IAM page, and the user then runs gcloud services enable or uses the console enable flow for that project.
Exam tip: Enabling an API does not grant permission to use it — serviceusage.services.enable only turns the service on, and using Compute Engine, Pub/Sub, or Dataflow still requires their own admin, worker, or viewer roles.
Roles needed after activation are the service-specific IAM roles that let a principal configure networks, run jobs, and access data created by enabled APIs. Enabling Compute Engine, Dataflow (opens in a new tab), Pub/Sub, Logging, Secret Manager, and Storage only creates the ability to create resources, so API calls still fail until the caller has the right role for that service. User accounts and service accounts normally get different roles because the user starts the work and the service account performs the work on the user's behalf.
Common roles required after enabling services include:
roles/iam.serviceAccountUser) for managing access and impersonating service accountsA typical split gives Service Account User to the developer so the developer can attach service accounts to jobs, while the Compute Engine default service account receives worker roles such as Dataflow Worker, Pub/Sub Editor, Storage Object Admin, and BigQuery Data Editor. To verify access, open the IAM page, select the project, find the user or group in the Principal column, and check the Role column for each required role.
Security implications of enabling services come from the identities and broad access that activation can create automatically in a project. Enabling or first using a service that depends on Compute Engine automatically creates the Compute Engine default service account with the email format PROJECT_NUMBER-compute@developer.gserviceaccount.com, and that account acts as the identity for virtual machines and managed jobs in the project. Depending on organization policy, that default account might automatically receive the Editor role on the project, which grants broad read and write access far beyond what most workloads need.
Production environments should follow least privilege by creating a new service account, granting only the minimum roles the workload requires, and removing the automatic Editor grant. The automatic grant is controlled by the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint, which is enforced by default for organizations created after May 3, 2024. Before replacing broad roles with narrower ones, use Policy Simulator to see the impact of the change, then grant and revoke roles on the IAM page or with gcloud projects add-iam-policy-binding.
Quota management and billing requirements explain how an enabled service consumes limited capacity and how that use is paid for. A Google Cloud project is the container and isolation boundary for both quota and billing, so limits and charges are managed independently for each project. When a service is enabled, it becomes associated with the project, adds monitoring pages in the console, and can incur billing if billing is enabled for that project.
The Google Cloud project as a boundary means the project owns resources such as API keys, service accounts, Compute Engine VMs, Cloud Storage buckets, and BigQuery datasets. Usage telemetry and dashboards are grouped by project, which lets teams manage quota limits (opens in a new tab) and billing separately for each workload. When an application calls an API, the project that owns the application credentials is the client project and the project that owns the target resource is the resource project, so one request can involve multiple resource projects.
Enabling an API for a project requires accepting the Terms of Service and billing responsibility for that API. When an API depends on other APIs, those dependencies are enabled at the same time, and some IAM roles only become visible after the associated service is enabled. Enabling requires the serviceusage.services.enable permission, which project creators typically hold through Owner (roles/owner) or through Service Usage Admin (roles/serviceusage.serviceUsageAdmin).
Monitoring quota usage is the process of checking current limits and consumption so an application does not hit an operational limit and lose availability. Current limits can be viewed on the Quotas & System Limits page or on the APIs & Services page, where the Value column shows the default quota unless an adjustment was made. If no value exists for a quota, the value appears as Unlimited, and selecting Show usage chart displays usage over time.
To view API-specific quotas from the Quotas & System Limits page:
The APIs & Services page shows the same information scoped to one API. From APIs & Services, select the project, click the API name, then open the Quotas & System Limits tab to see quotas for that API. The Metrics tab for the selected API shows current API usage, and the Filter box can query quotas by property name or value.
A quota adjustment changes the provided quota value for a project up or down based on resource usage and application needs. Requests are subject to review, with one email acknowledging receipt and a later email stating whether the request was approved. Depending on the API, billable usage can also be capped explicitly to limit charges.
To adjust a quota value in the console:
Adjusting a value to a number equal to or greater than the default can remove a previous quota override, and then the dialog shows an acknowledgment checkbox to confirm that removal. Quotas can also be managed with the Cloud Quotas API for programmatic preferences, with gcloud quotas info and gcloud quotas preferences in the Google Cloud CLI, and with the quota adjuster for automatic monitoring and requests.
Billing requirements for enabled services mean a project needs an active billing account linked to it before chargeable Cloud APIs can be used. API usage in a project is charged to the billing account linked to that project, so creating a billing account alone is not enough until it is linked. Teams should review pricing for each service to understand potential costs and verify that billing is enabled before enabling chargeable APIs.
Disabling an API that is no longer used reduces misuse and accidental billing charges, and the same console, gcloud CLI, and Service Usage API paths used to enable services can disable them. Because enabling accepts billing responsibility, unused services should not remain enabled when no workload depends on them. Keeping billing linked, quotas monitored, and unused services disabled connects service lifecycle, capacity, and cost in one project boundary.
Exam tip: API usage is charged to the billing account associated with the project, so the account must be created and then linked to the project before chargeable APIs can be used.
Service activation is the process that changes a Google Cloud API from disabled to enabled inside a specific project so applications can consume that service. The Service Usage API (opens in a new tab) is the control system that manages this lifecycle, and both the Google Cloud Console and the gcloud CLI send enable requests to it on behalf of the project. A service cannot be used until it is enabled, billing is verified, and the caller has permission to enable services and to use the related resources.
Permission and project prerequisites are the IAM and billing conditions that must be true before any activation method can succeed. Activation requires the serviceusage.services.enable permission, which is included in Owner (roles/owner) and in Service Usage Admin (roles/serviceusage.serviceUsageAdmin). Project creators usually already hold this permission through ownership, while other users must be granted Service Usage Admin or a custom role with the same permission.
The request must also target a selected project and a verified billing state. Selecting an existing project requires only that the user already has a role on it, while creating a project requires Project Creator (roles/resourcemanager.projectCreator). Billing must be verified as enabled on the project, and some APIs add extra steps such as accepting Terms of Service, getting approval for a preview API, or providing organization contact details.
Google Cloud Console activation uses a guided enable flow that enables one or more APIs for the selected project in the browser. The user selects or creates a project, confirms billing is enabled, then opens an enable link that lists the required APIs, such as Compute Engine, Dataflow, Cloud Logging, BigQuery, Pub/Sub, Cloud Storage, and Resource Manager. The console then sends the enable request from the user identity to the Service Usage API, which changes each listed service to enabled for that project.
This method is useful for tutorials or proofs of concept because related APIs can be enabled together in one click. For example, a Cloud Deploy setup enables Cloud Deploy, Cloud Build, Google Kubernetes Engine, Cloud Run, and Cloud Storage together, so the delivery pipeline depends on all five services being enabled. If resources will not be kept, creating a new temporary project is preferred because deleting the project later removes all associated resources.
gcloud CLI activation performs the same enable operation from a terminal or Cloud Shell using the gcloud services enable command. The command names the full service endpoints for the project, such as compute.googleapis.com, dataflow.googleapis.com, logging.googleapis.com, bigquery.googleapis.com, pubsub.googleapis.com, storage.googleapis.com, and cloudresourcemanager.googleapis.com. The CLI sends the request from the authenticated user to the Service Usage API, which enables each named service in the configured project.
A typical activation workflow follows an ordered sequence:
gcloud init, then create the project with gcloud projects create PROJECT_ID and select it with gcloud config set project PROJECT_ID.serviceusage.services.enable through Owner or Service Usage Admin.gcloud services enable with all required API names in one command so dependencies are satisfied together.gcloud auth application-default login when using a local shell, then grant workload roles to users and service accounts.Other workloads use the same pattern with different API sets, such as logging.googleapis.com monitoring.googleapis.com cloudtrace.googleapis.com telemetry.googleapis.com for observability or binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com for Binary Authorization with Google Kubernetes Engine.
API dependencies exist when one solution cannot run unless several related APIs are enabled together in the same project. Dataflow depends on Compute Engine for workers, Pub/Sub for ingestion, Cloud Storage for staging, BigQuery for output, Cloud Logging for logs, and Resource Manager for project metadata. Eventarc event routing depends on Artifact Registry, Cloud Build, Logging, Pub/Sub, Cloud Run, Cloud Storage, and Eventarc itself, so missing any one API breaks the flow from event source to destination.
Common dependency bundles from the documentation include:
The two interactive activation methods compare as follows:
| Method | How activation is sent | Choose when |
|---|---|---|
| Google Cloud Console | User opens an enable-flow link for the selected project | A guided, one-click setup of multiple related APIs is needed |
| gcloud CLI | User runs gcloud services enable with service endpoint names | A repeatable, scriptable setup or Cloud Shell workflow is needed |
Exam tip: Having a service-specific role like BigQuery Data Editor does not grant API activation; activation still requires serviceusage.services.enable through Owner or Service Usage Admin.
serviceusage.services.enable permission through Owner or Service Usage Admin, and using the service afterward still requires its own service-specific roles.PROJECT_NUMBER-compute@developer.gserviceaccount.com.gcloud services enable sends a request to the Service Usage API, which changes the service from disabled to enabled in the selected project.Enabling a Google Cloud API requires the serviceusage.services.enable permission through the Owner role or the Service Usage Admin role. This permission only changes the service from disabled to enabled in the selected project, so using Compute Engine, Pub/Sub, or Dataflow afterward still requires their own service-specific roles.
The Google Cloud Console sends activation through a guided enable-flow link for the selected project and is best when a one-click setup of multiple related APIs is needed. The gcloud CLI sends activation with a gcloud services enable command naming the service endpoints and is best when a repeatable, scriptable setup or Cloud Shell workflow is needed.
The Google Cloud project is the isolation boundary for quota and billing, so limits and charges are managed independently for each project. API usage is charged to the billing account linked to that project, so the account must be created and linked before chargeable APIs can be used, and current limits and consumption can be checked on the Quotas and System Limits page.
Enabling or first using a service that depends on Compute Engine automatically creates the Compute Engine default service account with the email format PROJECT_NUMBER-compute at developer.gserviceaccount.com. Depending on organization policy, that account might automatically receive the Editor role on the project, so production environments should follow least privilege by creating a new service account with only the minimum required roles.
Last updated