Every GCP service is backed by an API, and most of those APIs are not enabled by default in a new project. Before you can create a Cloud Run service, spin up a GKE cluster, or send a Pub/Sub message, the API for that service has to be active in your project. This is one of the first troubleshooting scenarios the Associate Cloud Engineer exam puts in front of you, and missing it costs points that are easy to get back once you understand the pattern.
Google Cloud uses an API-first architecture. Every action you take in the Cloud Console, every gcloud command you run, and every client library call your application makes goes through the same underlying API. Enabling the API is what activates that surface for your project.
When you create a brand new project, only a handful of APIs come enabled automatically. The Cloud Resource Manager API and the Cloud Billing API are among them because project management itself depends on them. Most service-specific APIs, like the Compute Engine API, the Kubernetes Engine API, or the Cloud Run API, start disabled. You have to turn them on before you can use the service.
This is intentional. Enabling only the APIs you need reduces your project's attack surface. A disabled API cannot be called, which means a compromised credential cannot abuse a service you are not using.
There are three ways to enable an API: through the Cloud Console, through the gcloud CLI, or automatically when you first interact with a service through the console navigation.
In the Cloud Console, navigate to APIs and Services, then click Library. Search for the service you need, click the API, and click Enable. The change takes effect within seconds.
From the gcloud CLI:
gcloud services enable run.googleapis.com
gcloud services enable container.googleapis.com
gcloud services enable pubsub.googleapis.comEach service has an API identifier in the format servicename.googleapis.com. Cloud Run is run.googleapis.com. GKE is container.googleapis.com. Pub/Sub is pubsub.googleapis.com. You can enable multiple APIs in one command by listing them space-separated.
To check which APIs are currently active in a project:
gcloud services list --enabledTo see all available APIs including disabled ones, remove the --enabled flag.
The Associate Cloud Engineer exam surfaces API enablement through troubleshooting scenarios. The pattern is always some variation of: a team tries to use a GCP service and gets an error, and you need to identify the root cause and resolution.
Common signals in the question that point to a disabled API: the project is newly created, the team is using a service they have not used in this project before, the error message mentions the API name or a permission denied error that does not match any IAM issue. When you see these clues, the answer almost always involves navigating to APIs and Services and enabling the relevant API.
A typical scenario: a developer tries to deploy a container to Cloud Run in a new project and gets an error. They have the Cloud Run Admin IAM role. What is the issue? The Cloud Run API is not enabled. The IAM role grants permission to use the service, but the service cannot be called until the API is active.
In production environments, teams often enable APIs as part of their infrastructure-as-code setup. A Terraform configuration for a new project typically includes a block that enables all required APIs before creating any resources. This ensures that when the infrastructure runs, the services are ready to use.
The exam does not test Terraform syntax, but understanding that API enablement is a dependency for resource creation helps you reason about the order of operations in setup scenarios. You cannot create a Cloud SQL instance if the SQL Admin API is disabled, regardless of how correct everything else is.
Enabling an API does not immediately create costs. You only incur charges when you actually use the service. However, some services have minimum charges or charges that accrue even when idle, so it is worth understanding the pricing model of any API you enable. For the Associate Cloud Engineer exam, the key point is that the relationship between API enablement and billing is indirect: the API must be enabled to use the service, and using the service is what generates charges.
One detail that the Associate Cloud Engineer exam relies on is that API enablement is scoped to a project. Enabling the Cloud Run API in your development project does not enable it in your production project. Each project maintains its own set of enabled APIs independently. This matters when setting up new environments: a common mistake is to enable all the necessary APIs in one project and then assume they are available everywhere. They are not.
This also means that when your organization provisions new projects programmatically through scripts or Terraform, enabling the required APIs is part of that provisioning process. Organizations that skip this step find that deployments fail in new projects even though the same deployment worked perfectly in the original project.
There is also the concept of API dependencies. Some APIs require other APIs to be enabled first. Enabling the GKE API, for example, automatically enables the Compute Engine API because GKE relies on Compute Engine infrastructure. The Cloud Console handles this automatically, enabling dependencies on your behalf, but when scripting API enablement you may need to account for the order of operations.
My Associate Cloud Engineer course covers API enablement in the context of project setup and the broader troubleshooting scenarios that appear on the exam, including how to quickly diagnose the most common new-project configuration errors.
