Task 2.2: Model prototyping using notebooks (e.g., Gemini Enterprise Agent Platform Workbench and Colab Enterprise).

• AInstall extra packages with pip install --user and keep working files under /home/jupyter

  Correct

  The --user flag installs packages in /home/jupyter on the data disk, which an upgrade preserves together with the local files there.

• BTurn off automatic upgrades and run the same upgrade by hand each month instead

  Incorrect

  A manual upgrade also replaces the boot disk, so the packages and the other folder would still be lost.

• CStop the instances during the upgrade window so that the upgrade waits for the next start

  Incorrect

  A stopped instance is not upgraded automatically at all, so the fixes are missed rather than applied safely.

• DInstall the extra packages into a new conda environment instead of the default one

  Incorrect

  Pip and conda libraries are stored on the boot disk by default, and the upgrade replaces that disk.

Upgradable Workbench instances have a boot disk and a data disk. An upgrade moves the boot disk to a new image and keeps the data disk: notebooks and files in /home/jupyter are preserved, while files in other /home/ directories and user-installed operating system packages are not. Pip and conda libraries live on the boot disk by default; installing pip libraries with the --user flag puts them in /home/jupyter/, where they survive. Automatic upgrades run only on instances that are running.

• ACreate the instance without a public IP address

  Correct

  A public IP allows egress to the internet, which bypasses the service perimeter; instances in a perimeter should not have one.

• BTurn on idle shutdown for the instance

  Incorrect

  Idle shutdown stops an unused instance to save cost; it does not control network egress.

• CEncrypt the boot and data disks with a customer-managed key

  Incorrect

  CMEK controls the key for data at rest, not where the instance can send data.

• DChange the JupyterLab access mode to single user

  Incorrect

  The access mode decides who can open JupyterLab, not which network paths the VM has.

To use a Workbench instance within a service perimeter, the instance must not have a public IP address, because a public IP allows egress to the internet that bypasses the perimeter. Google APIs are reached through restricted.googleapis.com and the matching DNS and routes.

• AChange the instance's JupyterLab access mode to a single other user

  Incorrect

  The access mode is set when the instance is created and cannot be changed afterwards.

• BRotate the keys of the service account that the instance runs as

  Incorrect

  The open browser session does not depend on service account keys, so rotating them leaves it working.

• CStop or reset the instance

  Correct

  A revoked user can keep using an existing JupyterLab session for up to five days; stopping or resetting the instance ends it.

• DRemove the contractor from the project's Google group and wait for it to apply

  Incorrect

  The IAM change is already made; the cached session, not the group membership, is what still works.

Access to a Workbench instance's JupyterLab is governed by IAM and the access mode chosen at creation, which cannot be changed later. After revoking a user's permissions, an existing browser session can keep working for up to five days; to prevent access immediately, stop or reset the instance.

• AA cron job inside the Workbench instance's operating system

  Incorrect

  A cron job depends on the instance staying up and is not managed by Workbench.

• BAn Agent Platform pipeline wrapping the notebook's code

  Incorrect

  A pipeline works, but building one is exactly what the team wants to avoid for a single notebook.

• CA scheduled notebook run with the Workbench executor

  Correct

  The executor runs a notebook file on a schedule and stores the results without an interactive session.

• DIdle shutdown set to wake the instance at 1 a.m.

  Incorrect

  Idle shutdown only stops an inactive instance; it does not start or run anything.

The Agent Platform Workbench executor runs notebook files on demand or on a schedule, such as hourly or nightly, without an open JupyterLab session. Colab Enterprise offers scheduled notebook runs as well.

• ABuild a custom container from a Google-provided base container and create the instances from it

  Correct

  Workbench supports custom containers derived from the base containers, so every instance starts from the same image.

• BShare a requirements.txt file in the repository and ask each person to install it in their instance

  Incorrect

  A shared file still relies on manual installs, which is how the environments drift.

• CGive everyone one shared instance in service account access mode

  Incorrect

  One shared VM avoids drift but forces everyone onto the same machine and sessions.

• DTurn on automatic upgrades for all the instances

  Incorrect

  Upgrades move the base image forward; they do not install the team's own packages.

Agent Platform Workbench instances can be created from a custom container derived from one of the Google-provided base containers. Packages and extensions baked into the image are the same on every instance created from it.

• AA larger Workbench machine type that runs Spark in local mode on the notebook VM

  Incorrect

  Local mode is limited to one VM, so the large dataset still has to fit on it.

• BA Colab Enterprise notebook with pandas instead of Spark

  Incorrect

  pandas runs in memory on the runtime and rewrites the team's Spark code.

• CA Dataflow pipeline launched from the notebook

  Incorrect

  Dataflow runs Apache Beam, not the data scientist's PySpark code.

• DA Workbench instance with the Managed Service for Apache Spark JupyterLab extension

  Correct

  The preinstalled extension lets notebooks use Managed Service for Apache Spark, serverless or on clusters, as their kernel.

Agent Platform Workbench instances have the Managed Service for Apache Spark JupyterLab extension preinstalled (version M113 and later), which lets notebooks run Spark workloads on Managed Service for Apache Spark, serverless or on Compute Engine clusters.

• AWrite the loading and tuning code from scratch in a Workbench notebook

  Incorrect

  This works but is the slow start the team wants to avoid.

• BOpen the notebook linked from the model's card in Model Garden

  Correct

  Model cards for most open and fine-tunable models offer an Open notebook option with working code for tuning the model.

• CDeploy the Model Garden model to an endpoint and test it with curl requests

  Incorrect

  Deployment comes after prototyping and gives no code for tuning.

• DCall the model through the Translation API's model selector

  Incorrect

  The Translation API serves translation models, not Model Garden's open models.

In Model Garden, the model cards of most open source foundation models and fine-tunable models support tuning in a notebook: Open notebook on the model card gives a working starting point for prototypes, and model cards also offer code samples.