Google Cloud Platform Beginner

Cloud computing is the on-demand delivery of computing resources — servers, storage, databases and networking — over the internet, paid for as you use them. Instead of buying and racking your own hardware, you rent capacity from a provider and scale up or down in minutes.

Key benefits are elasticity (grow and shrink with demand), pay-as-you-go pricing (no large upfront capital expense), global reach (deploy near your users), and managed services (the provider runs the undifferentiated heavy lifting). The trade-off you accept is depending on a third party and learning their tools.

Google Cloud Platform (GCP) is Google’s suite of cloud services running on the same global infrastructure that powers Search, Gmail and YouTube. It offers infrastructure (virtual machines, networking, storage), platform services (databases, serverless, Kubernetes) and higher-level data and AI products such as BigQuery and Vertex AI.

You interact with Google Cloud through the Cloud Console (web UI), the gcloud CLI, client libraries, and REST/gRPC APIs. Everything you create — a VM, a bucket, a network — is a resource that lives inside a project and is governed by IAM.

To start, you create a Google Cloud account with a Google identity and a billing method. New customers receive a free trial with credits (commonly \$300 to spend over 90 days) plus an Always Free tier that includes small monthly allowances for selected products — for example a small e2-micro VM, a Cloud Storage allowance and some BigQuery query volume.

The free trial will not auto-charge you when credits run out; you must explicitly upgrade to a paid account. Still, set a budget alert early so a forgotten resource never surprises you.

The Cloud Console is the web interface at console.cloud.google.com. From it you switch projects, browse resources, view billing and open product pages. A project selector at the top scopes everything you see.

Cloud Shell is a free, browser-based Linux terminal with the gcloud CLI, kubectl, Python, Docker and an editor pre-installed. It comes with 5 GB of persistent home storage and is already authenticated as your user, so you can run commands without installing anything locally. It is the fastest way to try the CLI.

The gcloud CLI is the command-line tool for managing Google Cloud. Commands follow a readable pattern: gcloud GROUP SUBGROUP COMMAND, for example gcloud compute instances list. Use --help on any command to see flags.

Configurations store reusable settings such as the active project, region and zone, so you do not repeat them on every command. gcloud init walks you through authentication and picking a default project. The companion tools gsutil (Cloud Storage) and bq (BigQuery) ship in the same SDK.

Google Cloud organizes everything in a resource hierarchy. At the top is the Organization node (tied to your domain). Below it you can create Folders to group projects by department, team or environment. The workhorse is the Project: every resource (VMs, buckets, networks) belongs to exactly one project, which is the unit of billing, quotas and isolation.

IAM policies and organization policies set high in the tree are inherited downward, so a permission granted at the organization level applies to all folders and projects beneath it. Each project has a globally unique project ID.

Google Cloud’s infrastructure is divided into regions — independent geographic areas such as us-central1 or europe-north1 — each containing multiple isolated zones like europe-north1-a. A zone is roughly a single failure domain (think one data-center facility); a region groups nearby zones.

You choose a region or zone to place latency near users and to meet data-residency rules. Some resources are zonal (a VM, a standard disk), some are regional (a regional disk, a subnet), and some are global (a VPC network, a global load balancer, an image). Spreading resources across zones improves availability.

Cloud IAM (Identity and Access Management) answers “who can do what on which resource.” A policy binds members (a user, group, service account or domain) to roles. A role is a bundle of permissions.

There are three kinds of roles. Basic roles — Owner, Editor, Viewer — are broad and legacy; avoid them in production. Predefined roles are curated per service (for example roles/storage.objectViewer) and follow least privilege. Custom roles let you assemble an exact permission set when nothing predefined fits. Always grant the least privilege that gets the job done.

A service account is a special identity used by applications and VMs — not people — to authenticate to Google Cloud APIs. Instead of embedding a human’s credentials, your code runs as a service account that has only the roles it needs.

On Compute Engine you attach a service account to a VM and grant it roles; the VM then obtains short-lived tokens automatically, so you avoid storing long-lived keys. Downloadable service-account keys exist but are a security risk and should be avoided where possible. Prefer attached identities and workload identity federation.

Compute Engine provides virtual machines (called instances) running on Google’s infrastructure. You pick an image (OS), a machine type, a zone and a boot disk, then start the VM in seconds. Each VM lives in a VPC subnet and gets an internal IP, and optionally an external IP.

You connect over SSH. The easiest way is gcloud compute ssh, which manages keys for you and can tunnel through the browser or IAP. There is no need to manually copy public keys for the common case — gcloud and OS Login handle it.

Machine types define a VM’s vCPUs and memory. General-purpose families like e2 and n2 suit most workloads; c2 is compute-optimized, m2 memory-optimized. You can also build custom machine types. You pay per second (after a one-minute minimum) for the resources allocated.

To cut cost dramatically, Spot VMs (the successor to preemptible VMs) offer steep discounts in exchange for being reclaimed by Google with a 30-second warning when capacity is needed. They are ideal for fault-tolerant, restartable batch work — not for stateful databases. Sustained-use and committed-use discounts reward steady or pledged usage.

Cloud Storage is object storage for unstructured data — images, backups, logs, static sites. Objects live in buckets, which have a globally unique name and a chosen location (regional, dual-region or multi-region).

Each object has a storage class that trades retrieval cost against storage cost: Standard for hot, frequently accessed data; Nearline for roughly monthly access; Coldline for quarterly; Archive for rarely accessed, long-term retention. Object Lifecycle rules can automatically transition or delete objects as they age. Use gcloud storage (or legacy gsutil) to manage buckets.

A persistent disk is durable block storage attached to a Compute Engine VM, independent of the VM’s lifecycle — you can detach it, reattach it to another VM, snapshot it or resize it while it stays available. The boot disk is itself a persistent disk.

Types include pd-standard (HDD, cheap, throughput-oriented), pd-balanced (general SSD), pd-ssd (high-performance SSD), and newer Hyperdisk options. Disks are zonal or regional. By contrast, local SSDs are physically attached, very fast, but ephemeral — their data is lost when the VM stops. Use snapshots for backups.

A VPC (Virtual Private Cloud) is your private, software-defined network in Google Cloud. Unlike many providers, a Google Cloud VPC is a global resource: one VPC can span every region. Inside it you create subnets, and each subnet is regional with its own internal IP range (CIDR block).

Resources in different regions but the same VPC can communicate over Google’s private backbone using internal IPs, without traversing the public internet. You can use auto mode (a subnet auto-created per region) or, for production, custom mode where you define each subnet and its range deliberately.

VPC firewall rules control which traffic may reach your VMs. Each rule has a direction (ingress or egress), a priority (lower number wins), an action (allow or deny), and targets chosen by network tags or service accounts. You match traffic by source/destination ranges and protocols/ports.

Every VPC starts with implied rules: deny all ingress, allow all egress. You then add explicit allow rules — for example permit TCP 22 (SSH) and TCP 80/443 (web) only to instances carrying a specific tag. Tagging VMs lets you apply the right rules without listing individual IPs.

Every VM has an internal IP for private communication inside the VPC. To be reachable from the internet, it also needs an external IP, which can be ephemeral (changes if released) or static (reserved and stable). Outbound internet from VMs without an external IP can go through Cloud NAT.

Rather than exposing one VM, you typically put a load balancer in front of a group of backends. Google Cloud offers global HTTP(S) load balancing with a single anycast IP that routes users to the nearest healthy backend, plus health checks that pull unhealthy instances out of rotation. This gives scalability and resilience.

Security in the cloud is a shared responsibility. Google secures the infrastructure — the physical data centers, hardware, host operating system, and the global network — and the managed parts of each service. You, the customer, are responsible for security in the cloud: your data, IAM grants, network and firewall configuration, OS patching on your VMs, and application code.

The boundary shifts with the service model. With raw VMs (IaaS) you patch the guest OS; with serverless and fully managed services, more responsibility moves to Google. Google calls the collaborative version shared fate, where it actively helps you start secure with blueprints and recommendations.

Billing in Google Cloud is organized by a Cloud Billing account, which pays for one or more projects. You can inspect costs in the console’s billing reports, broken down by project, service and label, and export detailed billing data to BigQuery for analysis.

To avoid surprises, create a budget with alert thresholds (for example notify at 50%, 90% and 100% of a monthly amount). Budgets alert you; they do not hard-stop spending by default. Before deploying, estimate costs with the Google Cloud Pricing Calculator. Discounts like sustained-use and committed-use further reduce steady-state bills.

Labels are key-value pairs you attach to resources — VMs, disks, buckets, projects — to organize and track them. A label like env=prod or team=payments or cost-center=1234 carries no permissions; it is metadata for filtering, grouping and especially cost attribution.

Because billing exports include labels, you can answer questions like “how much did the staging environment cost last month?” Keys and values are lowercase with limited characters, and a resource can carry many labels. Do not confuse labels (organization/billing) with network tags (which firewall rules use to target traffic).

Infrastructure as Code (IaC) means defining your cloud resources in declarative configuration files kept in version control, instead of clicking through the console. You describe the desired end state; the tool figures out how to create, update or delete resources to match it. This makes deployments repeatable, reviewable and auditable.

Google’s native tool is Deployment Manager (YAML/Jinja/Python templates). The widely used, cloud-agnostic standard is Terraform (HCL), which Google supports first-class; many teams choose it for multi-cloud and a large module ecosystem. Either way, the same config reliably reproduces an environment.

Let’s tie it together. We create a VM that installs and starts a web server on boot using a startup script, tag it so a firewall rule allows HTTP, then visit its external IP. The startup script runs as root the first time the instance boots, making the deploy fully automated.

After it boots, find the external IP with gcloud compute instances list and open it in a browser. Remember to delete resources when done so you stop being billed. This single flow exercises Compute Engine, networking, firewall rules and external IPs together.

Google Cloud offers a tiered certification path. The entry point is the Cloud Digital Leader — a foundational, non-technical exam covering cloud concepts, Google Cloud products and business value; ideal for anyone, including non-engineers.

Next is the Associate Cloud Engineer, which validates hands-on ability to deploy and operate workloads with the console and gcloud — the natural goal after this course. Beyond that sit Professional certifications (Cloud Architect, Data Engineer, Security Engineer, DevOps Engineer and more) that demonstrate deep, role-specific expertise. Build real projects between exams; practical reps matter more than memorization.