Before you can do anything useful with the gcloud CLI, you need to authenticate and tell it which project to target. These two requirements are not optional. Every functional gcloud command requires both, and the Associate Cloud Engineer exam tests whether you know the right commands to satisfy them and in what order.
gcloud auth login authenticates your gcloud installation with your Google account. When you run this command, it opens a browser window where you log in with your Google credentials. After you complete the login, gcloud receives an access token that lets it make API calls on your behalf.
Without running gcloud auth login first, every gcloud command that touches GCP resources will fail with an authentication error. This is the first step in any new gcloud setup.
There is a related command worth knowing: gcloud auth application-default login. This sets credentials for applications running locally that need to call GCP APIs, such as a Python script using a Cloud client library. It is different from gcloud auth login in that it writes credentials to a well-known file that libraries read automatically, rather than storing credentials for the gcloud tool itself. The exam occasionally distinguishes between these two use cases.
After authenticating, you need to set a default project. The command is:
gcloud config set project [PROJECT_ID]Replace [PROJECT_ID] with the actual project ID, which is the globally unique alphanumeric identifier, not the human-readable name or the numerical project number. The project ID is what gcloud uses internally and what most gcloud commands expect when a project flag is required.
Setting a default project means you do not need to specify the project on every command. Without a default, each command that requires a project context will either fail or prompt you to specify one. Most teams set a default project for their current working environment and change it when they switch projects.
gcloud init is the guided setup command that does authentication, project selection, and compute defaults in a single interactive flow. When you run it, gcloud walks you through each step:
First, it asks whether you want to log in or re-initialize with an existing account. If you choose to log in, it opens the browser for authentication. Second, it lists the GCP projects associated with your account and asks you to select one as the default. Third, it asks if you want to set a default compute region and zone, which affects Compute Engine and GKE commands that need a location.
For a fresh installation, gcloud init is often the fastest way to get to a working state. For experienced users who know exactly what they want to set, running gcloud auth login followed by gcloud config set project separately gives more control without the interactive prompts.
A common workflow question on the exam involves finding the project ID before you can set it. If you know the project name but not the ID, gcloud projects list shows all projects associated with your account along with their names, IDs, and project numbers. This is typically the step before running gcloud config set project in a fresh environment where you need to look up the correct project ID.
The full setup sequence for a new environment or a new developer on the team follows this order: authenticate with gcloud auth login, find the project ID with gcloud projects list if needed, set the default project with gcloud config set project [PROJECT_ID], and optionally set a default compute zone with gcloud config set compute/zone [ZONE]. Or run gcloud init to do all of this interactively.
After these steps, the gcloud CLI is ready to use. Commands like gcloud compute instances list or gcloud services list will work without additional flags because the project context is set.
The Associate Cloud Engineer exam tests this setup sequence in troubleshooting and procedural scenarios. A new team member cannot run gcloud commands and gets authentication errors: the answer is gcloud auth login. A developer can authenticate but their commands return permission errors because they are targeting the wrong project: the answer involves gcloud projects list followed by gcloud config set project.
The exam also distinguishes between the setup commands. gcloud init does everything interactively but does not give you fine-grained control. gcloud auth login handles only authentication. gcloud config set project handles only project targeting. Knowing which command is appropriate for which scenario is what the exam tests.
For the full CLI setup workflow in the context of the GCP ACE exam, including how this fits into the broader environment setup scenarios on the exam, my Associate Cloud Engineer course covers it with worked examples.
To see which account is currently authenticated and what credentials are active:
gcloud auth listThis shows all accounts that have been authenticated, with the active account marked. If multiple team members share a workstation or if you have authenticated with multiple Google accounts, this command tells you which credentials gcloud is currently using for API calls.
To revoke credentials and log out:
gcloud auth revoke [ACCOUNT]This is relevant in scenarios where you need to switch from one Google account to another or clean up credentials on a shared machine.
In automated environments, gcloud does not use user account credentials from gcloud auth login. Instead, it authenticates as a service account. The standard approach is to use workload identity federation or to activate service account credentials with a key file:
gcloud auth activate-service-account --key-file=service-account-key.jsonThis is relevant for CI/CD pipelines, Cloud Build jobs, and scripts running on Compute Engine instances where a human is not present to log in interactively. The Associate Cloud Engineer exam occasionally tests the distinction between user account authentication and service account authentication for automated workloads.
