1.3.1. Console, Cloud Shell, and Cloud SDK
💡 First Principle: Cloud Shell exists to eliminate the "it works on my machine" problem for administrative tasks — it's a pre-authenticated, pre-configured terminal that lives in your browser, so you never need to install or configure the Cloud SDK locally just to run a handful of commands.
The Google Cloud Console is the web-based graphical interface — the natural starting point for exploring services, reviewing configurations, and one-off changes. Cloud Shell is a temporary, browser-based virtual machine that Google provisions for you on demand, with the Cloud SDK, kubectl, and common developer tools already installed and already authenticated to your account — no setup required, though its underlying VM and persistent 5 GB home directory are ephemeral and shared across sessions rather than dedicated hardware. The Cloud SDK is the installable package (gcloud, gsutil, bq) you'd set up on your own workstation or CI/CD pipeline when Cloud Shell's temporary nature isn't suitable — for example, in an automated deployment pipeline that needs a persistent, dedicated environment.
⚠️ Exam Trap: Cloud Shell's underlying VM is temporary and recycled after a period of inactivity, but your home directory (including files and installed customizations you've added) persists across sessions up to its 5 GB quota — don't assume "ephemeral" means "everything is lost," and don't assume unlimited storage either.
Reflection Question: A contractor needs to run a handful of gcloud commands for a one-time audit and has no interest in installing anything locally. Which tool minimizes setup friction, and what's the tradeoff of relying on it for anything long-running?
