Cloud / Vertex AI Model Garden Interview questions

Vertex AI Model Garden is Google Cloud's model catalog. It gives you one place to discover, test, customize and deploy models from Google, from partners and from the open-source community. Google describes it as a curated set of 200+ models.

Every model is reached through the same surfaces: the Cloud console, the Vertex AI SDK and the gcloud CLI. Some models are serverless APIs you can call straight away, while others are deployed onto an endpoint that you control.

It also connects to the rest of the platform, so a model you pick can move on to tuning, evaluation and serving without leaving Google Cloud.

Naming note: since April 2026 Google brands the platform as Gemini Enterprise Agent Platform (formerly Vertex AI). Model Garden is still part of it, and many docs, SDK packages and commands still say Vertex AI.

Gemini Enterprise Agent Platform is the name Google Cloud announced on April 22, 2026 (at Cloud Next '26) for the evolution of Vertex AI. Vertex AI services and roadmap items are now delivered through it.

It keeps what Vertex AI users already had, namely model selection through Model Garden, model building and tuning, and adds agent-focused pieces such as agent building, integration, orchestration, security and governance.

In an interview, a safe phrasing is "Model Garden on Vertex AI, which is now part of Gemini Enterprise Agent Platform". API and SDK identifiers can lag behind the branding, so confirm exact names in the current docs.

Model Garden groups its catalog into three practical categories: first-party models from Google, partner (third-party) models, and open models. Within those, individual cards are labelled as foundation, tunable or task-specific models.

The category matters because it decides who runs the infrastructure, how you are billed and which controls you get.

First-party models are models built and served by Google itself. They include the Gemini family for text and multimodal work, plus task-focused models for image generation, video generation, music and speech.

You call them as a managed Google API. There is no endpoint to create and no GPU to size, and Google handles scaling and updates. You can try them in Vertex AI Studio first, then call the same model from the SDK.

Google also lists Gemini on Model Garden alongside pre-trained APIs, which are narrower services built for one job, such as speech or vision, and exposed through simple API calls.

Open models are models whose pretrained weights are published, so you can run, tune and deploy them yourself. Gemma and Llama are well-known examples in Model Garden, and Hugging Face models can be deployed too.

Most are open weight rather than fully open source. You get the parameters, but not necessarily the training code or data.

On Vertex AI you can consume them in two ways: a small curated set as serverless managed APIs, or any deployable model as a self-deployed endpoint inside your own project and VPC network.

Partner models are models built by Google's partners and offered through Model Garden, for example Anthropic's Claude and Mistral. Most are delivered as a managed API, so you keep sending requests to Vertex AI endpoints rather than to the partner's own servers.

Before first use you typically enable the model from its card, which creates a Marketplace-style entitlement and may require accepting the partner's terms.

A few partner models can instead be self-deployed on your own hardware. Weights of those self-deployed partner models cannot be exported.

MaaS means the model is offered as a fully managed, serverless API. Google handles provisioning, scaling and patching, and you pay for what you use, usually per token, instead of paying for idle machines.

Both partner models (such as Claude and Mistral) and a curated list of open models (such as Llama) are available this way. You still call a Vertex AI endpoint and use IAM for access.

Some MaaS models can reserve capacity with Provisioned Throughput for a fixed fee when you need steadier availability.

Self-deployed models are models you deploy to a Vertex AI endpoint in your own project. You pick the region, machine type and accelerator, and the model runs inside your project and VPC network.

This covers open models, custom or fine-tuned weights and some partner models. Model Garden gives a deployment pattern that wraps the serving container, the Model Registry entry and the endpoint.

The trade-off is control against effort. You gain network isolation, tunable serving settings and weight ownership for open models, but you pay for the nodes while they run and must watch quota and scaling.

A model card is the detail page for one model in Model Garden. It is where you evaluate the model and start using it.

Cards typically show an overview, the model's intended use, license and terms, and the actions available for it. Depending on the model, those can be:

• Open in Vertex AI Studio to prompt it
• Deploy to an endpoint
• Enable a managed partner API
• Open notebook for tuning or serving samples

Read the card before building. It tells you whether the model is a managed API or self-deployed, and whether tuning is supported.

There are three common routes, and they all lead to the same catalog.

1. Cloud console: open the platform and choose Model Garden from the Tools or Models menu, then search and filter model cards.
2. Python SDK: the Model Garden module in the Vertex AI SDK, used to list and deploy models in code.
3. gcloud CLI: the gcloud ai model-garden models command group, with list and deploy.

The console is best for exploring and comparing. The SDK and CLI are better for repeatable deployments, scripts and CI pipelines.

One-click deployment is the Deploy button on a model card. It packages the usual steps into a single guided flow: register the model, create an endpoint and start a serving container on suitable hardware.

You still make a few choices, namely the region, endpoint name, machine type and accelerator, and you accept the model license where required. Model Garden suggests tested defaults for the model's size.

When it finishes you have a live Vertex AI endpoint you can call from the SDK or REST. The same flow can be run from code with the SDK or gcloud.

The Model Garden SDK is a module in the Vertex AI SDK for Python that lets you list, deploy and manage Model Garden models from code. Its central class is OpenModel, which wraps a model ID and exposes a deploy() method.

import vertexai
from vertexai import model_garden

vertexai.init(project="my-project", location="us-central1")

model = model_garden.OpenModel("google/gemma3@gemma-3-1b-it")
endpoint = model.deploy()

deploy() returns an endpoint object you can call. It is the code equivalent of the console's Deploy button and is easy to put in a pipeline.

Use the gcloud ai model-garden models command group. list shows deployable models, and deploy creates the endpoint.

gcloud ai model-garden models list
gcloud ai model-garden models list --can-deploy-hugging-face-models

gcloud ai model-garden models deploy \
  --model=google/gemma3@gemma-3-1b-it \
  --region=us-central1

The default list leaves out tuned models and Hugging Face models. Add --can-deploy-hugging-face-models to see the supported Hugging Face ones. For gated Hugging Face models, deploy also accepts --hugging-face-access-token.

Gemma is Google's family of lightweight open-weight models, built with research related to Gemini. In Model Garden it is a common first choice for self-deployment because the smaller sizes fit on a single modest GPU.

Model Garden lists several Gemma variants, including instruction-tuned versions, and gives you notebooks for serving and tuning. The ID format used by the SDK looks like google/gemma3@gemma-3-1b-it.

Gemma is released under its own terms of use, so you accept those before deploying. Note it is open weight, not a managed Google API.

Llama is Meta's open-weight model family. Model Garden offers it in two ways: a curated set as serverless MaaS (for example Llama 4 Scout 17B-16E) and a wider set you can self-deploy.

Llama models are released under Meta's community license, and access is gated. You accept the license in Model Garden, and for Hugging Face downloads you also need an access token.

For the MaaS route you call a Vertex AI endpoint, often with an OpenAI-compatible chat completions interface.

Anthropic's Claude models are partner models offered on Vertex AI as a managed API (MaaS). You enable the model from its Model Garden card, then send requests to Vertex AI endpoints with Google Cloud authentication.

You can call them with Anthropic's SDK, which has a Vertex client, or with raw REST. Always copy the exact model ID from the model card, because IDs are version-specific.

Billing and access run through Google Cloud. Anthropic's models are not self-hosted by you, so there are no GPUs to size.

Model Garden can deploy many Hugging Face models straight to a Vertex AI endpoint. You pass the Hugging Face model ID, such as stabilityai/stable-diffusion-xl-base-1.0, instead of a Model Garden ID.

1. List supported Hugging Face models (the gcloud flag or the SDK's Hugging Face listing option).
2. Pass the model ID to deploy, plus an access token if the model is gated.
3. Pick hardware and wait for the endpoint to become ready.

Only models Model Garden can serve are listed, so not every model on the Hub qualifies. For ones that are not supported, the custom weights route is the alternative.

The token authenticates Vertex AI to Hugging Face when a model is gated, meaning the author requires you to accept terms before downloading weights. Llama is a typical case.

You first accept the license on the model's Hugging Face page, create a read-only token in your Hugging Face account, then pass it at deploy time:

gcloud ai model-garden models deploy \
  --model=meta-llama/Llama-3.2-1B-Instruct \
  --hugging-face-access-token=HF_TOKEN \
  --region=us-central1

Public, ungated models do not need it. Treat the token like a password and keep it out of source control, for example in Secret Manager.

Custom weights deployment lets you serve your own fine-tuned or imported version of a supported base model without writing a serving container. You upload the model files to a Cloud Storage bucket in your project, then deploy from Model Garden.

Key constraints from the docs at the time of writing:

• The feature has been in Preview, so check its current status.
• Files must be in the Hugging Face weights format.
• Quantized models are not supported for import.
• It works for supported base models and many Hugging Face architectures, including LoRA (PEFT) adapters.

The Model Garden SDK can also import Hugging Face weights into a bucket and deploy them in a few calls.

Model Garden ships prebuilt serving containers so you do not assemble the stack yourself. The main runtimes are vLLM, SGLang, Hugging Face TGI (text generation), TEI (text embeddings) and plain PyTorch inference.

Google also publishes some of these images as FedRAMP High compliant containers, which matters for regulated workloads.

Provisioned Throughput reserves model capacity for a fixed fee. You decide how much throughput you need and in which regions, and your requests are prioritized over standard pay-as-you-go traffic.

The result is better availability and steadier latency during busy periods, at the cost of paying for the reservation even when it is idle. It is offered for some partner models, not all.

One limitation to remember: Provisioned Throughput is not supported on the global endpoint, so use a regional endpoint if you depend on it.

Calling a managed model needs the Vertex AI User role (roles/aiplatform.user) on the project, or an equivalent custom role.

Enabling a partner model is a separate step. The Cloud Commerce Consumer Procurement API (cloudcommerceconsumerprocurement.googleapis.com) must be allowed by your organization policy, and whoever enables the model needs permission to manage the procurement entitlement.

For open MaaS models you also need to grant users access to open models before first use. If an organization policy restricts which Model Garden models are allowed, the model must be on the allowed list.

Each open model carries its own license, and Model Garden shows it on the model card. There is no single Google license that covers them all.

• Gemma uses Google's Gemma terms of use.
• Llama uses Meta's community license with usage conditions.
• Other open models may use licenses such as Apache 2.0 or MIT, or custom terms.

You usually accept the terms before deploying, and for gated Hugging Face models also on the Hugging Face page. Check commercial-use limits, attribution rules and any acceptable-use policy before shipping a product built on the model.

Vertex AI Studio is the interactive workspace for prompting and comparing models. Model Garden is where you discover models, and Studio is where you try them.

From a Gemini or supported partner model card, the Open in Vertex AI Studio button loads that model into a prompt workspace. You test prompts, adjust parameters such as temperature and token limits, then export the same call as code.

For open models you deploy yourself, Studio is less central. You normally test the endpoint through the SDK or a notebook.

Managed open models on Vertex AI expose an OpenAI-compatible chat completions API. You point the OpenAI client at the Vertex AI base URL and use a short-lived Google access token as the API key.

import google.auth, google.auth.transport.requests, openai

creds, _ = google.auth.default(
    scopes=["https://www.googleapis.com/auth/cloud-platform"])
creds.refresh(google.auth.transport.requests.Request())

client = openai.OpenAI(
    base_url=f"https://{LOCATION}-aiplatform.googleapis.com/v1/projects/"
             f"{PROJECT}/locations/{LOCATION}/endpoints/openapi",
    api_key=creds.token)

resp = client.chat.completions.create(
    model="meta/llama-4-scout-17b-16e-instruct-maas",
    messages=[{"role": "user", "content": "Define MaaS in one line."}])

The token expires, so refresh it for long-running apps. Take the exact model ID and location from the model card.

The core difference is who runs the infrastructure. With MaaS, Google serves the model as a serverless API. With self-deployment, you run it on endpoint nodes in your own project.

Pick MaaS for speed and spiky traffic, and self-deployment when you need control, customization or steady heavy load.

An open-weight model publishes its trained parameters, so you can run and tune it. A truly open-source model goes further and releases enough, such as code and often data details, under a recognized open license.

Google's own docs make this distinction, and Vertex AI offers both. In practice, check the license on each model card for commercial limits.

The Hub is a vast community repository of models, datasets and Spaces. Model Garden is a curated catalog tied to Google Cloud's deployment, IAM and networking.

They also work together. Model Garden can deploy many Hub models by ID, so the Hub acts as a source and Model Garden as the serving layer.

Choose MaaS when you want the fastest path to production and do not need to touch the weights or the serving stack.

• Traffic is spiky or unpredictable, and idle GPUs would be wasteful.
• You lack ML platform staff to manage GPUs, quota and scaling.
• The model you want exists as a managed API, such as Claude or Llama.

Choose self-deployment when you need a fine-tuned model, a model that is not offered as MaaS, strict network placement, or a steady high load where dedicated nodes cost less per token.

flowchart TD
  A["Need a model"] --> B{"Offered as MaaS?"}
  B -- No --> E["Self-deploy"]
  B -- Yes --> C{"Need custom weights or VPC-only serving?"}
  C -- Yes --> E
  C -- No --> D{"Steady heavy traffic?"}
  D -- Yes --> F["Compare node cost vs per-token cost"]
  D -- No --> G["Use MaaS"]

1. Open Model Garden, search for the model and open its card.
2. Read the license and the deployment notes, then click Deploy.
3. Choose the region, endpoint name, machine type and accelerator. Start from the suggested default.
4. Set minimum and maximum replicas, and any network or encryption options your organization requires.
5. Accept the model terms and start the deployment.
6. Wait until the endpoint shows as ready, then test it with the sample request, a notebook or the SDK.

Deployment can take several minutes because nodes must start and weights must load. If it fails, the usual suspects are GPU quota in the chosen region and a machine type that is too small for the model.

When you press Deploy, Model Garden orchestrates several Vertex AI resources on your behalf.

1. A Model resource is created in the Model Registry, pointing to the serving container and the weight location.
2. An Endpoint resource is created in the chosen region.
3. The model is deployed to the endpoint on nodes with the chosen machine and accelerator.
4. Each node starts the container (for example vLLM), pulls the weights and loads them into GPU memory.
5. After health checks pass, the endpoint accepts prediction requests.

sequenceDiagram
  participant U as You
  participant MG as Model Garden
  participant R as Model Registry
  participant E as Endpoint
  participant N as GPU node
  U->>MG: Click Deploy
  MG->>R: Create Model resource
  MG->>E: Create Endpoint
  MG->>N: Start container and load weights
  N-->>E: Health checks pass
  E-->>U: Ready for requests

Billing for the nodes starts once they are provisioned, so a stuck deployment still costs money until you undeploy it.

Get a handle to the endpoint and call predict. For vLLM-based Model Garden deployments, each instance is a dictionary with a prompt and generation settings.

from google.cloud import aiplatform

aiplatform.init(project="my-project", location="us-central1")
endpoint = aiplatform.Endpoint("ENDPOINT_ID")

resp = endpoint.predict(instances=[{
    "prompt": "Explain MaaS in two sentences.",
    "max_tokens": 128,
    "temperature": 0.2,
}])
print(resp.predictions[0])

Many deployments also accept chat-style payloads, and some work with OpenAI-compatible clients. The model's sample notebook shows the exact request shape. Authenticate with a service account that has the Vertex AI User role.

Enable the Claude model from its Model Garden card, then call it with Anthropic's SDK using the Vertex client. Authentication uses your Google Cloud credentials, not an Anthropic API key.

from anthropic import AnthropicVertex

client = AnthropicVertex(region=REGION, project_id=PROJECT)

msg = client.messages.create(
    model=MODEL_ID_FROM_CARD,
    max_tokens=512,
    messages=[{"role": "user", "content": "Summarize this ticket."}],
)
print(msg.content[0].text)

Use the model ID listed on the card, since IDs are version-specific. A regional endpoint keeps traffic in a region and supports Provisioned Throughput, while the global endpoint favors availability but does not support it.

Most open and fine-tunable model cards offer a tuning path. The two common routes are:

• Notebook: click Open notebook and run the sample in Colab Enterprise or Workbench. You get full control over code, hyperparameters and experiments.
• Managed job: for supported models, launch tuning from the card, point it at training data in Cloud Storage and let Vertex AI run it.

Parameter-efficient methods such as LoRA train small adapters instead of all weights. They need less GPU memory and are cheaper than full fine-tuning.

Dataset formats differ by model, usually JSONL, so follow the card. After tuning you deploy the result to an endpoint and evaluate it against the base model.

There are two paths, depending on how you tuned.

1. Managed tuning job: the tuned model is registered in the Model Registry. Open it and deploy it to an endpoint, or deploy from the tuning job's results.
2. Your own training: save the checkpoint or LoRA adapter in Hugging Face weights format to Cloud Storage, then use the custom weights deployment, from the console or the SDK.

Both routes need the base model to be a supported one. Quantized checkpoints are not accepted by custom weights import, so merge or export in full or half precision first.

After deployment, run the same evaluation set against base and tuned models. A tuned model that wins on your data is worth the endpoint cost, and one that does not should be discarded.

A regional endpoint serves requests from a region you name. A global endpoint does not pin a region, and Google routes the request to wherever capacity is available, which improves availability.

If your policy demands regional processing, you can block the global endpoint with the constraints/gcp.restrictEndpointUsage organization policy constraint.

Use an organization policy that limits which Model Garden models are allowed. It is the Model Garden-specific constraint, constraints/vertexai.allowedModels, and you set it at the organization, folder or project level.

Layer it with other controls:

• IAM: grant Vertex AI User only to the identities that should call models.
• Partner models: the Cloud Commerce Consumer Procurement API must be allowed, and the policy must list the partner model.
• Endpoint restriction: block the global endpoint if you need regional-only processing.

If a user can see a model but a call fails with a policy error, check the allowed-models list first.

For managed APIs, Google states that customer prompts and model responses are not shared with third parties when you use the Vertex AI API. That includes partner models such as Claude and managed open models.

A few details matter for compliance reviews:

• Data at rest stays in the region or multi-region you select for open models.
• Regionalization of processing can vary, so confirm it for the exact model.
• Generative AI certifications on Vertex AI continue to apply to partner and open MaaS use.

With self-deployed models the picture is simpler to defend, because the model runs inside your own project and VPC network and you control logging and egress.

Treat the endpoint like any production API and layer controls from the network to the identity.

1. Private access: use a private endpoint or Private Service Connect so traffic never crosses the public internet.
2. Least-privilege IAM: callers use dedicated service accounts with only Vertex AI User, and the endpoint's own service account is scoped tightly.
3. Perimeter: put the project inside VPC Service Controls to limit data exfiltration.
4. Encryption: use customer-managed encryption keys if your policy requires them.
5. Secrets and audit: keep tokens in Secret Manager and enable audit logging for endpoint calls.

Add input and output filtering at the application layer, since the endpoint serves whatever the model generates.

Neither wins in general. Gemini is usually better when you want top capability with zero infrastructure. A self-deployed open model is better when control, customization or unit cost under steady load matters most.

A practical approach is to prototype on a managed model, measure quality and cost, and move a workload to an open model only when the numbers justify the extra operations.

A quota error means your project has no spare accelerators of that type in that region. The deployment fails or stays pending, and the message names the quota.

1. Read the error and note the accelerator type and region in the message.
2. Open IAM and Admin, then Quotas, filter by the custom model serving quota for that GPU, and check usage against the limit.
3. Request an increase with a justification, or free quota by undeploying idle endpoints.
4. Try a different region or a different accelerator that the model card says is supported.
5. Redeploy once the quota is confirmed.

Quota is separate for each GPU type and region, so having L4 headroom does not help an A100 deployment.

OOM usually means the model plus its KV cache do not fit in GPU memory. Weights take a fixed amount, and long prompts and many concurrent requests grow the cache on top.

Start with the container logs in Cloud Logging, which show whether the crash happened at load time or under traffic.

• At load: the weights are too big. Use a larger accelerator, more GPUs with tensor parallelism, or a quantized variant such as FP8.
• Under traffic: lower the maximum sequence length or concurrent sequences, or the memory-utilization setting of the serving runtime.
• Right-sizing: compare the model card's recommended machine type with what you chose.

Change one setting at a time and redeploy, so you know which change fixed it.

The two codes point to different problems, so separate them first.

Also check the region and model ID. A 404 or a model-not-found message often means the model is not offered in that region or the ID is wrong.

For sustained 429s, a backoff-only client is not enough. Reserve capacity or spread load across supported regions.

Cost for a self-deployed endpoint is mostly accelerator node-hours, so every optimization either shrinks the nodes or shortens the time they run.

• Right-size: pick the smallest machine that fits the model and your traffic, using the card's recommendation as a baseline.
• Quantize: an FP8 or similar variant can fit on cheaper or fewer GPUs, if quality holds on your tests.
• Tune replicas: keep the minimum low and let autoscaling add nodes only under load.
• Undeploy idle endpoints in dev and test, since dedicated endpoints typically keep at least one node warm.
• Commit: use reservations or committed use discounts for steady production load, and consider Spot VMs for tolerant workloads where offered.
• Rethink: if traffic is low or spiky, a MaaS model may simply cost less.

Latency has two parts: time to first token and per-token speed. Throughput is how many requests the node can serve at once. Most levers come from the serving runtime.

• Use a fast runtime such as vLLM or SGLang, which batch requests continuously instead of waiting for fixed batches.
• Parallelize: shard big models across GPUs with tensor parallelism so each token is computed faster.
• Quantize to cut memory traffic, then confirm quality did not drop.
• Cache prefixes: repeated system prompts benefit from prefix caching.
• Limit lengths: a sensible max sequence length frees KV cache for more concurrent requests.
• Stream tokens so users see output sooner, and keep the endpoint close to callers.

Load-test with realistic prompts, because the best settings depend on your input and output lengths.

Build a small golden dataset from your real prompts, with reference answers or rubric criteria, then run each candidate against it.

1. Shortlist a Google, a partner and an open model from Model Garden.
2. Enable partner models first, because the evaluation service needs them enabled before it can run.
3. Run them through the Gen AI evaluation service with the same prompts and metrics.
4. Record quality, latency and cost per request for each.
5. Re-test the winner on a harder, held-out slice before you commit.

A model that is slightly worse on quality but far cheaper may be the right production choice, so weigh all three numbers together.

The lifecycle runs from discovery to monitoring, and Model Garden covers the first half directly.

flowchart LR
  A["Browse Model Garden"] --> B["Read model card and license"]
  B --> C["Try in Studio or notebook"]
  C --> D["Evaluate vs candidates"]
  D --> E{"Tune needed?"}
  E -- Yes --> F["Fine-tune with LoRA or full"]
  E -- No --> G["Deploy"]
  F --> G
  G --> H["Endpoint in production"]
  H --> I["Monitor cost, latency, quality"]
  I --> D

1. Select: shortlist by task, license, size and managed versus self-deployed.
2. Trial: prompt in Studio or run a notebook.
3. Evaluate and tune: measure on your data and tune only if the gap justifies it.
4. Deploy: managed API or endpoint, with IAM and network controls.
5. Operate: watch cost, latency and output quality, then loop back when better models appear.

Undeploying removes the deployed model from the endpoint and releases its serving nodes, so node-hour charges for that deployment stop. Requests to the endpoint that relied on it will fail or fall to other deployed models.

The Model resource stays in the Model Registry, so you can redeploy it later without re-importing. The endpoint also remains until you delete it, and an empty endpoint costs nothing for compute.

• Undeploy: frees GPUs and stops node billing, keeps the Model.
• Delete endpoint: removes the endpoint resource itself, after models are undeployed.
• Delete model: removes the Registry entry, which you only do when you are done with it.

If the endpoint was taking traffic, shift traffic first or redirect clients, to avoid errors.

Use a router in front of several models, so each request goes to the cheapest model that can handle it.

flowchart TD
  C["Client request"] --> R["Router service"]
  R -->|simple| S["Small open model, self-deployed"]
  R -->|complex| M["Managed frontier model, MaaS"]
  R -->|bursty overflow| M
  S -.->|failure or low confidence| M
  M --> O["Response"]
  S --> O

• Small self-deployed model for high-volume, simple tasks such as classification or extraction, where steady load makes dedicated nodes cheap.
• Managed model for hard reasoning and burst traffic, so you do not over-provision GPUs.
• Fallback: route failures or low-confidence answers up to the stronger model.

Log the model used, latency and cost for each request. Those logs let you adjust routing rules with evidence instead of guesses.

Treat a model deployment like application code. Script it with the SDK or gcloud, keep the settings in version control and run it from a pipeline.

1. Define model ID, region, machine type, accelerator and replica limits in a config file.
2. Deploy to a staging endpoint with gcloud ai model-garden models deploy or the SDK's deploy().
3. Smoke test with a fixed prompt set and assert on latency and a few quality checks.
4. Promote by deploying to production, shifting a small share of endpoint traffic first and then the rest.
5. Roll back by routing traffic to the previous deployed model, and undeploy old versions when safe.

Use a dedicated service account for the pipeline, with only the roles it needs, and pull tokens from Secret Manager. Infrastructure-as-code tools can manage the surrounding endpoints, networking and IAM.