Module 2 — Managed notebooks and development environments

Every experiment in the rest of the course starts in a notebook: the exploratory query on BigQuery, the first training run, the sanity check on a predicted score. The notebook stays the driver even when jobs move to background runners in module 4. Vertex AI offers two managed options — Workbench and Colab Enterprise — and choosing the wrong one silently doubles the bill.

Why a "managed" notebook, and not just a laptop

A Jupyter server on a laptop works until three problems show up: the data is too big to download, the credentials the notebook needs live in the cloud, and the accelerator you occasionally want costs more than the whole laptop. A managed notebook fixes all three: it runs in the same project and region as the data, it inherits IAM from an attached service account, and it lets you pick a machine type — including GPUs — that you release when you close the tab.

The fraud-detection red thread benefits from this immediately. The transactions table is 40 GB in BigQuery; a Workbench instance in the same region queries it in seconds without leaving the cloud, and a laptop would spend an hour downloading a slice it barely fits in memory.

Workbench: a persistent VM you can shut down

A Workbench instance is a managed JupyterLab server on a Compute Engine VM. You choose:

Choice	For the fraud-detection work
Machine type	n1-standard-4 (4 vCPU, 15 GB) for exploration; n1-highmem-8 when a slice of BigQuery is loaded into pandas
Accelerator	None during exploration; NVIDIA_TESLA_T4 for a first deep-learning run
Boot disk	100 GB standard; 500 GB when caching intermediate parquets
Service account	notebook-runner@fraud-detection-dev.iam.gserviceaccount.com (never the default)
Idle shutdown	30 minutes without kernel activity

gcloud workbench instances create fraud-explore \
    --location=europe-west1-b \
    --machine-type=n1-standard-4 \
    --service-account-email=notebook-runner@fraud-detection-dev.iam.gserviceaccount.com \
    --metadata=idle-timeout-seconds=1800

The idle-timeout-seconds is the single most cost-saving setting in the whole course. A n1-standard-4 left running over a long weekend costs about $10; the same instance with 30-minute idle shutdown costs pennies. Every organisation that has run Vertex for a year has a "someone forgot the notebook on" story, and the fix is one flag.

Shutdown means stopped, not deleted

Idle shutdown stops the VM. Storage is still charged ($0.04 per GB per month), the notebook contents survive, and a click restarts it in a minute. Deleting the instance is a separate action, and only that one wipes the disk. Confusing the two costs either data or money.

Kernels and environments: the shape of "it works on my instance"

A Workbench instance ships with a small set of pre-installed kernels — Python 3 with CPU or GPU frameworks, R. For the red thread we install what we need in a dedicated conda environment so the training container of module 4 can be built from the same requirements.

conda create -n fraud python=3.11 -y
conda activate fraud
pip install \
    google-cloud-aiplatform==1.60.0 \
    google-cloud-bigquery==3.25.0 \
    pandas==2.2.2 scikit-learn==1.5.1 xgboost==2.1.0 \
    matplotlib==3.9.0
python -m ipykernel install --user --name fraud --display-name "Python (fraud)"

Pin versions. A notebook whose pip install line reads pandas (no version) is a notebook whose behaviour changes with the wind. The container of module 4 will read the exact same requirements file and either agree or fail loudly at build time — which is what you want.

Direct BigQuery access from the notebook

Because the notebook runs in the same project as the data, credentials are ambient — no keys to manage, no service-account JSON to download. The BigQuery client picks up the attached service account.

from google.cloud import bigquery

client = bigquery.Client(location="europe-west1")

df = client.query("""
    SELECT amount, merchant_category, hour_of_day, is_fraud
    FROM `fraud-detection-dev.raw.transactions`
    WHERE _PARTITIONDATE BETWEEN '2026-06-01' AND '2026-06-07'
    LIMIT 100000
""").to_dataframe()

The _PARTITIONDATE filter is not stylistic: without it, the query scans the full table (40 GB in the red thread), which the next module quantifies in dollars. A notebook that runs unpartitioned queries all afternoon writes a bill on its own.

For interactive plotting on tabular data, the %%bigquery magic returns a DataFrame with one line:

%%bigquery df --location=europe-west1
SELECT DATE(created_at) AS day, COUNT(*) AS n_tx, SUM(CAST(is_fraud AS INT64)) AS n_fraud
FROM `fraud-detection-dev.raw.transactions`
WHERE _PARTITIONDATE BETWEEN '2026-06-01' AND '2026-06-30'
GROUP BY day
ORDER BY day

Colab Enterprise: the same code, a different runtime

Colab Enterprise is the same Google Colab UI you may know, wired to your GCP project and your VPC. Notebooks live as a resource in the project — versioned, shareable across the team, permissioned by IAM — instead of in one person's Drive.

Choose Colab Enterprise when the work is collaborative and short-lived (a review, a shared exploration on a fresh dataset, a demo for a stakeholder). Choose Workbench when the work is long-running, needs a specific machine, or is going to build the container that module 4 pushes to production. The two are complementary; the platform charges only for what runs.

	Workbench	Colab Enterprise
Persistence	Yes (disk survives shutdown)	Runtime is ephemeral, notebook is stored
Machine choice	Full Compute Engine catalogue	Predefined runtime templates
Best for	Model development, training containers	Team review, exploration, demos
Idle shutdown	Configurable	Enforced by the platform

The one-page setup for the red thread

# Cell 1 - platform and defaults
from google.cloud import aiplatform, bigquery

PROJECT   = "fraud-detection-dev"
LOCATION  = "europe-west1"
BUCKET    = "gs://fraud-detection-dev-vertex-eu"

aiplatform.init(project=PROJECT, location=LOCATION, staging_bucket=BUCKET)
bq = bigquery.Client(location=LOCATION)

# Cell 2 - a small stratified slice for local iteration
QUERY = """
    SELECT
      amount, merchant_category, hour_of_day, days_since_signup,
      is_fraud
    FROM `fraud-detection-dev.raw.transactions`
    WHERE _PARTITIONDATE BETWEEN '2026-06-01' AND '2026-06-30'
      AND MOD(FARM_FINGERPRINT(CAST(transaction_id AS STRING)), 100) = 0
"""
df = bq.query(QUERY).to_dataframe()
print(df.shape, df["is_fraud"].mean())

The FARM_FINGERPRINT trick gives a stable 1% sample by transaction ID — same 1% each time you run the query, cross-consistent with any other slice keyed the same way. That determinism is what turns a notebook run into a reproducible experiment.

Two rules that pay for themselves

Pin every dependency in a requirements.txt you can copy into the training container of module 4. Set idle shutdown to 30 minutes on every instance. Those two habits together save more money than any accelerator choice you will make later.

In summary

• A managed notebook puts compute next to the data and inherits credentials from a service account; on 40 GB of BigQuery data, that alone changes the workflow.
• Workbench is a persistent Compute Engine VM you shut down; Colab Enterprise is an ephemeral runtime for collaboration. Both are Vertex AI resources.
• Always configure idle shutdown (30 minutes is a sensible default) and attach a least-privileged service account; the default identity is Editor on the project.
• Query BigQuery from the notebook with _PARTITIONDATE filters and a deterministic sampling trick — the same slice on every run is what makes an experiment reproducible.

Next module: the data itself — how BigQuery and Cloud Storage carry the fraud-detection dataset into a Vertex managed dataset or a DataFrame, and what each query costs.