3.2.3. Loading Data and Multi-Region Redundancy
💡 First Principle: Getting data into Google Cloud and keeping it durable across regions are two separate concerns that get bundled together in practice — loading is a one-time or recurring transfer problem, while redundancy is an ongoing architectural commitment that has to be designed in from the start, not bolted on after data loss.
Data can be loaded via direct command-line upload (gsutil/gcloud storage cp for small volumes), directly from an existing Cloud Storage location (for data already in Google Cloud), or via Storage Transfer Service for large-scale, scheduled, or recurring transfers — including from on-premises sources or other cloud providers — without needing to build custom transfer tooling. Maintaining multi-region redundancy means deliberately choosing multi-region or dual-region bucket configurations (for Cloud Storage) or regional/multi-region replication settings (for databases like Spanner) so a single region's outage doesn't mean data loss or unavailability.
⚠️ Exam Trap: A scenario describing a one-time, small file upload as part of a manual admin task doesn't need Storage Transfer Service — that tool is built for large-scale, recurring, or source-external transfers; reaching for it on a trivial one-off task is over-engineering the answer the exam is testing for.
Reflection Question: A company needs to migrate 500 TB of data from an on-premises data center to Cloud Storage on a recurring nightly schedule. Which feature is purpose-built for this, and why would a simple gsutil cp script be the wrong tool at this scale?
