When you start studying for the Professional Cloud Architect exam, one of the first things you need to internalize is that there are three ways to interact with Google Cloud, and the exam expects you to know when each one fits. Those three are the Cloud Console, the Software Development Kit (SDK), and the APIs themselves. They look different on the surface, but they all eventually do the same thing.
I want to walk through how these three relate to each other, then spend most of the article on the SDK and the gcloud command line tool, because that is where the Professional Cloud Architect exam tends to test you in detail.
The Cloud Console is the graphical interface you reach in a browser at console.cloud.google.com. You log in with your Google account and you get a visual view of your projects, your VMs, your buckets, your IAM policies, and so on. If you are new to a service, the Console is usually the easiest place to learn what the service even does, because the forms and dropdowns make the available options visible without you having to read the docs first.
The SDK is a toolkit you install on your own machine. It includes a command line interface called gcloud, plus client libraries for languages like Python, Java, and Node.js, plus a few service-specific tools like bq for BigQuery and gsutil for Cloud Storage. The SDK is what you use when you want to script something, automate a workflow, or build an application that talks to Google Cloud.
APIs are the lowest level. Every Google Cloud service exposes a REST or gRPC API over HTTPS endpoints. If you want raw programmatic access, or if you are integrating from a system that does not have a Google client library available, you call the APIs directly.
Here is the part that is worth knowing for the exam and for how you think about Google Cloud in general. The SDK is a wrapper around the APIs. When you run a gcloud command, gcloud is making API calls for you behind the scenes and presenting the result. The Console is also a wrapper around the APIs. When you click around in the browser, the Console is making API calls for you behind the scenes. So you do not really have three independent ways to access Google Cloud. You have one access surface, the APIs, and two more convenient layers on top of it.
That said, the exam treats them as three separate things, and you should too when you are answering questions. If a question asks how to deploy something repeatably across environments, the answer is the SDK or the API, not the Console. If a question asks how a non-technical reviewer can check the state of a resource, the Console is fine.
The SDK is a bundle. The pieces you need to know are:
Of those four, gcloud is the one you will see tested most often on the Professional Cloud Architect exam. The exam likes to give you a scenario and ask which gcloud command achieves it, or it likes to put a gcloud command in front of you and ask what it does. So your study time on the SDK should weight gcloud heavily.
gcloud is the command line equivalent of the Cloud Console, and in some areas it can do more than the Console can. A few examples of common commands:
gcloud app deploy
# Deploys an application to App Engine
gcloud projects create my-project-id --name="My Project"
# Creates a new project called "My Project"
gcloud compute instances list
# Lists all Compute Engine VMs in the active project
gcloud logging read "resource.type=gce_instance AND severity>=ERROR" --limit=10
# Retrieves the 10 most recent error-level log entries from Compute Engine instancesNotice the structure. gcloud commands generally read as gcloud, then the service or product (compute, projects, logging, app), then the action (list, create, deploy, read), then any flags. Once you see that pattern, unfamiliar gcloud commands on the exam become a lot easier to parse.
To use the SDK, you install it on your own computer. Two common paths:
Both paths give you the same result. The package manager route is convenient if you already manage other tools that way, since updates flow through the same system you already use.
Once gcloud is installed, there are two setup steps before most functional commands will work. The exam can ask about this.
Step 1: authenticate. Run:
gcloud auth loginThis opens a browser, you log in with your Google account, and gcloud now has credentials it can use to call the APIs on your behalf.
Step 2: set the default project. Run:
gcloud config set project [PROJECT_ID]Replace PROJECT_ID with the actual ID of the project you want to operate in. This is necessary because most gcloud commands operate inside the context of a specific project, and gcloud needs to know which one you mean. Without these two steps, gcloud will refuse to run most functional commands.
If you work across multiple projects or environments, you do not want to keep retyping gcloud config set project every time you switch contexts. gcloud configurations solve this. A configuration is a named bundle of settings, like a project, a default zone, a default region, and an account, that you can switch between as a unit.
Creating and using a configuration looks like this:
# Create a new configuration named "prod"
gcloud config configurations create prod
# Set properties on the active configuration
gcloud config set project my-prod-project
gcloud config set compute/zone us-central1-a
gcloud config set compute/region us-central1
# Later, switch to a different configuration
gcloud config configurations activate devThis is useful in real work and it is the kind of thing the Professional Cloud Architect exam likes to ask about, because it maps directly onto how an architect actually manages multiple environments.
A handful of commands come up often enough that I would memorize them:
There is a fourth way you can run gcloud, which is Cloud Shell, a browser-based environment with gcloud already installed and authenticated to your account. It is technically not a separate access method, since you are still using gcloud and the SDK, but it removes the install step entirely. I cover Cloud Shell in its own article because it has enough specifics around session lifetime, persistent disk, and editor integration that it deserves the space.
For the Professional Cloud Architect exam, I would treat this material as foundational rather than as a destination. You need to be fluent enough that when a scenario question pours out a gcloud command, you can read it and know what it is doing without slowing down. You also need to know that authenticate-then-set-project sequence, because it is the one piece of gcloud setup the exam will actually quiz you on directly.
Beyond that, do not over-invest in memorizing every gcloud subcommand. The exam tests architecture decisions far more than command line trivia. Knowing which access method fits a given scenario, and being comfortable reading a gcloud command, is most of what you need.
My Professional Cloud Architect course covers ways to access GCP alongside the rest of the IAM and governance material.
