Book TOC · Previous · Chapter 4 of 8 · Next

Chapter 4: Enterprise Domain Knowledge: RAG Pipelines, Vector Search, Identity & MCP Tooling

Official Exam Guide Subsections Consolidated: 3.2

Chapter Consolidation Telemetry: Synthesizes 44 architectural scenarios across 1 Exam Subsections and 3 Official Considerations into consolidated takeaway pillars, paired with 1 Reference Architecture Mermaid Diagrams and 8 Curated Visual Illustrations.

Chapter Focus: Hybrid Search (BM25 + Dense Vector + RRF), AlloyDB ScaNN vs. Vertex AI Vector Search, WIF/OAuth 2.0 identity propagation, and resilient MCP tool schemas.


Subsection 3.2: Integrating Enterprise Domain Knowledge: RAG Pipelines, Vector Search, Agent Identity, and MCP Tool Ecosystems

Part III: Developing Custom Agents (~33% of Exam) · 3 Official Considerations · 44 Scenarios Consolidated

Domain Overview and Reference Architecture

Precision Knowledge & Tool Integration: Why Naive Vector Search and Direct Database Credentials Fail

In Subsection 3.2, your custom agent needs access to live enterprise domain knowledge—spanning unstructured policy documents (3.2a), strictly scoped identity permissions (3.2b), and structured databases or third-party SaaS APIs (3.2c).

Three architectural traps dominate this domain on the exam:

  1. The "Naive Dense-Only RAG" Trap (3.2a): A developer splits PDFs into arbitrary 500-character chunks (slicing financial tables in half), embeds both short user queries and long documents using symmetric embedding settings, and runs pure dense cosine similarity search in Vector Search. When a user searches for an exact alphanumeric SKU like "ERR-9042-X" or asks a nuanced clinical question, dense embeddings return topically similar but factually wrong chunks! Production RAG requires Layout-Aware Chunking, Asymmetric Task-Type Embeddings (RETRIEVAL_QUERY vs. RETRIEVAL_DOCUMENT), Hybrid Search (Dense Semantic + Sparse BM25 Keyword), and Cross-Encoder Semantic Reranking.
  2. The "Broad Service Account & Direct SQL Generation" Trap (3.2b & 3.2c): Giving an agent a broad roles/owner or roles/cloudsql.admin identity and allowing the LLM to execute raw, unvalidated SQL strings directly against Cloud SQL or BigQuery invites catastrophic data deletion (DROP TABLE), prompt-injected SQL exfiltration, and runaway $10,000 full-table scans. You must enforce dedicated Agent Identity least privilege, expose databases through Google Cloud MCP Servers using parameterized read-only SQL templates (or maximumBytesBilled guards in BigQuery), and catalog all approved tools in Agent Registry.
3.2a: High-Precision Enterprise RAG Pipeline (RAG Engine + Vector Search 1.0) Enterprise Corpus (PDFs, Tables, Manuals) 1. Layout-Aware Chunking (Preserve Markdown Tables & Section Headers) 2. Asymmetric Embeddings (Doc: RETRIEVAL_DOCUMENT Query: RETRIEVAL_QUERY) ("3. Vector Search 1.0 • Streaming Index Updates • Hybrid Search: Dense + Sparse BM25 • Metadata Pre-Filtering (ACL/Tenant)") 4. Cross-Encoder Reranker (Top-50 Candidates -> Top-5 High-Precision Chunks) 3.2b & 3.2c: Agent Identity, Agent Registry & Google Cloud MCP Servers Custom ADK Agent (Scoped Agent Identity) Agent Registry (Central Governance Catalog) Google Cloud MCP Servers • Parameterized Cloud SQL Queries • BigQuery Read-Only + MaxBytesBilled • 3rd-Party SaaS OAuth Passthrough • MCP Resources (Read-Only) vs Tools (Action) Custom ADK Agent --[Discovers Approved Tools]--> Agent Registry Custom ADK Agent --[Invokes Prebuilt / Custom MCP]--> Google Cloud MCP Servers

Core Foundational Primitives & Mental Models (Subsection 3.2)

Overview diagram of the RAG workflow, showing external documents, vector stores, and prompt augmentation leading to a grounded response.
RAG grounds LLM outputs by injecting retrieved factual context directly into the prompt before generation occurs.
Core Concept / Service
Winning Architectural Rule & Default Behavior
Common Exam Trap to Avoid
Retrieval-augmented generation
(Services: vertex_ai:grounding, vertex_ai:search, vertex_ai:rag)
Retrieval-augmented generation (RAG) retrieves relevant external enterprise documents to provide factual context and ground LLM outputs.
Static weights quantization reduces model parameter precision to decrease memory usage, not to supply external knowledge.
Embedding generation
(Services: vertex_ai:embeddings, vertex_ai:vector_search)
Embedding generation transforms text into high-dimensional numerical vectors that capture semantic meaning for vector similarity search.
OAuth exchange is an authentication and authorization protocol, not a mathematical text vectorization process.
Reranking
(Services: vertex_ai:search, vertex_ai:rag, vertex_ai:ranking_api)
Reranking evaluates initial retrieval candidates and reorders them by relevance before passing the top results to the LLM.
Token masking is a model training technique, not an information retrieval ordering process.
Vector Search
(Services: vertex_ai:vector_search, vertex_ai)
Vertex AI Vector Search is specifically designed to perform low-latency, high-scale approximate nearest neighbor vector searches across billions of embeddings.
Compute Engine provides general-purpose virtual machine (VM) instances and is not a purpose-built vector search engine.
Agent Retrieval
(Services: vertex_ai:agents, vertex_ai:search, vertex_ai:grounding)
Agent Retrieval is designed specifically to ground generative agents in enterprise knowledge bases and data stores.
Cloud Tasks is an asynchronous execution and queueing service, not a semantic retrieval mechanism.
Agent Registry
(Services: vertex_ai:agent_builder, vertex_ai)
Agent Registry is specifically designed to manage enterprise agent metadata, capabilities, and discovery.
Cloud Spanner is a globally distributed relational database, not an AI agent metadata registry.
Agent Identity
(Services: vertex_ai:agents, iam)
Agent Identity assigns unique service account credentials and IAM roles to individual agents.
Cloud Trace analyzes request latency and performance rather than access credentials.
Google Cloud MCP Servers
(Services: vertex_ai:agents, vertex_ai:model_garden)
Model Context Protocol (MCP) servers provide a standardized protocol interface for agents to integrate with external tools and third-party SaaS APIs.
Raw serial ports are low-level hardware interfaces, not application protocols for SaaS integration.
RAG Engine
(Services: vertex_ai:rag_engine, vertex_ai:grounding)
Vertex AI RAG Engine is the dedicated managed service that handles end-to-end RAG indexing and retrieval workflows.
Compute Engine provides raw virtual machine (VM) infrastructure rather than managed RAG pipelines.
Vector Search
(Services: vertex_ai:vector_search, vertex_ai:embeddings)
Vertex AI Vector Search stores and retrieves high-dimensional vector embeddings with low latency and high scale for retrieval-augmented generation.
Cloud Armor provides DDoS and web application firewall security, not vector indexing.
BigQuery
(Services: bigquery:analytics, vertex_ai:agents)
BigQuery is Google Cloud's fully managed enterprise data warehouse optimized for scalable structured SQL analytics.
Cloud Shell provides a web-based command-line interface for administration, not database services.
Cloud SQL
(Services: cloud_sql, vertex_ai:agents)
Cloud SQL is Google Cloud's fully managed relational database service that delivers ACID-compliant transactional data access.
Model Armor is a security service for generative AI models, not a database service.

Official Exam Considerations & Consolidated Takeaways (Subsection 3.2)

Consideration 3.2a: Designing, configuring, and managing retrieval-augmented generation (rag) pipelines and vector retrieval systems (e.g., embedding models, similarity scoring, and reranking) using appropriate services such as vector databases (e.g., vector search and agent retrieval)

Master the 5 stages of an exam-grade RAG architecture using RAG Engine, Agent Retrieval, and Vector Search 1.0:

  • 1. Layout-Aware Chunking: Never use naive fixed-character splitting on documents containing tables, financial statements, or code blocks. Use Document AI Layout Parser or markdown-aware chunking that keeps entire tables and section headers intact within each chunk.
  • 2. Asymmetric Task-Type Embeddings: Short user questions and long document passages have different statistical distributions. Configure Vertex AI text embedding models with task_type="RETRIEVAL_DOCUMENT" during indexing and task_type="RETRIEVAL_QUERY" at search time.
  • 3. Hybrid Search (Dense + Sparse BM25): Dense vector embeddings capture conceptual meaning ("automobile" pprox "car"), but fail on exact out-of-vocabulary strings (part numbers, error codes, legal citations, function names). Configure Hybrid Search in Vector Search 1.0 combining dense semantic vectors with sparse token/keyword embeddings (BM25/SPLADE) merged via Reciprocal Rank Fusion (RRF).
  • 4. Two-Stage Retrieval with Cross-Encoder Reranking: Bi-encoder vector search is fast ($O(\log N)$ ANN lookup) but coarse. Retrieve a broad candidate set (e.g., top_k = 50) from Vector Search, and pass those 50 chunks through a Semantic Cross-Encoder Reranker (which attends jointly to query + document tokens) to select the top 5 most relevant chunks for the LLM prompt.
  • 5. Streaming Index Updates vs. Batch Rebuild & Live Tools: Use Vector Search Streaming Updates when manuals or articles change throughout the day and must be searchable within seconds. However, if data changes sub-second on every transaction (e.g., live stock prices or real-time warehouse inventory counts), do not use RAG/Vector Search—call a real-time MCP Tool / API instead!
Diagram showing how RETRIEVAL_QUERY and RETRIEVAL_DOCUMENT create an aligned vector path.
Correct alignment of task types ensures that short queries and long documents map to nearby regions in the vector space, enabling successful retrieval.
How hybrid search resolves alphanumeric mismatches by combining sparse and dense results.
Hybrid search resolves mismatches by using sparse retrieval to secure exact matches while dense retrieval handles conceptual context.
Takeaway 1: Optimizing Chunking Strategies for Tabular Enterprise Policies (vertex_ai:search · vertex_ai:agent_builder · document_ai)
  • Core Concept: Chunking strategies and structural metadata preservation in RAG ingestion pipelines
  • Scenario Trigger & Requirement: A scenario where a Retrieval-Augmented Generation (RAG) agent fails to provide accurate answers because tabular benefit schedules from PDF files are split by a naive character-based chunking strategy. The core challenge is choosing an ingestion strategy that preserves the structural integrity of tables.
  • Winning Architecture & Implementation: Parse the documents with Document AI or layout-aware chunking to maintain tabular structure as Markdown before generating embeddings. When dealing with complex structured documents such as policies containing multi-column tables, fixed-character chunking breaks rows and columns across separate chunks.
  • Exam Traps to Reject: Increasing top-k retrieves more chunks but fails to repair tables split during chunking. Reducing chunk size further fragments tabular data and worsens context fragmentation.
  • Core Concept: Embedding model task type configuration in Vertex AI text-embedding models
  • Scenario Trigger & Requirement: An asymmetric search scenario where short user queries search against long reference documents. The goal is to maximize semantic retrieval relevance by selecting the appropriate task type parameter during embedding generation with Vertex AI text-embedding models.
  • Winning Architecture & Implementation: Set the task_type parameter to RETRIEVAL_QUERY when embedding user queries and RETRIEVAL_DOCUMENT when embedding runbooks. Vertex AI text-embedding models support task types to optimize vector embeddings for specific search modalities. In asymmetric search, queries are typically short phrases while documents are comprehensive passages.
  • Exam Traps to Reject: Inverting the task types degrades search quality because query and document embeddings require distinct task representations. SEMANTIC_SIMILARITY is optimized for symmetric text pairs of similar length, not asymmetric document retrieval.
Takeaway 3: Enhancing Retrieval Precision with Semantic Cross-Encoder Reranking (vertex_ai:vector_search · vertex_ai:ranking_api · vertex_ai:rag)
  • Core Concept: Two-stage retrieval and semantic reranking using Vertex AI Ranking API
  • Scenario Trigger & Requirement: A common retrieval-augmented generation (RAG) challenge: high-similarity vector candidates often miss specific contextual nuances (like critical disclaimers) because bi-encoder embeddings compute representations independently.
  • Winning Architecture & Implementation: Add the Vertex AI Ranking API between vector retrieval and prompt construction to rescore the top candidates with a semantic ranker. Vertex AI Ranking API provides a semantic cross-encoder reranking service. In a two-stage retrieval pipeline, first-stage retrieval retrieves candidates efficiently through approximate nearest neighbors (ANN) with bi-encoders, while the second stage applies a cross-encoder model to accurately rescore query-document pairs.
  • Exam Traps to Reject: Switching distance metrics does not improve the semantic precision of first-stage vector search. Retraining and re-indexing requires excessive engineering overhead and violates the scenario constraints.
Takeaway 4: Mitigating Out-of-Vocabulary Code Lookup Failures with Hybrid Search (vertex_ai:search · vertex_ai:vector_search · vertex_ai:rag)
  • Core Concept: Hybrid search combining dense vector embeddings and sparse keyword matching (BM25)
  • Scenario Trigger & Requirement: A common failure mode in Retrieval-Augmented Generation (RAG) pipelines that rely solely on dense vector search: retrieving exact alphanumeric codes or part numbers (e.g., 'XR-9421-B'). Dense embeddings map semantic concepts well, but often map specific part numbers to general product categories or similar devices.
  • Winning Architecture & Implementation: Implement hybrid search in Vertex AI Search to combine dense semantic embeddings with sparse keyword matching. Hybrid search combines dense vector search (which captures semantic meaning and concepts) with sparse lexical search (such as BM25 keyword matching).
  • Exam Traps to Reject: Raising the similarity threshold drops irrelevant matches but fails to solve the underlying problem of matching exact part numbers. Fine-tuning embedding models is costly and does not reliably guarantee exact alphanumeric string retrieval.

Consolidated Golden Rules (Consideration 3.2a):

  • Fixed-character chunking destroys tabular and multi-column document structures.
  • Use layout-aware chunking or Document AI to convert tables to Markdown before embedding.
  • Preserving row-column relationships is essential to avoid numerical hallucinations in RAG pipelines.
  • Always configure task_type='RETRIEVAL_QUERY' for search input and task_type='RETRIEVAL_DOCUMENT' for corpus chunks during asymmetric vector retrieval.
  • Use SEMANTIC_SIMILARITY only for symmetric text-to-text comparisons of similar length.
  • Task-specific embeddings ensure higher cosine similarity and dot product precision between questions and answers.

Consideration 3.2b: Configuring agent permissions (e.g., agent identity)

When securing how custom agents access enterprise knowledge and tools:

  • Dedicated Agent Identity per Agent: Provision a distinct Agent Identity (managed Service Account) for every agent rather than sharing the default compute service account. Grant only the minimum required IAM roles (e.g., roles/storage.objectViewer on a single ingestion bucket, roles/run.invoker on a specific Cloud Run MCP tool).
  • End-User Identity Pass-Through vs. Agent Service Account:
  • Use the Agent's Service Account (Agent Identity) when accessing a shared, non-user-specific backend microservice or public knowledge base.
  • Use End-User OAuth 2.0 Identity Pass-Through / Token Exchange whenever the underlying data has per-user access controls (e.g., querying an employee's personal HR records, Google Drive files, or multi-tenant CRM rows).
Diagram showing how forwarding Doctor A's credentials results in access only to their assigned patient records.
Credential forwarding ensures the data store correctly filters sensitive records based on the specific identity provided.
Diagram illustrating the Storage Object Viewer role providing read-only access to grounding documents.
The Storage Object Viewer role provides exactly the read-only access needed for grounding documents.
Takeaway 1: End-User Identity Pass-Through vs. Service Account for Document Access (vertex_ai:agent_builder · vertex_ai:search · iam)
  • Core Concept: End-User OAuth Credential Forwarding vs. Ambient Agent Service Account
  • Scenario Trigger & Requirement: A healthcare application where access to sensitive patient records must follow strict, per-user access control lists (ACLs). The key problem is ensuring that search queries triggered by an AI agent only expose documents authorized for the specific calling doctor, rather than relying on a broadly privileged agent identity.
  • Winning Architecture & Implementation: Configure end-user credential forwarding with OAuth 2.0 token pass-through to query the data store with the identity of the authenticated doctor. Configuring end-user credential forwarding (OAuth 2.0 user token pass-through) allows Vertex AI Agent Builder to propagate the authenticated user identity down to the search data store.
  • Exam Traps to Reject: A shared service account has broad ambient permissions and cannot enforce individual doctor access controls. Embedding service account keys in prompts is insecure and violates identity best practices.
Takeaway 2: Least Privilege IAM Role Assignment for Grounded Cloud Storage Ingestion (vertex_ai:agents · storage:iam · iam:service_accounts)
  • Core Concept: Custom Agent Service Identity and Cloud Storage IAM Permissions
  • Scenario Trigger & Requirement: The scenario requires configuring identity and IAM permissions for a Vertex AI autonomous agent to read grounding data stored in Cloud Storage. Key considerations include: (1) identity management (user-managed vs. default), (2) access scope (bucket-level vs. project-level), and (3) role permissions (read-only vs. admin/write).
  • Winning Architecture & Implementation: Create a dedicated user-managed service account, attach it to the agent, and grant this service account the Storage Object Viewer (roles/storage.objectViewer) role on the bucket. Attaching a dedicated user-managed service account to the Vertex AI agent ensures granular identity isolation. Granting the Storage Object Viewer (roles/storage.objectViewer) role scoped directly to the target bucket satisfies the principle of least privilege because it provides only read access to objects without granting administrative or write permissions across the project.
  • Exam Traps to Reject: Storage Admin grants dangerous administrative rights and default service accounts lack workload isolation. Storage Object Creator provides write-only capabilities and prevents the agent from reading guidelines.
Takeaway 3: Enterprise Knowledge Grounding with Document-Level ACL Synchronization (vertex_ai:search · vertex_ai:agents · iam:identity_federation)
  • Core Concept: Vertex AI Search Access Control Lists (ACLs) and Third-Party Identity Mapping
  • Scenario Trigger & Requirement: The scenario requires an enterprise agent to respect source permissions (ACLs) from Google Workspace and third-party repositories so that employees only see search results they are authorized to view. The key determining detail is dynamically filtering search results based on the querying employee's identity.
  • Winning Architecture & Implementation: Configure identity federation with document-level access control on the Vertex AI Search data store, and pass the end-user identity token with query requests. Configuring identity federation and document-level access control lists (ACLs) on the Vertex AI Search data store allows the search service to inherit and evaluate permissions from the source system.
  • Exam Traps to Reject: Prompt-based filtering does not provide reliable data security or enforce strict access control. Splitting storage buckets and agents per team is unmanageable and does not enforce dynamic document-level ACLs.

Consolidated Golden Rules (Consideration 3.2b):

  • Use end-user credential pass-through (OAuth 2.0 forwarding) when search results must honor per-user document ACLs.
  • Use service account authentication only when the knowledge base contains shared, non-sensitive documents accessible to all users.
  • Never embed private keys or credentials in prompts or system instructions.
  • Security and access control must be enforced at the data retrieval layer, not through prompt instructions.
  • Always assign custom user-managed service accounts to autonomous agents for clear workload identity boundaries.
  • Apply the Storage Object Viewer role when grounding agents only require read access to Cloud Storage objects.

Consideration 3.2c: Using google cloud tools (e.g., agent registry, google cloud mcp servers) to configure prebuilt and custom capabilities (e.g., custom integration layers for managed databases, api integrations, and mcp server that connects agents to third-party saas tools and remote servers)

When integrating databases, internal APIs, and third-party SaaS platforms:

  • Google Cloud MCP Servers for Managed Databases (Cloud SQL, BigQuery, Firestore): Instead of giving an agent direct network credentials and allowing free-form LLM-generated SQL (which risks SQL injection and accidental table mutations), deploy a Google Cloud MCP Server on Cloud Run using the Cloud SQL Auth Proxy (with IAM database authentication) that exposes pre-defined, parameterized read-only SQL query tools.
  • MCP Resources vs. MCP Tools: In the Model Context Protocol specification:
  • Expose static or read-only contextual data (such as database schemas, architectural documentation, or configuration files) as MCP Resources (resources/read), which cannot trigger side effects.
  • Expose executable operations and queries as MCP Tools (tools/call).
  • Handling 30+ Tools Without Context Bloat: When an enterprise agent must potentially access dozens or hundreds of tools registered in Agent Registry, do not inject all 50 tool JSON schemas into the prompt on every turn. Use a semantic tool-retrieval step (or hierarchical router) to dynamically select and load only the 3–5 relevant tool schemas for the current user query.
IAM governing tool invocation in Agent Registry
Governance via IAM ensures that only authorized agents can invoke tools registered in the central catalog.
Diagram illustrating the flow of user input into an MCP server for intent understanding, sanitization, and SQL template building before database execution.
The MCP server facilitates advanced workflows like input sanitization and dynamic SQL generation required for complex database interactions.
Takeaway 1: Secure Private Cloud SQL Access via Cloud Run MCP Server (vertex_ai:agents · cloud_run · cloud_sql:postgres · vpc:serverless_vpc_access)
  • Core Concept: Deploying a custom Model Context Protocol (MCP) server to interface an agent with a private Cloud SQL instance without public exposure.
  • Scenario Trigger & Requirement: The scenario requires connecting a Vertex AI agent to an internal, private Cloud SQL for PostgreSQL instance using a Model Context Protocol (MCP) server. The critical constraint is that the database must remain entirely private without any public IP address exposure.
  • Winning Architecture & Implementation: Deploy the Model Context Protocol (MCP) server on Cloud Run with Direct VPC egress configured to reach the private Cloud SQL IP address. Deploying the Model Context Protocol (MCP) server on Cloud Run with Direct VPC egress or a Serverless VPC Access connector allows the server to communicate directly with private IP addresses inside your VPC network.
  • Exam Traps to Reject: Vertex AI agents require an intermediate tool interface or protocol server to execute database queries. This option introduces a public IP address on Cloud SQL, violating the security requirement.
Takeaway 2: Third-Party SaaS Integration via Remote MCP Server with OAuth Passthrough (vertex_ai:agents · iam:oauth · cloud_run)
  • Core Concept: Authenticating third-party SaaS tools like Jira and Salesforce through an MCP server while preserving individual caller identity.
  • Scenario Trigger & Requirement: Requires the recommended method to authenticate remote Model Context Protocol (MCP) tool integrations against third-party SaaS platforms while satisfying compliance requirements for end-user audit logging. The key requirement is attributing operations to individual human engineers rather than a shared service account.
  • Winning Architecture & Implementation: Configure OAuth 2.0 user delegation and propagate the authentication token of the end user from the agent runtime to the remote MCP server. Configuring OAuth 2.0 user delegation allows the agent framework and the remote MCP server to act on behalf of the authenticated human operator.
  • Exam Traps to Reject: Static administrator keys attribute actions to the key owner rather than validating individual user credentials. Logging in Cloud Logging does not fulfill compliance requirements for audit trails inside downstream SaaS systems.
Takeaway 3: Real-Time BigQuery Analytics via Prebuilt Tools vs Custom MCP Server (vertex_ai:agents · bigquery)
  • Core Concept: Selecting the optimal integration pattern between prebuilt data store tools and a custom MCP server for parameterized BigQuery execution.
  • Scenario Trigger & Requirement: The scenario requires executing real-time queries against BigQuery while applying custom input sanitization, parameter validation, and dynamic query generation logic. The key constraint is the need for an intermediate execution layer containing custom business logic.
  • Winning Architecture & Implementation: Deploy a custom Model Context Protocol (MCP) server that validates parameters and generates dynamic SQL queries before calling BigQuery. Deploying a custom Model Context Protocol (MCP) server provides a dedicated integration layer. This allows you to execute custom code, sanitize inputs, enforce business logic, and dynamically construct SQL queries before executing queries against BigQuery.
  • Exam Traps to Reject: BigQuery cannot process raw natural language prompts directly without SQL translation and validation. Built-in data store connectors do not support custom pre-execution parameter validation and dynamic SQL manipulation.
Takeaway 4: Centralized Tool Governance with Agent Registry (vertex_ai:agents · iam)
  • Core Concept: Using Agent Registry to discover, catalog, version, and enforce RBAC on shared agent capabilities across multiple enterprise departments.
  • Scenario Trigger & Requirement: Decentralized development teams creating redundant, unversioned, and unmanaged connectors to core enterprise systems. The primary requirement is to provide a single, secure catalog for discovering, versioning, and managing access to reusable agent capabilities across Google Cloud projects.
  • Winning Architecture & Implementation: Publish the standardized tool definitions to Agent Registry and apply Identity and Access Management (IAM) roles to control discovery and invocation across projects. Publishing tools to Agent Registry directly addresses tool duplication and centralized governance. Agent Registry serves as a centralized catalog where developers can register, discover, version, and manage access to tools, OpenAPI extensions, and Model Context Protocol (MCP) servers across multiple Google Cloud projects.
  • Exam Traps to Reject: Cloud Storage stores raw specification files but lacks native agent tool discovery, runtime integration, and granular capability lifecycle management. Artifact Registry manages software packages and container images rather than AI agent tools and capability metadata.

Consolidated Golden Rules (Consideration 3.2c):

  • Model Context Protocol (MCP) servers act as standard integration bridges between AI agents and enterprise backends.
  • To reach private Google Cloud resources from serverless runtimes like Cloud Run, enable Direct VPC egress.
  • Never assign public IP addresses when private VPC communication is sufficient.
  • Remote MCP servers connecting to SaaS tools should avoid shared service accounts when individual auditability is required.
  • OAuth 2.0 user delegation allows agents and MCP servers to act on behalf of the end user.
  • Propagating user identity tokens downstream guarantees that external SaaS audit logs accurately reflect the human initiator.

Multi-Constraint Production Architecture Scenarios (Subsection 3.2)

Diagram showing one step with three simultaneous calls to different data systems.
Parallel tool calling enables the model to bridge multiple systems in one simultaneous step.
Production Scenario & Hard Constraints
Winning Google Cloud Architecture
Why Look-Alike Alternatives Fail
Standard mechanism to define external REST API interfaces for reliable tool calling: The requirement to connect an AI agent to an external REST API for real-time data retrieval. The key challenge is enabling the large language model to discover API capabilities and supply accurate invocation arguments. Standard tool-calling paradigms require structured API definitions such as OpenAPI schemas.
Define the tool schema with clear descriptions, parameter types, and OpenAPI specifications. Defining clear tool schemas and OpenAPI specifications allows the model to understand API capabilities and provide accurate arguments.
Parsing unstructured text with regular expressions is brittle compared to native function calling. Hallucinating responses produces inaccurate information and does not connect to the live external API.
Standard protocol designed for connecting AI agents to enterprise microservices without: The need for an enterprise agent to communicate with disparate microservices through an open, standardized protocol. Key requirements include support for tools, resources, and prompt templates while eliminating custom adapter development for each service.
Implement Model Context Protocol (MCP) servers for the microservices and connect them to an MCP client. Model Context Protocol (MCP) provides a standardized, open protocol for exposing tools, prompts, and resources between models and external systems.
Static CSV exports offer only stale data and do not provide an interactive protocol for tool calling. Writing webhook parsers within prompt templates increases maintenance overhead and violates separation of concerns.
Standard authentication configuration in Vertex AI Extensions that propagates individual: The question specifies an integration between an AI agent and an enterprise ERP system through Vertex AI Extensions. The primary constraint is that the ERP system requires OAuth 2.0 user-delegated authorization.
Configure Vertex AI Extensions with user OAuth 2.0 credential forwarding. Configure OAuth 2.0 credential forwarding so that the extension passes the end-user bearer token to the ERP system, ensuring authorization matches user permissions.
Hardcoding secrets in prompt instructions exposes credentials to prompt injection and violates per-user authorization requirements. A service account with unrestricted read access bypasses user-level delegation and exposes all ERP data to any user.
Recommended architectural design pattern to maintain high tool selection accuracy: A common challenge in LLM-based agent design: tool distraction or tool degradation. Providing dozens of tool definitions concurrently increases token overhead, confuses the attention mechanism, and increases the error rate in tool selection and argument generation.
Implement dynamic tool filtering or route requests to specialized sub-agents with smaller tool sets. Filtering tools dynamically or routing requests to domain-specific sub-agents reduces schema distraction and restores tool selection accuracy.
Random sampling omits required tools and disrupts conversational task fulfillment. A single generic tool removes structured schema enforcement and forces error-prone parsing on the backend.
OpenAPI specifications integrate directly into agent frameworks to generate tool: An existing OpenAPI specification for an internal service and asks for the standard, automated method to expose these operations as tools within the Agent Development Kit (ADK) or Vertex AI agent ecosystem without rewriting interface code.
Import the OpenAPI specification directly into ADK or Vertex AI Extensions to auto-generate tool definitions. ADK and Vertex AI Extensions automatically parse OpenAPI specifications into tool definitions without manual coding.
Manual re-implementation requires significant development effort and contradicts the goal of automated conversion. Vector search retrieves similar text instead of generating executable API tool definitions.
Recommended architecture for exposing relational database queries to an AI agent safely: The core objective in this scenario is enabling an AI agent to read sales analytics data from Cloud SQL while strictly enforcing read-only access and operational safety. Key considerations include: * Constraint: The agent must not possess write access or execute arbitrary modification queries.
Provide the agent with dedicated parameterized tool functions that execute read-only queries. Dedicated parameterized tools constrain the model to explicit read-only operations and prevent SQL injection or unintentional updates.
Exposing arbitrary SQL generation on an unauthenticated public IP address introduces critical security vulnerabilities. Prompt instructions do not guarantee security; administrator credentials violate the principle of least privilege.
Recommended pattern to ground an AI analytics agent with schema metadata and semantic: The scenario requires an analytics agent to query petabytes of structured sales data in BigQuery accurately without hallucinating non-existent column names or generating invalid SQL queries.
Deploy the Data Agent Kit with BigQuery schema metadata, few-shot SQL examples, and semantic catalog definitions. Providing schema metadata, few-shot SQL demonstrations, and semantic definitions grounds the model and prevents hallucinated column names.
Converting petabytes of structured data into embeddings is cost-prohibitive and inefficient for structured SQL aggregations. BigQuery is fully managed and serverless, meaning compute clusters do not accept direct shell script execution.
Managed Google Cloud service designed to execute low-latency approximate nearest: Three critical technical constraints: Scale: Millions of embedding vectors derived from a corpus of technical manuals. Performance requirement: Single-digit millisecond latency (sub-10 ms). * Operational requirement: Real-time corpus updates combined with semantic similarity searches.
Deploy Vertex AI Vector Search with an index endpoint optimized for approximate nearest neighbors. Vertex AI Vector Search is designed specifically for single-digit millisecond approximate nearest neighbor searches across millions of embedding vectors.
Sequential scans of vectors stored in Cloud Storage introduce high latency and cannot satisfy millisecond-scale retrieval requirements. Session memory cannot store millions of high-dimensional vectors and lacks vector search indexing mechanisms.
Proper integration pattern to retrieve rapidly changing, deterministic enterprise data: Data that fluctuates every minute (product pricing and stock availability) within an e-commerce agent. The key design challenge is determining the appropriate architecture pattern: Vector RAG versus Function Calling (tool execution).
Use direct real-time tool calling against the inventory database rather than static vector index embeddings. Real-time tool calling queries transactional databases directly, providing accurate and up-to-the-minute data that vector embeddings cannot maintain efficiently.
Estimating prices produces hallucinations and inaccurate data, which is unacceptable for transactional commerce. Batch re-indexing every thirty seconds is computationally expensive, impractical, and introduces latency bottlenecks.
Prompt engineering and decoding configuration techniques that minimize model: A medical research agent struggling with factual accuracy and domain-specific terminology. Hallucination in retrieval-augmented generation (RAG) occurs when a model invents unsupported claims or extrapolates beyond provided reference passages.
Configure strict grounding thresholds, lower the model temperature, and require citation verification in the prompt. Decreasing temperature, enforcing strict grounding thresholds, and requiring citations minimize hallucinations by keeping the model deterministic and anchored to source text.
Increasing top-k broadens token selection and fosters creativity, directly aggravating hallucination problems. Removing grounding documents deprives the agent of factual references and intensifies hallucination rates.
Recommended pattern to enable a conversational agent to retrieve and correlate both: The business problem asks for correlation between two fundamentally different types of data: structured relational data in Cloud Spanner (order IDs, purchase dates, amounts) and unstructured natural language text in Cloud Storage (customer support conversations).
Implement a multi-tool agent with the Data Agent Kit that combines Cloud Spanner SQL tools with Vertex AI Search. A multi-tool agent combines structured SQL retrieval from Cloud Spanner with semantic document retrieval across Cloud Storage support transcripts through Vertex AI Search.
Converting structured transactional records into raw text destroys schema advantages and creates unnecessary data synchronization pipelines. Manual preprocessing creates massive operational overhead and fails to support real-time conversational agents.
Recommended chunking strategy for complex technical PDF documents containing tabular: Long technical PDF documents containing hierarchical sections and tables. When preparing data for Vertex AI Vector Search, text segmentation (chunking) directly determines the quality of semantic search.
Use layout-aware chunking that preserves document structure, table formatting, and section headers. Layout-aware chunking preserves table integrity, structural hierarchy, and semantic context necessary for effective vector search retrieval.
Fixed 50-character chunks cut across words and discard meaningful semantic context. Embedding whole long documents exceeds model input token limits and dilutes specific factual information.
Deploy an MCP server with native Google Cloud IAM authentication using Cloud Run: The scenario requires securing a Model Context Protocol (MCP) server deployed in Google Cloud by enforcing incoming authentication through Google Cloud Identity and Access Management (IAM). A secure solution requires a managed service that natively validates Google identity tokens, preventing unauthorized clients from invoking MCP tools.
Deploy the MCP server on Cloud Run with IAM authentication enforced and configure the MCP client with OIDC tokens. Cloud Run enforces native IAM authentication by validating OpenID Connect (OIDC) identity tokens passed by authorized clients.
Permitting unauthenticated access leaves the server completely open to unauthorized callers and fails to enforce IAM. Hardcoded keys in URL parameters expose credentials in access logs and do not integrate with Google Cloud IAM.
Best practices for designing tool schemas and wrapping third-party APIs to optimize: A common challenge in building enterprise AI agents: integrating legacy or broad enterprise APIs that contain excessive payload bloat and complex schemas. Large language models (LLMs) perform best when tool schemas are lean, precise, and contain clear parameter descriptions.
Create a simplified ADK tool wrapper that exposes only the essential input and output fields needed by the agent. Wrapping a complex API with a simplified tool contract isolates the agent from extraneous parameters and maximizes tool-calling reliability.
Dumping complete documentation into the system prompt saturates context limits and degrades execution quality. Models require well-defined schemas to invoke external APIs deterministically without parameter guessing.
Proper architectural design pattern for integrating long-running backend tools into: An architectural challenge: interacting with a slow backend system (a banking mainframe taking up to 45 seconds) from a conversational or task-oriented agent. The core technical consideration is handling high-latency operations without encountering HTTP connection timeouts, blocking client execution, or degrading the user experience.
Implement asynchronous tool calling with background polling or callback notifications in ADK. Asynchronous invocation with polling or callbacks prevents network timeouts and maintains agent responsiveness during long-running tasks.
Blocking a synchronous HTTP connection for 45 seconds causes timeout errors and thread exhaustion. Terminating after two seconds prevents the mainframe operation from ever completing successfully.
Standard architectural pattern for improving document retrieval quality when initial: The scenario specifies that an agent relies on Vertex AI Search for grounding, but the retrieved snippets are irrelevant because the initial user queries are vague or poorly phrased.
Implement a query rewriting step before the retrieval call to expand and clarify user search terms. Query rewriting leverages a prompt or model to clarify and expand vague user inputs into precise search terms before retrieval.
Retrieving one thousand chunks increases latency, cost, and noise without fixing the poorly phrased query. Disabling grounding prevents the model from accessing enterprise knowledge and leads to hallucinations.
Recommended architecture within the Data Agent Kit to ground SQL generation with schema: Three critical requirements for an analytical data agent built with the Data Agent Kit: generating complex SQL queries against BigQuery, validating generated SQL against table schemas, and automatically repairing syntax errors when query execution fails.
Use the Data Agent Kit built-in Text-to-SQL agent workflow with automated schema inspection and execution feedback loops. The built-in Text-to-SQL agent workflow provides schema inspection and automated query repair loops out of the box.
Directly executing unvalidated SQL risks syntax failures, runtime errors, and performance degradation. Excluding schema context causes hallucinated columns and fails to provide validation or error correction.
Managed Google Cloud architecture pattern that blends lexical BM25 matching and semantic: The question specifies two critical criteria for building an effective context-retrieval pipeline for an AI agent: millions of technical articles and the specific need to combine traditional keyword matching (BM25) with semantic vector search for optimal accuracy.
Configure hybrid search with semantic reranking in Vertex AI Search. Hybrid search combines dense semantic vector matching with sparse keyword matching (BM25), and semantic reranking refines results for optimal retrieval precision.
An unindexed database table requires slow full table scans and does not provide out-of-the-box hybrid retrieval or reranking. Scanning raw text files lacks vector capabilities, fails to scale across millions of articles, and introduces massive latency.
Foundation model capability that enables concurrent invocation requests across multiple: The scenario requires an automated agent to request three different external resources (weather API, internal database, and CRM) within a single reasoning step.
Parallel tool calling (multi-tool calling) support in Vertex AI Gemini models. Parallel tool calling enables the model to request multiple tool executions concurrently in a single response turn.
Basic text completion cannot interact with external runtime tools or retrieve live data. Prompt chaining executes tasks sequentially across steps and lacks native multi-function calling definitions.
A hybrid retrieval architecture for an AI agent that routes sub-queries to BigQuery: The scenario requires an enterprise conversational agent to query two distinct modalities of data: structured customer profile data located in BigQuery and unstructured customer support tickets indexed in Vertex AI Search.
Build a unified agent with the Data Agent Kit that routes sub-queries to BigQuery tools and Vertex AI Search tools. A unified agent routes sub-queries to dedicated tools for structured BigQuery data and unstructured Vertex AI Search data.
Exporting structured data to text files degrades schema relationships, increases latency, and impedes precise analytical querying. Relational columns without indexing do not provide semantic search capabilities and introduce severe performance bottlenecks.
MCP primitive to provide read-only data without enabling action execution: Two requirements: First, the agent must obtain read-only access to architectural documentation. Second, the agent must not obtain permission to execute commands. The solution must follow the primitive design guidelines of the Model Context Protocol (MCP).
Expose the documentation as MCP Resources rather than exposing MCP Tools. MCP Resources provide read-only data without execution capabilities, whereas Tools invoke actionable operations.
Exposing administrator credentials grants excessive privileges and creates security vulnerabilities. An MCP Tool that runs arbitrary shell scripts grants command execution capabilities, violating the read-only requirement.

Head-to-Head Architectural Trade-Off Clinic (Subsection 3.2)

Knowledge Access Scenario
Optimal Google Cloud Architecture
Why the Alternative Fails
Search 5,000,000 technical support articles for both conceptual problems and exact error codes (ERR_4091)
Vector Search 1.0 Hybrid Search (Dense embeddings + Sparse BM25 keyword index) + Cross-Encoder Reranker
Pure dense vector search misses exact alphanumeric codes; long-context prompting cannot fit 5M articles.
Customer asks an e-commerce agent: "How many units of SKU-882 are in stock right now?"
Direct Real-Time MCP Tool Call to the inventory database / API
RAG / Vector Search (re-embedding transactional inventory every second is expensive and serves stale counts).
Agent must query both structured sales tables in BigQuery AND unstructured customer feedback PDFs in Cloud Storage
Multi-Tool / Hybrid Agent combining Data Agent Kit (or BigQuery MCP Server) for SQL analytics + RAG Engine / Vector Search for PDFs
Dumping SQL tables into a vector index (breaks aggregations like SUM/AVG) or running SQL over raw PDFs.
Agent has access to 45 backend tools; tool selection accuracy drops and input tokens spike
Dynamic Semantic Tool Filtering / Retrieval (fetch only the top-K relevant tool definitions from Agent Registry per turn)
Passing all 45 tool schemas in every prompt turn or hardcoding regex if/else statements.
Expose repository markdown documentation to an agent over MCP with zero risk of data modification
Expose as read-only MCP Resources
Expose as executable MCP Tools with shell/write capabilities.

Rapid Pattern-Trigger Cheat Sheet (Subsection 3.2)

If the Exam Scenario Mentions...
Choose This Architecture / Configuration
Reject This Common Distractor Trap
"RAG pipeline splits markdown/PDF tables across chunks, causing wrong financial answers"
Implement Layout-Aware Chunking (Document AI Layout Parser) that keeps tables and headers intact
Increasing fixed character chunk overlap or raising LLM temperature
"Vector Search fails to match exact part numbers, SKUs, or function names"
Enable Hybrid Search (combining dense semantic vectors with sparse BM25 keyword matching)
Increasing embedding vector dimensions or fine-tuning the foundation model
"Top-50 retrieved vector chunks contain relevant info at rank 18, but top-5 passed to LLM miss it"
Add a Semantic Cross-Encoder Reranking stage before passing chunks to the LLM
Switching from cosine similarity to Euclidean distance
"Prevent SQL injection and unauthorized table writes when an agent queries Cloud SQL"
Expose parameterized read-only query templates via a Google Cloud MCP Server with least-privilege IAM
Giving the LLM direct database credentials to run raw generated SQL strings
"Legacy SOAP/XML service or massive 50-field nested JSON API confuses the LLM"
Build a simplified ADK Tool / MCP Adapter that exposes a clean, flat JSON schema and translates internally
Passing raw WSDL/SOAP XML envelopes directly into the LLM prompt

Curated Official Google Cloud Documentation (Subsection 3.2)


Book TOC · Previous · Chapter 4 of 8 · Next

AwesomeGCP.com Learning

The approach taken is a question-led learning approach: you explore realistic project scenarios where you need to make decisions or take actions to achieve business goals within specific constraints. Instead of passive learning, you are challenged to think and work through the options to master the Professional Agentic Architect (PAA) certification!

Practice PAA Questions