Deploying and Implementing a Cloud Solution
Deployment mechanisms
Deploy with the Console, gcloud, infrastructure-as-code (Terraform or Deployment Manager), Cloud Build pipelines, or Marketplace for third-party solutions. Cloud Build runs containerized steps from cloudbuild.yaml: build, test, push to Artifact Registry, deploy. In exams the mechanism rarely matters - the resource configuration does.
Compute deployments
GKE: choose zonal versus regional (regional gives control-plane HA), then apply manifests. Cloud Run: deploy an image, set concurrency and scaling limits, and decide whether to allow unauthenticated invocations or require IAM. App Engine: app.yaml defines runtime and scaling. Cloud Functions: runtime, entry point, trigger, memory, timeout. Compute Engine fleets: instance template plus MIG for repeatability, startup scripts for bootstrapping.
Storage and data deployment
Bucket names are globally unique, and the name and location are immutable after creation - you must create a new bucket and copy to change either. Set storage class, versioning, lifecycle rules, retention policy, and uniform bucket-level access at creation. Enabling uniform bucket-level access disables object ACLs. For Cloud SQL, choose tier, region, HA, backups, and private IP via VPC peering.
Traps worth memorizing
- A deploy failing with 403 is usually a missing API enablement or IAM grant, not bad code.
- Lifecycle rules act on object age, class, or version count; they do not move data between buckets.
- IaC questions test the concept (reproducible, version-controlled environments), not syntax.
Rule of thumb: every manual step you perform should be encoded in a template or pipeline so the same environment can be rebuilt identically.