Setting up a cloud solution environment
- Resource hierarchy: Organization → Folders → Projects → resources. IAM and org policy set at a node are inherited by everything below it.
- Billing accounts are separate from projects — one billing account can fund many projects, and budgets/alerts are set at the billing-account or project level.
- Cloud Shell and the gcloud CLI both give you an authenticated, pre-configured environment for managing resources without installing anything locally.
- Projects need a unique project ID (immutable) separate from the display name (changeable) — many gcloud commands require the project ID, not the name.
Planning and configuring a cloud solution
- Choosing compute: Compute Engine for full control, GKE for container orchestration, Cloud Run for stateless request-driven containers that scale to zero, App Engine for a fully managed app platform.
- Choosing storage: Cloud Storage (object, with storage classes Standard/Nearline/Coldline/Archive), Persistent Disk (attached to Compute Engine), Filestore (managed NFS).
- Choosing a database: Cloud SQL (managed MySQL/PostgreSQL, regional), Cloud Spanner (globally distributed, strongly consistent), Firestore (document NoSQL), Bigtable (wide-column, high-throughput), BigQuery (analytics warehouse).
- VPC networks: subnets are regional, firewall rules are defined at the VPC level and apply by tag or service account, and a VPC can span multiple regions within one project.
Deploying and implementing a cloud solution
- Managed instance groups (MIGs) provide autoscaling and self-healing for Compute Engine VMs based on a template, and support rolling updates.
- Deployment Manager and Terraform both support infrastructure as code on GCP; know that Deployment Manager is Google-native while Terraform is multi-cloud.
- GKE deployments: Deployments manage pod replicas and rolling updates, Services expose pods internally or externally, and Ingress manages external HTTP(S) routing.
- Cloud Build automates container image builds and can trigger from a source-repository push — the standard CI step before a Cloud Run or GKE deployment.
Ensuring successful operation of a cloud solution
- Cloud Monitoring: dashboards, uptime checks, and alerting policies based on metrics or logs. Cloud Logging: centralised logs with log-based metrics and sinks (to BigQuery, Cloud Storage, or Pub/Sub) for export.
- Managed instance group health checks trigger auto-healing (recreating unhealthy instances) separately from the load balancer's own health checks, which control traffic routing.
- Snapshots (Persistent Disk) and exports (Cloud SQL) are the standard backup mechanisms; snapshot schedules automate recurring backups.
- Cost visibility: budgets and alerts, the pricing calculator, and Recommender for identifying idle or oversized resources.
Configuring access and security
- IAM roles: basic (Owner/Editor/Viewer, broad and generally discouraged), predefined (scoped to a service, Google-maintained), custom (org-defined, for precise least-privilege needs).
- Service accounts represent workload identity, not a human user — attach the minimum role needed, and prefer workload identity federation over exported key files where possible.
- Cloud IAM policies can be set at any level of the resource hierarchy; the effective policy on a resource is the union of everything inherited plus what's set directly on it.
- Data protection basics: Google encrypts data at rest by default; Cloud KMS adds customer-managed encryption keys (CMEK) when an organization needs its own key control.
Test yourself on Associate Cloud Engineer
Reading a summary is the easy part. Take the free 10-question diagnostic to see which of these domains you actually have, then drill the rest.
Also free: 15 Associate Cloud Engineer sample questions with answers and the Associate Cloud Engineer study guide.