# Google Cloud infrastructure lab

Original LockedIn Labs exercise · reviewed 20 October 2026.
Companion: /training/vendors#gcp.

## Understand model requests before connecting AI

Use the [free model request workbook](/templates/cloud-model-request-workbook.md)
to separate the SDK, service endpoint, model and agent loop. Compare this
provider's normal text, output-limit and custom function responses. Then open
the [runnable response lab](/training/guides/cloud-responses): predict a decision,
run the standard-library Python adapter and change one synthetic response. No
cloud account or model key is needed; no function proposal is executed.

## What you will understand

A project owns service resources. A global VPC contains regional subnets.
A VM and its boot disk run in a zone. The VM's image, size, network and identity
are separate choices. You will create one private Linux VM, inspect it and remove
the dedicated lab resources. This is infrastructure practice, not an AI deployment
or a certification assessment.

## Read a private request before changing access

This no-account exercise comes before provisioning. A private IP is an address,
not a guarantee of reachability or permission. DNS finds an address; routes and
traffic rules let a connection reach a listener; TLS verifies the server and
protects the connection; the application authorizes the requested data.

Draw a document assistant at `10.24.1.10` calling a records service at
`10.24.2.15:443` inside a Google Cloud VPC. These are fictional addresses.
The name `records.example.test` is for illustration only. Do not send requests
to these addresses. A port identifies the service endpoint on a host; this
example uses TCP port 443 for HTTPS.

Label the name lookup **Cloud DNS private zone** and the traffic check
**effective VPC firewall rules and policies**. A DNS lookup does not carry the API request.
Account for forward and return routes, other applicable traffic controls and
the running server's listener. Application identity and data policy are separate.

For each case, write (1) what is observed, (2) what cannot yet be concluded,
and (3) the next observation or bounded action:

| Case | Supplied evidence | Your next step |
| --- | --- | --- |
| Only a timeout | DNS returns the intended address; a new TCP connection times out; no other path evidence | Explain why the firewall is not yet a proven cause. |
| A different address | DNS returns `10.24.2.99`; the deployment record expects `.15`; no connection attempted | Inspect the caller's DNS view before changing traffic or TLS settings. |
| A policy finding | An authorized investigation additionally establishes that this specific new connection is not allowed by the effective traffic policy | If the path is approved, scope a proposed change to the caller, destination and port, then retest. |
| The service says no | Connection and TLS succeed; the intended service's correlated log denies another customer's document; HTTP 403 | Preserve the denial and test an approved document with the same workload identity. |
| One approved read | The service identifies the caller, allows its document and returns the expected ID and revision; HTTP 200 | Record this success alongside the forbidden-read evidence. |

Review: a timeout alone does not distinguish routing, traffic policy, an
unavailable host or another connection failure. A private address may be the
wrong destination. Saving a rule does not prove a working request. A 403 alone
could originate at an intermediary; in this case the service's correlated log
identifies the denying layer. One permitted request does not establish readiness
for all callers, failures or loads. Never turn an unobserved layer into a pass.

The protected regions-and-networks lesson provides the visual version and
case-specific feedback. For a local runnable exercise with real sockets and
TLS, use the [free networking lab](https://training.lockedinlabs.ai/training/guides/networking).
This teaching case is separate from the isolated VM below: that VM deliberately
has no exposed application or inbound access. Do not open it merely to reproduce
the diagram.

## Before creating anything

Use a dedicated authorized training project with billing, Compute Engine API,
appropriate permissions and quota. Install the current Google Cloud CLI and
authenticate using your organization's normal flow. Agree a spending ceiling and
cleanup time; a budget notification is not a hard spending cap. Check current
compute and disk prices. The example region is illustrative, not a residency
recommendation. Use synthetic data only.

Read each block before running it. Stop on errors; inspect any resources already
created before retrying. Keep this shell's variables and record resource IDs.
Do not run cleanup against a shared or production environment.

```bash
LAB_PROJECT="replace-with-approved-project-id"
LAB_REGION="us-central1"
LAB_ZONE="us-central1-a"
LAB_NAME="fde-lab-$(date +%Y%m%d%H%M%S)"
gcloud projects describe "$LAB_PROJECT" --format='table(projectId,name,projectNumber)'
gcloud services list --enabled --project="$LAB_PROJECT"
gcloud compute machine-types describe e2-micro --zone="$LAB_ZONE" --project="$LAB_PROJECT"
```

Match the observed project ID with your approved project. Verify the zone belongs
to the chosen region and that the machine type is available to your project.
If quota or policy blocks it, ask the environment owner for the correct lab
configuration; do not widen permissions or change location blindly.

## Create the isolated network

These commands create billable-resource dependencies in your project. No public
address, SSH access or internet gateway configuration is added.

```bash
gcloud compute networks create "$LAB_NAME" \
  --subnet-mode=custom --project="$LAB_PROJECT"
gcloud compute networks subnets create "$LAB_NAME-subnet" \
  --network="$LAB_NAME" --region="$LAB_REGION" \
  --range=10.24.0.0/24 --project="$LAB_PROJECT"
```

Explain: the network is global, the subnet is regional, and the private address
range has 24 network bits. There is no tutorial-created inbound firewall allow.
Inherited organization policies may further restrict the environment.

## Create one server

```bash
gcloud compute instances create "$LAB_NAME" \
  --project="$LAB_PROJECT" --zone="$LAB_ZONE" --machine-type=e2-micro \
  --subnet="$LAB_NAME-subnet" --no-address \
  --image-family=debian-12 --image-project=debian-cloud \
  --boot-disk-size=10GB --boot-disk-type=pd-standard --boot-disk-auto-delete \
  --no-service-account --no-scopes --labels=purpose=fde-training
```

The image family resolves to an image at creation time. Record the actual image.
The VM has no attached service account and no public IP. This deliberately does
not install packages or test external connectivity. A private VM would need an
explicitly designed management and egress path for those tasks.

## Inspect instead of guessing

```bash
gcloud compute instances describe "$LAB_NAME" \
  --project="$LAB_PROJECT" --zone="$LAB_ZONE" \
  --format='yaml(name,status,machineType,networkInterfaces,serviceAccounts,disks)'
gcloud compute disks describe "$LAB_NAME" \
  --project="$LAB_PROJECT" --zone="$LAB_ZONE" \
  --format='yaml(name,sizeGb,type,sourceImage,users)'
```

Expected observations, to be verified rather than pasted as your result:

- The machine type ends with `e2-micro`.
- The interface has an internal address and no external `natIP`.
- No service account is attached.
- The boot disk is owned by this instance and auto-delete is enabled.
- `RUNNING` is VM state, not an application health result.

Draw the path from project to VPC, subnet, zone, VM and disk. Then explain why a
second VM in the same zone does not establish zone-failure recovery.

## Cleanup and verify

First compare each name and project with your recorded lab inventory.

```bash
gcloud compute instances delete "$LAB_NAME" \
  --project="$LAB_PROJECT" --zone="$LAB_ZONE"
gcloud compute disks list --project="$LAB_PROJECT" --filter="name=$LAB_NAME"
gcloud compute networks subnets delete "$LAB_NAME-subnet" \
  --project="$LAB_PROJECT" --region="$LAB_REGION"
gcloud compute networks delete "$LAB_NAME" --project="$LAB_PROJECT"
gcloud compute instances list --project="$LAB_PROJECT" --filter="name=$LAB_NAME"
gcloud compute networks list --project="$LAB_PROJECT" --filter="name=$LAB_NAME"
```

Confirm the VM, its auto-deleted boot disk and the lab network are absent.
If the disk remains, inspect its ownership before deleting it; do not assume
every unattached disk belongs to this exercise. Retain the final inventory.
Check billing later for residual usage; invoice reporting can lag.

## Connect the server to an AI architecture

Do this design exercise without provisioning more services:

1. Draw a service identity, permitted document source and managed model endpoint.
2. Record model/API, processing location, output allowance and timeout.
3. Describe a supported question, unauthorized source and unavailable endpoint.
4. Explain why a managed model may remove the need for a GPU on this VM.
5. Choose an official provider lab for live model invocation and keep its
   observed results separate from this proposed design.

## Follow the cost after an alert — no cloud account required

A budget is a plan for a scope and time period. A notification tells someone
that a threshold was reached or forecast. Enforcement is a separate control
that refuses work or changes a resource. A quota can limit requests or resources
without limiting the currency cost of the whole application.

Draw three cost streams for the fictional Field Desk: model usage, running
compute and retained data. Use these **invented teaching rates, not vendor
prices**: $14/hour for model usage, $4/hour for compute and $2/hour for retained
resources. Start with $80 already accrued and a $100 notification threshold.

1. At the end of hour 1, the total reaches $100. Assume notification and response
   occur two hours later, at the end of hour 3. This is a teaching delay, not a
   claim about the provider's reporting schedule.
2. Predict the total at the end of hour 6 for each response: notify only; stop
   new model work; stop new model work and release compute. Keep the data in
   every case. A response affects subsequent hours, not costs already accrued.
3. Draw each accumulated-cost line. Label the threshold, response time and each
   cost stream that remains. Explain why none of the lines stops at $100.
4. Repeat with an immediate response at the end of hour 1. What changes? What
   still costs money?
5. Write the scope, owner, action, required permission, remaining billable
   resources and safe restart rule for a real training environment. Keep this
   proposed design separate from an observed cloud result.

Review after making your prediction:

| Response | Hour 6 total: two-hour delay | Hour 6 total: immediate response |
| --- | ---: | ---: |
| Notify only | $200 | $200 |
| Stop new model work | $158 | $130 |
| Stop new model work and release compute | $146 | $110 |

For example, with the delayed compute response: $80 + (3 × $20) + (3 × $2)
= $146. Storage remains. This simplified exercise excludes in-flight requests,
commitments, taxes and other services; a real inventory must account for them.
Model token limits and bounded retries help control request costs, but do not
cap the entire cloud bill. Do not run a shutdown or delete data just to reproduce
this paper exercise.

Google Cloud distinguishes alerts-only budgets from spend cap budgets for
eligible services. A spend cap covers one project and one eligible service;
enforcement is not instant, and persistent-resource charges can remain. Verify
current service eligibility and reset behavior. An alerts-only notification
still does not stop the application.

- [Google Cloud budgets](https://docs.cloud.google.com/billing/docs/how-to/budgets)
- [Spend cap scope and limitations](https://docs.cloud.google.com/billing/docs/how-to/budgets-spend-caps)

Provider references checked 21 October 2026.

## Evidence and certification preparation

Keep the environment passport, actual server properties, network diagram,
permission matrix, cleanup inventory and one recovery scenario. Do not include
keys or tokens. Mark unrun work as proposed.

This covers selected infrastructure foundations. Continue with official labs for
GKE, databases, load balancing, broader administration and the ML lifecycle:

- [Cloud Engineer learning path](https://www.skills.google/paths/11)
- [Associate Cloud Engineer exam guide](https://cloud.google.com/learn/certification/guides/cloud-engineer)
- [Machine Learning Engineer learning path](https://www.skills.google/paths/17)
- [Compute Engine create reference](https://docs.cloud.google.com/sdk/gcloud/reference/compute/instances/create)

Cloud provisioning has not been executed by the Training site on your behalf.
Your sandbox run establishes the live evidence.