The GCP GenAI Stack: Vertex AI, Gemini & Agent Builder

1. The GCP GenAI stack as one mental model

Google Cloud's GenAI story is more centralized than AWS's: almost everything routes through Vertex AI — model consumption (Gemini plus Model Garden), tuning, vector search, agents, and evaluation live under one API surface and one IAM model. The second pillar is BigQuery, which has quietly become a GenAI platform in its own right: embeddings, vector search, and LLM calls as SQL over governed data. The third is the compute substrate — GKE, Cloud Run, and TPUs — for anything you serve yourself. Hold this layering and you can place any interview question in seconds.

Since senior loops routinely ask "why GCP over AWS here?", keep the service-level mirror ready. Chapter 08 owns the AWS depth; this map is the translation table:

2. Gemini inference: two API surfaces, quotas, caching, and batch

The first discriminating question in any GCP loop: which Gemini API are you calling? The Gemini Developer API (AI Studio) authenticates with API keys, is optimized for velocity and free-tier experimentation, and offers few enterprise controls. Vertex AI Gemini serves the same models through aiplatform.googleapis.com with IAM/service-account auth, regional endpoints, VPC Service Controls compatibility, CMEK on stored artifacts, audit logging, and the data-governance commitments enterprises require. The unified Google Gen AI SDK targets both surfaces with a flag flip, so the senior recommendation is: prototype anywhere, but production traffic with corporate data goes through Vertex — the migration is a config change, not a rewrite. The core methods are generateContent and streamGenerateContent (SSE), with system instructions, tool/function declarations, structured output, and safety settings in one request shape across Gemini versions.

How you buy tokens is the second discriminator. Vertex replaced most fixed per-model rate quotas for Gemini with Dynamic Shared Quota (DSQ): pay-as-you-go requests draw from a shared regional capacity pool with no per-project guarantee — you get elasticity but must engineer for 429s. When you need contractual throughput, Provisioned Throughput sells committed capacity in generative AI scale units (GSUs) on weekly-to-multi-month terms per model, with overage spilling to DSQ by default. This is the exact analog of the Bedrock on-demand-versus-provisioned decision from chapter 08, with one twist worth naming: the global endpoint raises availability by routing to any region — mirroring AWS cross-region inference profiles, and carrying the same residency caveat.

flowchart TD
  A["New Gemini workload on Vertex AI"] --> B{"Latency-coupled user traffic?"}
  B -->|"no, offline"| C["Batch prediction: BigQuery or GCS input at a deep discount"]
  B -->|"yes"| D{"Hard throughput SLO or launch spike?"}
  D -->|"spiky, exploratory"| E["Pay-as-you-go on Dynamic Shared Quota"]
  D -->|"steady floor, hard SLO"| F["Provisioned Throughput in GSUs"]
  E --> G["Engineer for 429s: retries with jitter, regional failover"]
  F --> H["Size GSUs from measured tokens per second, spill bursts to DSQ"]
  C --> J["Outputs land in BigQuery for evals and joins"]
    

Two multipliers change the math on any purchase mode. Context caching comes in two forms: implicit caching, on by default for current Gemini models, which discounts input tokens automatically when your request shares a prefix with recent traffic; and explicit caching, where you create a cached-content object with a TTL and pay a per-token-hour storage fee in exchange for a steep discount (on the order of 75% off standard input pricing per the pricing page, as of the checked date) on every hit. Explicit caching wins when a large stable block — tool schemas, a policy manual, a video — is reused heavily inside the TTL; it loses when hit rates are low and storage-hours dominate. Batch prediction reads from a BigQuery table or GCS JSONL, runs with no latency SLA, and prices at roughly half of interactive rates — the BigQuery-native input/output is a genuine differentiator over AWS's S3-only batch path for analytics-adjacent workloads.

sequenceDiagram
  participant C as "Client"
  participant R as "Cloud Run service"
  participant V as "Vertex AI Gemini endpoint"
  C->>R: POST chat turn
  R->>V: streamGenerateContent with cachedContent reference
  V-->>R: token deltas over server-sent events
  R-->>C: forwarded SSE chunks as they arrive
  V-->>R: usageMetadata with cached token counts
  R-->>C: terminal event with usage and finish reason
    

Finally, Model Garden is the catalog: Gemini first-party; partner models as-a-service — notably Anthropic Claude on Vertex, billed through GCP with the same enterprise controls; and open models (Gemma, Llama, Mistral, DeepSeek, Qwen) that you deploy to Vertex endpoints or export to your own GKE/Cloud Run serving. The senior distinction is model-as-a-service versus self-deployed: MaaS models bill per token with zero capacity management; self-deployed open models bill per accelerator-hour on endpoints you size — that difference drives section 8's economics.

3. Grounding: Google Search, Vertex AI Search, and RAG Engine

GCP offers a graduated ladder of grounding options, and interviewers test whether you can place a use case on the right rung instead of hand-building RAG by reflex. The grounding overview frames three managed rungs before DIY:

The reference architecture below is the one to draw for "enterprise RAG on GCP." The load-bearing choices: Vertex AI Search for ingestion and ACL-aware retrieval (managed), your own generation call for contract control (custom), Model Armor screening on the way out, and logging to BigQuery so evaluation (chapter 06) runs as SQL over real traffic.

flowchart LR
  subgraph ING["Ingestion path"]
    SRC["GCS, Drive, SharePoint sources"] --> VAS["Vertex AI Search: parse, chunk, embed, rank"]
  end
  subgraph SRV["Serving path"]
    CL["Client app"] --> RUN["Cloud Run API with IAM auth"]
    RUN --> VAS
    RUN --> GEM["Gemini generateContent with retrieved chunks"]
    GEM --> MA["Model Armor: injection and safety screen"]
    MA --> RUN
  end
  GEM --> LOG["Request-response logging to BigQuery"]
  RUN --> OBS["Cloud Trace and Cloud Logging"]
    

The break-out logic mirrors chapter 08's Knowledge Bases discussion: stay fully managed (Vertex AI Search answer generation) for pilots and internal tools; split to managed retrieval, custom generation when you need response contracts, custom reranking, or multi-source federation; drop to RAG Engine or DIY only when the managed ranker demonstrably fails your eval set. Saying "I would benchmark Vertex AI Search's ranking against my custom pipeline before building anything" is a stronger senior move than defaulting to either extreme — Google's ranking stack is genuinely hard to beat on heterogeneous enterprise corpora.

4. The vector-store decision: Vector Search, AlloyDB, BigQuery

Vertex AI Vector Search is the productization of Google's ScaNN research (Guo et al., anisotropic vector quantization) — the same ANN family behind Google Search and YouTube retrieval. Know its shape: a tree-AH index (with a brute-force option for ground-truthing recall), deployed to index endpoints with dedicated serving replicas, streaming index updates for near-real-time upserts versus cheaper batch rebuilds, namespace/numeric restricts for filtered ANN, and autoscaling. Its trade profile: excellent recall-QPS-latency at tens of millions to billions of vectors, but an always-on serving-node cost floor — the same "idle dev index still bills" caveat as OpenSearch Serverless on AWS.

The interview-ready heuristic: latency class first, data gravity second, ops ownership third. Chat-path retrieval under ~100 ms at high QPS → Vector Search. Retrieval that must join user entitlements and transactional state → AlloyDB pgvector. Anything batch or analytical → BigQuery, and moving those workloads out of a serving store is often the cheapest optimization you can name. Chapter 04 owns retrieval science (chunking, hybrid search, reranking); your GCP-specific value is this placement argument plus the streaming-versus-batch index-update trade: streaming updates cost more per write but close the freshness gap for use cases like product catalogs, where a nightly batch rebuild silently serves stale inventory all day.

5. The Agent Builder ecosystem: ADK, Agent Engine, and A2A

Google's agent stack cleanly separates framework from runtime, and interviewers reward candidates who use that separation. The Agent Development Kit (ADK) is the open-source framework (Python and Java): LLM agents, deterministic workflow agents (sequential/parallel/loop), multi-agent hierarchies with delegation, tools (function tools, built-in Google Search and Vertex AI Search tools, OpenAPI tools, MCP tool support), callbacks for guardrails, and a local dev UI with built-in evaluation. ADK code is deployable anywhere a container runs. Vertex AI Agent Engine is the managed runtime: sessions, a managed Memory Bank for long-term memory, scaling, identity, VPC-SC compatibility, and tracing — the place you deploy an ADK (or LangGraph, or CrewAI) agent when you stop wanting to own that infrastructure. It is the direct counterpart of Bedrock AgentCore Runtime from chapter 08.

• ADK — agent logic as code: planners, workflow agents, tool declarations, callbacks; framework-agnostic deploy target.
• Agent Engine — managed sessions, Memory Bank, scaling, and runtime isolation; bring ADK or another framework.
• A2A protocol — an open, Linux Foundation-governed protocol (spec) for agent-to-agent discovery and task exchange across vendors and runtimes via agent cards.
• Tools & extensions — built-in Search/RAG tools, code execution, function calling, MCP servers, and Apigee/Application Integration connectors for enterprise systems.
• Observability — Agent Engine emits traces to Cloud Trace and logs to Cloud Logging; ADK's eval harness runs trajectory tests pre-deploy.

flowchart TD
  U["Caller: app or workflow"] --> AE["Agent Engine runtime: sessions and scaling"]
  AE --> ADK["ADK agent: planner plus workflow sub-agents"]
  ADK --> GEM["Gemini on Vertex AI"]
  ADK --> T1["Built-in tool: Vertex AI Search grounding"]
  ADK --> T2["Function tools on Cloud Run"]
  ADK --> T3["MCP tools and Apigee connectors"]
  AE --> MB["Memory Bank: long-term user memory"]
  ADK --> PA["Peer agent via A2A agent card"]
  AE --> OBS["Cloud Trace spans and Cloud Logging"]
    

The placement decision mirrors AWS but with GCP's accents. If the flow is deterministic, Workflows or a plain Cloud Run service calling Gemini beats any agent framework — same "refuse the agency" test as chapter 08, and chapter 05 covers when agency is genuinely warranted. If you need an agent, ADK-on-Agent-Engine is the default GCP answer because session state, memory, and tracing arrive managed. Self-hosting an agent loop on Cloud Run remains right when you need custom runtime behavior or already operate that infra. On A2A: position it as the inter-organizational and cross-runtime seam — valuable when agents from different teams or vendors must interoperate; premature when one team owns all agents in one runtime, where in-process delegation via ADK sub-agents is simpler and faster. Knowing that boundary — MCP standardizes agent-to-tool, A2A standardizes agent-to-agent — is a reliable senior discriminator in 2026 loops.

6. Tuning on Vertex: Gemini SFT and the serving-economics asymmetry

Supervised fine-tuning for Gemini is the managed adaptation path: JSONL prompt-completion datasets, adapter-based training under the hood, versioned tuned models, and — the fact that wins interviews — tuned Gemini models serve on the shared endpoint at the same per-token price as the base model. Contrast chapter 08: Bedrock custom models generally require provisioned throughput or dedicated model copies, an always-on capacity floor that can erase per-token savings. On GCP, the marginal serving cost of a tune is approximately zero, which moves the break-even for fine-tuning meaningfully earlier. If a candidate can articulate that asymmetry with the utilization math, they have demonstrated real multi-cloud judgment rather than feature recitation.

Scope discipline for the interview: chapter 03 owns when and how to adapt (LoRA math, data curation, catastrophic-forgetting risks); your GCP-specific claims are the offering matrix — SFT is the supported managed path for current Gemini text models, adapter training for open models runs as Vertex custom jobs or Model Garden recipes — and the serving-economics argument above. If asked about RLHF-style preference tuning on Vertex, the honest answer is that managed preference tuning has come and gone from the catalog; verify current model support in the docs rather than asserting from memory — saying exactly that earns more trust than a confident guess.

7. BigQuery as an AI data platform

BigQuery's GenAI surface (docs) turns the warehouse into a batch GenAI runtime: ML.GENERATE_EMBEDDING calls a remote Vertex embedding model over millions of rows; CREATE VECTOR INDEX builds IVF or TreeAH (ScaNN-family) indexes; the VECTOR_SEARCH table function does semantic joins in SQL; and AI.GENERATE-family functions (successors to ML.GENERATE_TEXT) run row-wise Gemini generation with structured outputs — all governed by BigQuery IAM, row-level security, and lineage, with zero data movement. Classic BigQuery ML still handles tabular models beside it. There is no AWS equivalent of comparable depth — Redshift ML is far thinner — which makes this a legitimate, defensible "why GCP" argument in cloud-choice questions.

flowchart LR
  SRC["Raw tables in BigQuery"] --> EMB["ML.GENERATE_EMBEDDING via remote Vertex model"]
  EMB --> IDX["Vector index: IVF or TreeAH"]
  IDX --> VS["VECTOR_SEARCH semantic joins"]
  SRC --> GEN["AI.GENERATE row-wise enrichment with Gemini"]
  GEN --> CUR["Curated, enriched tables"]
  VS --> APP["Similarity features for apps and models"]
  CUR --> LKR["Looker dashboards and activation"]
    

Use cases that belong here: product-catalog enrichment (classify, normalize, describe millions of SKUs), support-ticket triage and clustering, entity resolution via embedding similarity, offline evaluation of RAG systems against logged traffic, and semantic deduplication. The boundary to state crisply: BigQuery is a batch and analytical latency class. Row-wise generation over big tables runs through Vertex quota (reserve Provisioned Throughput or run during batch windows for large jobs), and VECTOR_SEARCH answers in seconds, not the tens of milliseconds a chat path needs. The senior architecture is complementary: embeddings computed and evaluated in BigQuery, then synced to Vector Search or AlloyDB for online serving — one embedding lineage, two latency classes.

8. Serving open models: GKE + vLLM, Cloud Run GPUs, Vertex endpoints

When the model is open-weights, GCP gives you three serving postures, and the decision is utilization economics plus ops appetite — the same framework as chapter 08's Bedrock-versus-EKS argument, with chapter 02 owning the serving internals (continuous batching, paged KV cache, quantization).

Cloud Run GPUs are the genuinely differentiated option to name: AWS has no serverless-GPU-container equivalent with scale-to-zero in the same shape, so "spiky Gemma-class workload → Cloud Run GPU" is a crisp GCP-specific answer. The TPU card matters too — vLLM has TPU support, and TPU capacity is sometimes easier to obtain than H100-class GPUs — but present it honestly: it pays off at sustained scale with a team willing to benchmark, not as a default. For everything else, the chapter 08 break-even logic transfers verbatim: per-token MaaS beats per-hour self-hosting until utilization is provably high, and most teams overestimate their sustained utilization.

9. Security architecture: IAM, VPC Service Controls, CMEK, residency

The GCP security story has one concept AWS answers differently, and leading with it wins regulated-industry interviews: VPC Service Controls puts a data-exfiltration perimeter around API services themselves. Inside a perimeter, aiplatform.googleapis.com can only be called from authorized networks/identities, and — the crucial half — data cannot flow out to non-perimeter projects even by a credentialed insider or a leaked service-account key. PrivateLink on AWS gives you a private network path; VPC-SC gives you a policy boundary on the service plane. Pair it with Private Service Connect for private connectivity and you have both.

flowchart LR
  subgraph PER["VPC Service Controls perimeter"]
    APP["App in private VPC"] --> PSC["Private Service Connect endpoint"]
    PSC --> VAPI["Vertex AI regional endpoint"]
    VAPI --> KMS["CMEK via Cloud KMS on tuned models, indexes, caches"]
  end
  APP -.-> SA["Least-privilege service account via Workload Identity"]
  VAPI --> AUD["Admin Activity plus opt-in Data Access audit logs"]
  VAPI --> RESID["Regional processing for residency commitments"]
    

• IAM and service accounts — scope roles/aiplatform.user per workload; workloads authenticate via Workload Identity Federation, never exported keys; separate service accounts for ingestion, serving, and tuning so blast radius is per-function.
• CMEK — customer-managed keys on tuned models, Vector Search indexes, context caches, and datasets; key revocation is your kill switch and the key policy is a second audit boundary.
• Data governance — per the Gen AI data-governance docs: customer prompts and outputs are not used to train foundation models without permission; state that precisely, then name the operational caveats you would verify — caching behavior and any abuse-monitoring retention, with zero-retention configurations available for stricter regimes.
• Residency — regional endpoints keep ML processing in-region; the global endpoint and cross-region features trade that away for availability. Same clause structure as AWS cross-region inference profiles: compliance signs off first.
• Audit — Cloud Audit Logs: Admin Activity is always on; Data Access logs for Vertex are opt-in and can capture request content — the same "audit asset, PII liability" tension as Bedrock invocation logging, so pair enabling them with CMEK buckets, retention rules, and access reviews.
• Model Armor — a model-independent screening service for prompt injection, jailbreaks, sensitive-data leakage, and unsafe content on both prompts and responses; GCP's counterpart to Bedrock Guardrails, and like it, one layer of defense-in-depth, not the whole story (chapters 05 and 11).

10. Observability and cost engineering on Vertex

Vertex AI publishes per-model metrics to Cloud Monitoring — invocation counts, latencies, token throughput, and error/throttle rates — and application-level telemetry flows through Cloud Logging and Cloud Trace (Agent Engine emits OpenTelemetry spans natively). The GCP-specific habit worth naming: route request-response logs and token usage into BigQuery, because your eval harness, cost attribution, and drift analysis then become SQL over one table instead of three tools. Alarm on 429 rate (DSQ pressure), p95 time-to-first-token, and tokens-per-request drift — the last one catches prompt regressions and context-stuffing bugs before the invoice does. Deeper LLMOps discipline lives in chapter 11; here, know which surface emits which signal.

Cost engineering on Vertex is an inventory of pricing dimensions (pricing page) plus levers in a fixed order. First, model routing: Gemini Flash tiers are多 an order of magnitude cheaper than Pro — route by task difficulty and escalate on failure (chapter 07's gateway pattern). Second, context caching: explicit caches for heavy shared prefixes, with the storage-hour term in your break-even; implicit caching rewards stable prompt layouts for free. Third, batch everything latency-tolerant for the ~50% discount, with BigQuery-native I/O. Fourth, Provisioned Throughput sized to the measured floor, not the peak — GSU commitments are per-model and per-term, so commit late and let DSQ absorb spikes. Watch the long-context pricing tier: above the per-model threshold, input tokens price higher, so a lazy "stuff the whole corpus in context" design can double unit cost silently. For self-hosted serving, standard committed use discounts on GPUs/TPUs apply — a different ledger from token spend, and conflating the two in an interview reads as never having owned a bill.

11. Interview scenarios: GCP solution-design drills

Three scenarios cover most senior GCP GenAI loops. Practice narrating each in under four minutes with a drawn diagram, and close every one with the first-week production metrics you would watch.

Scenario 1 — "A hospital network wants a clinician assistant over internal protocols; data cannot leave their boundary."

Strong answer skeleton: requirements first — residency, PHI exposure, auditability, then Figure 3's shape hardened by Figure 6: Vertex AI Search over GCS/Drive protocol sources with ACL-aware retrieval, custom generation via regional Gemini endpoints (no global endpoint until compliance clears it), the whole project set inside a VPC Service Controls perimeter with PSC access, CMEK on every stored artifact, Data Access logs enabled into a locked, CMEK-encrypted sink, Model Armor on both directions, and chapter 06 eval gates before any prompt or model change. Name the refusals: no Grounding with Google Search (public-web egress), no consumer Gemini API anywhere in the path, no Data Access logging without a PHI-retention review.

Scenario 2 — "We have three teams building agents; make it a platform, not chaos."

Strong answer skeleton: Figure 4 as the target: ADK as the shared framework (with its eval harness as the pre-deploy gate), Agent Engine as the common runtime giving sessions, Memory Bank, and Cloud Trace uniformly; tools exposed through a governed catalog — Apigee/MCP for enterprise APIs so tool auth is centralized, not per-agent; A2A only at the seams where teams' agents must interoperate as black boxes. Per-team service accounts and budgets; token telemetry to BigQuery for per-agent cost. The differentiator: state the deterministic-flow test first — any "agent" whose steps are enumerable gets compiled into Workflows and removed from the platform's risk surface.

Scenario 3 — "A retailer wants semantic search and AI-enriched product data for 20M SKUs."

Strong answer skeleton: Figure 5 for the offline half — AI.GENERATE enrichment and ML.GENERATE_EMBEDDING in BigQuery as scheduled batch (batch-priced tokens, PT reservation if windows are tight), evaluated in place with SQL over sampled outputs; then sync embeddings to Vertex AI Vector Search with streaming updates for the online half, because inventory freshness is the business requirement. Quantify the token math per SKU as an estimate you would refine, name the two latency classes explicitly, and give the cost levers: Flash-tier models for enrichment, TreeAH index economics versus serving-replica count, and re-embedding cadence tied to catalog churn, not calendar habit.

Interview playbook

Answer framework for GCP GenAI questions: (1) restate the workload in capability terms — latency class, volume shape, data sensitivity, freshness; (2) place it on the three-pillar model (Vertex AI plane / BigQuery data plane / GKE-Cloud Run compute plane); (3) pick services with one named alternative each and the reason; (4) attach the cross-cutting story — service accounts, VPC-SC, CMEK, audit logs, cost attribution; (5) close with the first three production metrics you would watch.

• Senior signals — DSQ versus GSU capacity reasoning; explicit-versus-implicit caching with the storage-hour term; tuned-Gemini shared-serving economics versus Bedrock; the two-latency-class embedding architecture (BigQuery offline, Vector Search online); VPC-SC as a perimeter, not a network path.
• Common traps — treating DSQ as "no limits"; proposing BigQuery vector search on a chat path; Grounding with Google Search in a data-egress-restricted design; conflating Agent Engine with Gemini Enterprise; quoting prices from memory instead of naming the dimension and checking the page.
• Stay in your lane — retrieval science is chapter 04, agent patterns chapter 05, evals chapter 06, gateway/streaming chapter 07, AWS equivalents chapter 08, LLMOps chapter 11. Reference them; do not re-derive them mid-answer.

Question bank

Proof artifact: a two-latency-class RAG stack on GCP, costed and broken

Build one small system that produces evidence for five chapter themes: API-surface choice, grounding-ladder judgment, the two-latency-class embedding architecture, security posture, and cache/batch economics. Keep the corpus small (50–100 public documents) so the lab stays in low tens of dollars — and tear down Vector Search endpoints afterward, because that is where the idle cost lives.

1. DeployLoad documents into GCS → BigQuery; compute embeddings with ML.GENERATE_EMBEDDING; build a TreeAH index in BigQuery for offline search AND sync the same vectors to a Vertex AI Vector Search streaming index; serve via Cloud Run calling streamGenerateContent with retrieved chunks.
2. HardenDedicated service account with least-privilege roles; CMEK on the GCS bucket and index; enable Data Access audit logs into a locked sink; document what a VPC-SC perimeter would add (dry-run it if you have an org).
3. MeasureDrive 200 scripted queries against both retrieval paths; record p50/p95 latency per path, recall overlap between BigQuery VECTOR_SEARCH and Vector Search results, tokens per answer, and cost per answered question from usage logs in BigQuery.
4. Break it — quotaBurst pay-as-you-go traffic until 429s appear; show the failure without retries, then with exponential backoff and a queue; graph both. Write one paragraph on what GSU floor you would buy from the measured tokens/sec.
5. Break it — stalenessUpdate 10 documents; show the streaming index reflecting changes in near-real-time while the batch-built BigQuery index serves stale results until rebuild; connect this to the freshness argument of section 4.
6. Compare economicsRe-run the query set three ways: cold, with an explicit context cache on the system prompt + policy block, and as a batch prediction job. Produce a one-page table of cost per 1k answers for each mode, dated and labeled as your own measurements.

What to present in an interview: the architecture diagram with both latency classes, the staleness demonstration, and the three-mode cost table. "I measured the cache discount and the batch discount myself, on this date, and here is where each wins" is the sentence that separates you from the certification crowd.

Chapter review

You now hold GCP GenAI as three pillars — Vertex AI as the single model/agent plane, BigQuery as the governed data-and-batch-GenAI plane, GKE/Cloud Run as the self-managed compute plane — crossed by a security model whose signature move is the VPC-SC perimeter. The recurring senior patterns: buy Gemini capacity deliberately against DSQ's non-guarantee (Figure 1), stream with caching discipline (Figure 2), descend the grounding ladder only on eval evidence (Figure 3), give agents a managed runtime and refuse unneeded agency (Figure 4), run batch GenAI where the data lives (Figure 5), and draw the perimeter-protected invocation path by default (Figure 6).

Dynamic Shared Quota

Pay-as-you-go Gemini capacity from a shared regional pool — elastic, but no per-project guarantee; 429s are a design input.

Provisioned Throughput / GSU

Committed Gemini capacity purchased in generative AI scale units per model and term; overage spills to DSQ.

Context caching

Implicit prefix-hit discounts by default; explicit cachedContent objects trade a per-token-hour storage fee for steep per-hit discounts.

Model Garden

Vertex catalog spanning Gemini, partner models-as-a-service (including Claude), and deployable open models.

Vertex AI Search

Turnkey enterprise retrieval: connectors, parsing, ranking, ACL-aware results; the default managed RAG baseline.

RAG Engine

Managed, programmable RAG framework with pluggable vector backends — the middle rung between turnkey and DIY.

ScaNN / tree-AH

Google's anisotropic-quantization ANN lineage behind Vertex AI Vector Search, AlloyDB's ScaNN index, and BigQuery's TreeAH.

ADK

Open-source Agent Development Kit: agents, tools, callbacks, multi-agent hierarchies, built-in evals; deploys anywhere.

Agent Engine

Managed agent runtime on Vertex: sessions, Memory Bank, scaling, tracing; hosts ADK and other frameworks.

A2A

Open, Linux Foundation-governed agent-to-agent protocol — discovery via agent cards and task exchange across runtimes.

VPC Service Controls

Service-plane perimeter blocking data exfiltration to non-perimeter projects even with valid credentials.

Model Armor

Model-independent prompt/response screening for injection, jailbreaks, and sensitive data — GCP's guardrails layer.

• I can explain Gemini API versus Vertex AI Gemini with three concrete enterprise controls and the SDK portability fact.
• I can reason about DSQ versus GSU commitments from measured tokens/sec, and design for 429s.
• I can compute a context-caching break-even including the storage-hour term, and protect implicit caching with prompt layout.
• I can place a use case on the grounding ladder and state the descent criteria.
• I can defend a vector-store choice by latency class, data gravity, and cost floor — and name the two-latency-class hybrid.
• I can separate ADK from Agent Engine from A2A, and refuse agency for deterministic flows.
• I can state the tuned-Gemini shared-serving asymmetry against Bedrock with its break-even consequence.
• I can deliver the four-clause data-governance answer with its opt-in caveats, and draw the VPC-SC invocation path.
• I can cut a Vertex bill with attribution-first diagnosis across five pricing dimensions.