GCP DEVOPS · STUDY WORKSPACE

Hands-on workbook

The exercises support the 24-week plan. Start with local labs. No Google Cloud resources were created while preparing this pack. Cloud exercises can incur charges; use an authorized training sandbox/credits when available, or a dedicated small lab project whose spending you can monitor. Never use an employer's production environment for these experiments. Confirm scope before running a command that creates, changes or deletes resources.

Use Google's certification learning-path link for guided cloud labs when you need a managed lab account. Free access and credits vary. Local work teaches much of the behavior, but it does not replace actual GCP IAM, build and observability experience.

For every exercise save: purpose, diagram, configuration, observed output, one failure and its diagnosis, cleanup evidence and a five-sentence teach-back. Success means reproducing the result and explaining it, not merely finishing instructions.

Lab 1 — HTTP, processes and logs (local; 60–90 minutes)

Prerequisite: Python 3 and a terminal. From the workspace root:

python3 labs/service/app.py

In a second terminal:

curl -i http://127.0.0.1:8080/healthz
curl -i 'http://127.0.0.1:8080/work?delay_ms=250'
curl -i 'http://127.0.0.1:8080/work?fail=1'
curl -i http://127.0.0.1:8080/missing

Expected: health succeeds; delayed work succeeds with observable latency; deliberate failure returns 500; the missing route returns 404. Inspect JSON logs and distinguish the HTTP status from log severity. Stop the service with Ctrl+C. Run with PORT=8081 python3 labs/service/app.py and explain why port 8080 no longer works.

Pass criterion: explain the process, listening address, port, endpoint, status, JSON payload and log. Cleanup: stop the process. This intentionally fault-injectable teaching service is not production hardened.

Lab 2 — Image, container and Git (local; 90–120 minutes)

Prerequisites: Docker and Git installed through their supported installation instructions. Work in a separate copy if you want to initialize a Git repository. Make a branch, change APP_VERSION or a response, review a diff and commit it.

docker build -t devops-lab:v1 labs/service
docker run --rm --name devops-lab -p 127.0.0.1:8080:8080 devops-lab:v1

Repeat lab 1's requests. In another terminal inspect docker logs devops-lab and docker image inspect devops-lab:v1. Stop with docker stop devops-lab. Change behavior and build a second image; compare IDs. Explain why a local image ID and a registry manifest digest are related identifiers but not always the same string.

Pass criterion: you can rebuild and run the service and explain tag mutability and port mapping. Cleanup: stop the lab container and remove only the two images you created when no longer needed. For production reproducibility, select/review supported base versions and pin suitable digests rather than treating this introductory tag as a permanent hardened base.

Lab 3 — GCP project, identity and cost boundary (cloud/sandbox; 2–3 hours)

Prerequisites: an authorized account/project and understanding of its billing. Record the project ID, region, enabled APIs and expected costs. Verify the active CLI account/project with gcloud auth list and gcloud config get-value project before any mutations. Use a separate CLI configuration for labs if needed.

Create a dedicated workload service account and a small private bucket. Grant the identity only the required object access on that bucket, through a permitted short-lived identity path. Demonstrate one allowed read and one denied operation outside its scope. If you cannot create an organization/folder in a personal account, draw that hierarchy and use a training sandbox for organization-level exercises.

Create a small scoped budget/alert if the environment permits it. Read the distinction between alerts-only and spend-cap budgets; do not treat alerts as a perfect cost ceiling. Inventory resources after the session. IAM, impersonation, budget notifications.

Pass criterion: show the actual caller, binding/resource scope and error for the denied action. Cleanup: remove lab-only bindings/service account and bucket data/resources according to the sandbox rules. Do not delete shared projects or identities.

Lab 4 — Network and security design (design plus sandbox; 2–3 hours)

Draw three solutions: shared subnets with central ownership; private connectivity between independent non-overlapping VPCs; one published private service consumed by another VPC. Explain why Shared VPC, peering and PSC are different.

In a training sandbox, implement one allowed topology. Record routes, DNS, firewall and caller identity. Break one firewall rule or DNS configuration within the sandbox, reproduce the failure, inspect evidence and restore it. Add an external CI identity to the diagram and show federation trust and IAM separately. Explain where API perimeter protection ends and internet egress control begins.

Pass criterion: diagnose reachability separately from permission denied. Explain why A↔B↔C peering does not automatically give A↔C transit. Cleanup: restore shared settings and delete only your disposable network resources. Shared VPC, peering, PSC.

Lab 5 — Kubernetes probes and scheduling (local first; 3–4 hours)

Use a local Kubernetes environment such as an existing kind/minikube cluster, or an authorized GKE lab. Load devops-lab:v1 into the local cluster using that tool's image-loading command. For GKE, replace the image with a registry path the nodes can pull. Apply only to a disposable namespace:

kubectl create namespace devops-practice
kubectl -n devops-practice apply -f labs/service/kubernetes.yaml
kubectl -n devops-practice rollout status deployment/devops-lab
kubectl -n devops-practice get pods
kubectl -n devops-practice port-forward service/devops-lab 8080:80

In a copy of the manifest, set readiness path to /missing, apply it and inspect kubectl describe pod plus logs. Observe that Running is not necessarily Ready. Restore the correct path. Next use an unavailable image tag and inspect ImagePullBackOff. Restore it. In a separate experiment set a request above available node capacity and inspect Pending events; restore promptly.

Pass criterion: distinguish image pull, scheduling, readiness and process failures from evidence. Cleanup: delete the disposable namespace after reviewing its contents. Delete a cloud cluster only if you created it exclusively for this lab; confirm no workloads/disks/load balancers remain chargeable. Pod debugging.

Lab 6 — Terraform plan, state and recovery (cloud/sandbox; 2–3 hours)

The included labs/terraform/main.tf creates one private, versioned bucket. The provider major version is deliberately constrained for reproducibility; consult compatibility before adopting a different version. Use authorized Application Default Credentials or a supported short-lived impersonation/federation path. Do not download a key merely for this lab.

cd labs/terraform
terraform init
terraform fmt -check
terraform validate
terraform plan -var='project_id=YOUR_LAB_PROJECT' -var='bucket_name=YOUR_GLOBALLY_UNIQUE_LAB_BUCKET'

Replace placeholders; inspect the plan before applying. Create only when you understand the cost/scope. Change a harmless label and compare the next plan. Show why local state should not be shared by emailing it. Extend the exercise with a separate, protected GCS backend following the official guide; enable backend-bucket versioning separately and demonstrate lock handling without force-unlocking an active writer.

Pass criterion: explain state versus configuration, plan versus apply, and locking versus versioning. Cleanup: empty only the disposable bucket, including versions if created, review terraform plan -destroy, then destroy only those lab resources. The configuration deliberately uses force_destroy=false to avoid silently deleting stored data. GCS backend, plan.

Lab 7 — Cloud Build and an immutable artifact (cloud/sandbox; 3–4 hours)

Create one Artifact Registry Docker repository. Choose a dedicated build identity and grant only required push/logging access. Inspect the sample labs/service/cloudbuild.yaml; its compilation check is introductory. Add behavior tests for health, failure and invalid input before calling this a meaningful pipeline.

From labs/service, use the documented Cloud Build submission flow with the intended project, execution identity and _REGION/_REPOSITORY substitutions. Capture build ID and registry digest. Introduce a failing test and show that the build does not proceed successfully. If using a source trigger, configure a required repository status check rather than assuming the trigger blocks merges.

Pass criterion: show commit/build/digest evidence and identify the exact execution principal. Cleanup: remove lab triggers, images/repository and other resources you created when they are no longer needed; retain only the small evidence file. Build schema, triggers.

Lab 8 — Delivery and rollback (cloud/sandbox; 3–4 hours)

Deploy the lab image to an authorized small Cloud Run service or GKE target. Keep authentication restricted. Record a known-good digest/configuration. Use the Cloud Deploy quickstart for the chosen supported runtime to create a small delivery pipeline; then add verification that actually invokes a useful endpoint. Evaluate the cost of extra environments before creating them.

Release v2 with an intentionally wrong setting in the disposable service. Observe verification failure, stop promotion and restore the compatible known-good release or route. Record what was automatic and what required your action. Explain how a database migration would change the rollback decision.

Pass criterion: prove the served version and successful user operation after recovery, not just a green rollout. Cleanup: remove disposable service/pipeline/targets and associated artifacts when done. Cloud Deploy, verification, rollback.

Lab 9 — Secrets and supply-chain reasoning (cloud/sandbox; 2–3 hours)

Create a dummy secret, never a real password. Grant its accessor permission to only the chosen consumer identity at the secret's scope. Demonstrate allowed access without printing the value into build logs. Revoke it and observe the expected denial; restore only if necessary for the next step. Rotate the dummy version and explain how running consumers learn about it.

Inspect build provenance for your artifact. Identify the subject digest and builder/source evidence. Draw a Binary Authorization flow: tests/scan → trusted decision → attestation for digest → enforced deployment policy. Use a supported sandbox to test denial of an unattested image if available. Do not claim an implemented enforcement test if you only drew the design.

Pass criterion: distinguish retrieval, disclosure prevention, provenance and enforcement. Cleanup: remove dummy secrets/versions and bindings under the environment's rules. Secrets, provenance, Binary Authorization.

Lab 10 — Observability and controlled diagnosis (cloud/sandbox; 4–6 hours)

Use the deployed teaching service. Generate a small bounded batch of successful, delayed and failed requests. Query structured logs by service, status and time. Create a useful metric or use available native request/latency metrics. Build a dashboard showing traffic/errors/latency and an alert with a notification channel you control. Trigger the condition in the lab and verify receipt, then recover.

Add a simple synthetic/uptime check appropriate to the endpoint's authentication and network configuration. Do not expose a service broadly merely to simplify a check. Trace exercise: instrument a two-service sample using the supported OpenTelemetry language guide, propagate context and compare a delayed downstream call with local delay. The included HTTP app does not already contain a tracing SDK; adding instrumentation is part of this exercise.

Pass criterion: explain a metric type, cardinality choice, alert duration, log/trace correlation and head/tail sampling. Capture a waterfall. For a VM exercise, install/configure Ops Agent in a disposable sandbox and verify guest-memory/file-log collection. Cleanup: remove lab alerts/checks/agents/services and review log retention and remaining charges. Ops Agent, context, synthetic monitors.

Lab 11 — SLO calculations and policy (local; 2 hours)

Define a request-based availability SLI for the service, including eligible events. Calculate these without the answer key:

  1. 4,000,000 requests, 99.9% target: allowed bad requests?
  2. Same window, 2,800 bad requests: budget fraction used and remaining?
  3. 99.95% target, observed error ratio 0.2%: burn rate?
  4. Time-based 99.95% over exactly 30 days: downtime minutes?
  5. Stable traffic and burn rate 6 for six hours in a 30-day window: approximate fraction consumed?

Answers: 4,000; 70% used/30% remaining; 4×; 21.6 minutes; 5%. Show units and assumptions. Then write a policy for feature releases when budget is exhausted, with explicit security/reliability exceptions and an owner.

Pass criterion: explain why a request budget is not automatically downtime minutes and why (long AND short) OR (long AND short) differs from ANDing unrelated burn branches. SLOs, alerts.

Lab 12 — Incident, cost review and capstone (local plus cloud; 4–6 hours)

Choose one reversible failure in the disposable service: bad image, bad readiness path or revoked lab-only permission. State expected impact, blast radius and restoration steps before changing it. Start a timeline, detect/diagnose the failure, mitigate and verify recovery. Write a blameless postmortem with one corrective action you can test.

Review the lab inventory and billing if available. Identify idle resources, artifact/log retention and unnecessary warm capacity. Estimate a stable baseline versus bursts using your measured workload; do not purchase any commitment for this exercise. Explain quota/reservation/commitment, Spot suitability and network placement.

Finish the capstone in the plan: a reviewed source change, useful tests, immutable artifact, controlled deployment, telemetry/notification, failed change/recovery and cost cleanup. Keep the evidence, remove disposable billable resources and verify what remains. Incident management, billing export.