Google Cloud is a catalog. These six services are the part of it a developer actually touches on a normal application: somewhere to run, somewhere to put files, somewhere to run containers, somewhere to ask questions of data, a way to decide who is allowed, and a way to know the system is still up.
Compute Engine
Compute Engine is a virtual machine. You pick a machine type, a region and zone, a boot disk, and a service account. The instance is yours down to the operating system, which means patching, SSH, and a startup script are yours too.
Use it when the software expects a host: a vendor image, a GPU workload, a lift-and-shift process that binds to a local disk. A stateless HTTP service usually wants a smaller surface. Managed instance groups still help when you do need VMs. They replace unhealthy instances and sit behind a load balancer, so one zone failure is a capacity event instead of an outage.
Cloud Storage
Cloud Storage stores objects in buckets. A file, an image, a database export, a model artifact. It is not a disk you mount and treat like ext4, and it is not a database you query.
Name the bucket for the workload, turn on uniform bucket-level access so permissions live on the bucket rather than on individual objects, and pick a storage class from how soon you need the object back. Standard for files the app reads now. Nearline, Coldline, and Archive for data you keep and rarely touch. Hand callers a short-lived signed URL when a browser has to upload or download. Do not put a service-account key in the frontend so it can talk to the bucket itself.
Google Kubernetes Engine
GKE runs Kubernetes so you do not build the control plane. The choice that matters is Autopilot or Standard. Autopilot bills pods and manages the nodes. Standard gives you the node pools, the machine types, and the operational work that comes with them.
Reach for GKE when you have more than one service, a real need for rolling deploys, and a team that will own manifests. A single container with one port is often happier on Cloud Run. On GKE, give each workload its own Kubernetes service account and map it to a Google service account with Workload Identity. The pod then calls Cloud Storage or BigQuery as itself. A node-wide credential that every container can use is how one compromised pod becomes the project's IAM policy.
BigQuery
BigQuery is a warehouse you query with SQL. It is built for scans over large tables, not for the transaction that records a user clicking a button. That row belongs in a database. The export of those rows, once you want to aggregate a year of them, belongs here.
On-demand queries bill bytes read. Partition the table on a date or an ingestion time, and cluster it on the columns you filter, or a SELECT * from a curious notebook becomes the bill. Load files from Cloud Storage, or stream them when the dashboard cannot wait for a batch. Keep the service account that runs queries on a role that can read the datasets it needs, and stop there.
IAM
IAM is the control plane under the other five. A principal (a user, a group, or a service account) gets a role on a resource. Prefer predefined roles over the basic Owner, Editor, and Viewer roles. Editor on a project is permission to change almost everything in it.
Developers usually get into trouble with service accounts, not with the console. Create one per workload. Grant it on the bucket or the dataset, not on the whole project. Let GitHub Actions or a GKE pod assume it through Workload Identity Federation. A downloaded JSON key in a repository is a credential you cannot rotate cleanly, and it will outlive the person who generated it.
Cloud Monitoring
Cloud Monitoring is where metrics, uptime checks, and alerting policies live, next to Cloud Logging. Turning it on is not the same as having a signal. Decide what "down" means before you draw a chart.
For a service behind a load balancer, an uptime check from outside the project tells you users cannot connect. An alerting policy on error rate or latency tells you the process is up and still failing. Log-based metrics turn a line your application already writes into a number you can page on. Page a person only when they can do something. A channel that fires on every restart trains the team to mute it.
How they fit
A typical application uses three of these on the first deploy. The process runs on Compute Engine or GKE. Files sit in Cloud Storage. IAM decides which service account may read the bucket. BigQuery shows up when someone asks a question the application database should not answer. Cloud Monitoring is the one to add before the first customer, because the other five will not tell you they are failing.
Learn them as a set of decisions. Where does this process run, where does this byte live, who is allowed to touch it, and who gets told when it breaks.