Build on the cloud that Google runs the world on.

The cloud is simply renting computers you access over the internet instead of buying and running your own. Google (and Amazon, and Microsoft) build enormous data centres full of servers, and you rent exactly what you need, when you need it, and pay only for that.

Why this changed everything:

• No upfront cost — no buying a $5,000 server and hoping you grow into it.
• Elastic — need 50 servers for one busy weekend? Rent them Friday, release them Monday.
• Global — serve users in Lagos and London from data centres near each.

Google’s cloud is physically spread around the planet. A region is a geographic area (for example europe-west1 in Belgium); each region has several zones (isolated data centres within it). You choose where your resources live.

Two reasons the choice matters: latency (closer to your users = faster) and resilience (spread across zones so one data centre failing does not take you down).

You manage everything through the Cloud Console (the web dashboard) or the gcloud command line, which you will meet in the intermediate level.

Everything in Google Cloud lives inside a project — a container for your resources, billing and permissions. Your first real skill is keeping projects tidy and not getting a surprise bill.

Three habits that protect you:

• Use the Free Tier — many services have an always-free allowance, plus new accounts get trial credit.
• Set a budget alert — Google emails you at, say, $5 so nothing creeps up.
• Delete what you are not using — an idle server still costs money.

"Data" is not one thing, and Google has a different tool for each shape.

• A database handles the live data of an app — users, orders, messages — with fast reads and writes.
• A data warehouse holds huge volumes of historical data for analysis — answering "what sold best last year?" across billions of rows.
• A data lake stores raw data of any kind (files, logs, images) cheaply until you decide what to do with it.

Picking the right one is half of good cloud design: do not run analytics on your live app database, and do not try to serve an app from a warehouse.

BigQuery is Google’s flagship data warehouse, and it is genuinely magical: you can query terabytes of data with ordinary SQL in seconds, with no servers to manage. You pay for the data your queries scan.

Cloud Storage is where files live — images, videos, backups, documents. You put them in a bucket (a top-level container with a globally unique name) and access them by URL.

It offers storage classes that trade cost against how often you read the data: Standard for files used often, down to Archive for backups you almost never touch but must keep — pennies per gigabyte.

These words get thrown around; here is the honest version. Artificial Intelligence (AI) is the broad goal of machines doing smart things. Machine Learning (ML) is the main way we get there — instead of writing rules by hand, you show a model many examples and it learns the pattern. Generative AI is the newest branch: models that create text, images and code, like Google’s Gemini.

The modern Cloud Digital Leader exam leans heavily on this area, because it is where cloud value is moving fastest.

Gemini is Google’s family of generative-AI models, available through Vertex AI (Google’s machine-learning platform). You can call it to summarise documents, answer questions, write code, or analyse images — without training anything yourself.

Agentic AI is the next step: instead of a model that just answers, an agent can take actions — use tools, call other services, complete a multi-step task on your behalf. This is the direction the whole industry is moving.

You do not always need to build a model. Google offers pre-trained APIs — ready-made AI you just call:

• Vision API — detect objects and text in images
• Speech-to-Text and Text-to-Speech
• Translation API — instant multilingual text
• Natural Language API — sentiment and meaning

Use a pre-trained API when a general capability is enough; train a custom model (with AutoML or Vertex AI) only when your problem is specific to your own data. The rule: start with the ready-made option, build custom only when you must.

Google gives you a ladder of ways to run your code, from most control to least worry:

• Compute Engine — full virtual machines you manage (most control).
• Google Kubernetes Engine (GKE) — managed Kubernetes for containers.
• Cloud Run — just give it a container, it runs and scales it, you manage nothing.
• Cloud Functions — run a single function on an event, no server at all.

Modernisation means moving up this ladder over time — from managing whole machines toward letting Google manage more, so your small team spends time on the product, not the plumbing.

Security in the cloud is a shared responsibility: Google secures the data centres and hardware; you secure your accounts, data and who can access what.

The core tool is IAM (Identity and Access Management), built on one principle: least privilege — give each person and service only the access it genuinely needs, nothing more. IAM answers "who can do what, on which resource".

Running well means spending wisely and knowing your system’s health. Google gives you tools for both.

Cost: billing reports show where money goes; committed-use discounts reward predictable usage; budget alerts (from lesson 03) prevent surprises.

Operations: Cloud Monitoring and Cloud Logging let you watch metrics and read logs across everything you run — the same see-it-all discipline as the DevOps course, built into the platform.

Google organises everything in a tree: Organisation → Folders → Projects → Resources. Permissions set higher up flow downward, which lets you manage access for a whole department in one place instead of per-resource.

For a small team you may only use projects — one per app or environment (e.g. myapp-dev and myapp-prod). Keeping production in its own project is the simplest, strongest safety boundary you can build: a mistake in dev cannot touch real users.

IAM grants access by binding a role (a bundle of permissions) to a member (a person or a service). Prefer predefined roles (like roles/storage.objectViewer) over the broad Owner or Editor — that is least privilege in practice.

A service account is an identity for a machine, not a human — it is how one service proves who it is to another. Your app uses a service account to read a bucket, for example.

The gcloud command-line tool does everything the console does, faster and scriptable. Cloud Shell is a free Linux terminal in your browser with gcloud already installed — nothing to set up, works from any machine.

A Compute Engine virtual machine is a full computer in the cloud that you control. You choose its machine type (how many CPUs and how much memory), its region/zone, and its operating system image.

Right-sizing matters: a machine twice as big costs twice as much, so start small and grow only when metrics say you must. For variable work, Google can even resize or autoscale for you.

Your resources live inside a VPC (Virtual Private Cloud) — your own private network in Google’s cloud. By default, almost nothing is reachable from outside; you open access deliberately with firewall rules.

A firewall rule says what traffic is allowed: for a web server you allow incoming traffic on port 80 (HTTP) and 443 (HTTPS), and SSH (port 22) only from your own address. Everything else stays closed.

When one server is not enough — too much traffic, or you want no single point of failure — you run several and put a load balancer in front. It spreads incoming requests across your servers and stops sending traffic to any that are unhealthy.

Google’s load balancer is global: users are routed to the nearest healthy servers automatically. Combined with autoscaling (add servers when busy, remove them when quiet), this is how you handle a traffic spike without panic — and without paying for idle capacity the rest of the time.

Building on the beginner bucket lesson: the engineer’s job is matching the storage class to real access patterns and automating the moves. Standard for hot data, Nearline/Coldline for monthly/quarterly access, Archive for keep-but-rarely-touch.

Two managed databases cover most needs. Cloud SQL is managed PostgreSQL or MySQL — the familiar relational database, but Google handles backups, patching and failover. Firestore is a managed NoSQL document database that scales effortlessly and syncs in real time — great for mobile and web apps.

Relational (Cloud SQL) when your data has clear structure and relationships (orders, invoices); document (Firestore) when you want flexibility and real-time updates (chat, live dashboards). "Managed" is the key word: you get a production database without becoming a database administrator.

Two ways to run containers, matching the ladder from the beginner level. GKE is managed Kubernetes — full power and control, for complex systems of many services. Cloud Run is the easy path — hand it a container image and it runs it, scales it up under load, and scales it to zero when idle, so you pay nothing when no one is using it.

Google’s Cloud Monitoring and Cloud Logging collect metrics and logs from everything you run, automatically. The engineer’s job is to build a dashboard of the few signals that matter (request rate, error rate, latency) and set an alerting policy that notifies you when a real problem starts — the four golden signals again, now on GCP.

An uptime check is Google repeatedly asking your site "are you up?" from around the world. If it stops answering, you get alerted — often before a single user complains. Pair it with an alerting policy routed to email or SMS.

Everything you have done by hand — VMs, networks, buckets, permissions — can be written as Terraform code (the same tool from the DevOps course, with Google’s provider). Your whole environment becomes a few text files in Git: reviewable, repeatable, and rebuildable with one command.