1.3.2. The gcloud, gsutil, and bq Command-Line Tools
💡 First Principle: Google Cloud splits its command-line surface into three specialized tools rather than one giant command, because Cloud Storage's object model, BigQuery's query/job model, and everything-else's resource model are different enough that a single unified syntax would be worse for all three.
gcloud is the general-purpose tool covering the vast majority of Google Cloud services — creating VMs, managing IAM policies, configuring networking, and deploying to GKE or Cloud Run. gsutil is specialized for Cloud Storage object operations (copying, listing, setting object metadata and ACLs) with a Unix-cp-like syntax. bq is specialized for BigQuery — running queries, managing datasets and tables, and loading data.
# gcloud: general resource management
gcloud compute instances create my-vm --zone=us-central1-a --machine-type=e2-medium
# gsutil: Cloud Storage object operations
gsutil cp ./report.csv gs://my-bucket/reports/
# bq: BigQuery queries and jobs
bq query --use_legacy_sql=false 'SELECT COUNT(*) FROM `my_dataset.my_table`'
Authentication is shared across all three: gcloud auth login (or a service account key/Workload Identity in automated contexts) establishes the identity that gsutil and bq also use — you don't authenticate each tool separately.
⚠️ Exam Trap: A scenario describing a script that needs to copy files into Cloud Storage as part of a larger automation pipeline is testing whether you reach for gsutil (or the newer unified gcloud storage commands) rather than trying to force the general-purpose gcloud compute surface to do storage work it isn't built for.
Reflection Question: Why does it make sense for BigQuery to get its own dedicated CLI tool (bq) instead of folding into gcloud, when Compute Engine, GKE, and networking all share the same gcloud surface?
