The gcloud CLI is how you control most of GCP from the command line. Almost anything you can do in the Cloud Console you can do with gcloud, and the Associate Cloud Engineer exam tests your knowledge of specific commands. This is not about memorizing every flag. It is about knowing which commands exist, what they do, and when you would use them.
Before any functional gcloud command will work, you need two things: authentication and a default project. These are the two setup steps that everything else depends on.
gcloud auth login opens a browser window where you log in with your Google account. After you authenticate, gcloud can make API calls on your behalf. Without this step, every subsequent command returns an authentication error.
gcloud config set project [PROJECT_ID] tells gcloud which project to target by default. Replace [PROJECT_ID] with the actual project ID, not the project name or number. After setting this, commands that create or list resources will operate within that project unless you override the project with a flag.
gcloud init is the guided version. It walks you through authentication, project selection, and default region and zone configuration in a single interactive flow. For initial setup, gcloud init is often the fastest path.
A large category of gcloud commands follows the pattern gcloud [service] [resource-type] list. These are the commands you use to see what exists in a project.
gcloud compute instances list shows all the virtual machine instances in your project. gcloud projects list shows all projects associated with your account. gcloud services list shows which APIs are currently enabled in the active project. These three commands appear in exam scenarios involving troubleshooting, auditing, and discovery tasks.
gcloud projects describe [PROJECT_ID] returns detailed metadata about a specific project, including the project number, which is useful when interacting with certain APIs that require the number rather than the ID.
The exam tests several gcloud commands for inspecting and managing IAM policies. These commands follow a consistent pattern: gcloud [resource-type] get-iam-policy [resource-name].
gcloud projects get-iam-policy [PROJECT_ID] retrieves all the roles and members that have access to a project. This is how you audit who has what access at the project level.
gcloud storage buckets get-iam-policy gs://[BUCKET_NAME] retrieves the IAM policy on a specific Cloud Storage bucket. When a user cannot access a bucket and you need to check their permissions, this is the command.
gcloud compute instances get-iam-policy [INSTANCE_NAME] --zone=[ZONE] retrieves the IAM policy on a specific Compute Engine instance. This is less commonly tested but appears in scenarios involving instance-level access control.
gcloud iam roles copy replicates a custom IAM role from one project to another. This is useful when you have defined a custom role with specific permissions and want to use the same role definition in a different project without recreating it manually.
gcloud logging read "[FILTER]" --limit=[N] retrieves log entries matching a filter expression. The exam uses this pattern in troubleshooting scenarios. A common filter is "resource.type=gce_instance AND severity>=ERROR" which retrieves error-level and above log entries from Compute Engine instances. Knowing that you can read logs via gcloud without going to the Cloud Console is useful for exam scenarios that describe command-line-only environments.
Almost all gcloud commands follow the same pattern: gcloud [group] [sub-group] [command] [resource] [flags]. Once you understand this pattern, you can often guess the right command for a resource you have not memorized. gcloud compute instances list, gcloud container clusters list, gcloud sql instances list all follow the same structure with different service groups.
The group name usually matches the GCP service: compute for Compute Engine, container for GKE, sql for Cloud SQL, storage for Cloud Storage (newer syntax), run for Cloud Run. Learning the group names helps you reason about commands you have not seen before.
The Associate Cloud Engineer exam does not require you to type commands. It shows you commands and asks what they do, or describes a task and asks which command accomplishes it. The questions focus on the commands most relevant to setting up environments, inspecting resources, managing access, and troubleshooting.
The commands I covered here are the ones most likely to appear. Auth and init for setup, compute and projects list for inspection, get-iam-policy for access auditing, and logging read for troubleshooting. Know what each does and in what scenario you would reach for it.
My Associate Cloud Engineer course includes the full set of gcloud commands covered on the exam, with context for how they appear in scenario-style questions.
One important but easy-to-overlook gcloud command is gcloud services enable. Most GCP services require their API to be enabled in the project before you can use them. In the Cloud Console, this happens automatically when you navigate to a service. From the command line, you need to enable the API explicitly.
gcloud services enable run.googleapis.com
gcloud services enable container.googleapis.comThe exam occasionally presents troubleshooting scenarios where a team cannot create a Cloud Run service or a GKE cluster, and the root cause is that the API is not enabled. Knowing that gcloud services list --enabled shows which APIs are active and that gcloud services enable activates them is enough to answer these questions correctly.
Many gcloud commands accept scope flags that override your default configuration. The --project flag targets a specific project without changing your active configuration. The --zone and --region flags override compute location defaults. Understanding that these flags exist means you do not need to switch configurations for single commands in a different context.
