Professional Agentic Architect sample questions with answers

Question 1, Section 3, 3.1 Designing and building agentic workflows in code

An insurance company wants its claims-intake agent, built with Agent Development Kit (ADK), to use an open-weight Llama model for summarizing adjuster notes. Traffic is unpredictable and bursty, and it spikes after storms and is near zero otherwise. The team is three application developers with no MLOps or GPU capacity-planning experience, and leadership wants the agent in production within two weeks. The standard instruction-tuned model meets quality requirements. Which approach meets these requirements with the LEAST operational overhead?

1. Deploy the model from Model Garden to a dedicated Agent Platform endpoint on NVIDIA L4 GPUs and pass the endpoint resource name to the LlmAgent model parameter.
2. Call the model through Model as a Service (MaaS) on Agent Platform by using the LiteLlm wrapper as the LlmAgent model.
3. Serve the model on a GKE Autopilot cluster with vLLM and point the agent at the OpenAI-compatible endpoint through LiteLlm.
4. Build a custom vLLM container image, deploy it to an Agent Platform endpoint, and add autoscaling rules for the storm season.

Show the answer and explanation

Answer: B. MaaS serves open models through serverless managed APIs, so Google handles accelerator provisioning, scaling, and maintenance, and pay-as-you-go pricing suits bursty, unpredictable traffic. Because a standard, non-customized model is sufficient, there is no reason to self-deploy. ADK reaches MaaS open models through the LiteLlm model connector.

Why the other options are wrong:

• A. A dedicated self-deployed endpoint adds capacity planning and pays for GPUs during idle periods, which suits predictable high-volume traffic rather than bursty traffic.
• C. Running vLLM on GKE gives granular control but requires Kubernetes and MLOps skills the team does not have.
• D. A custom vLLM container is meant for custom serving logic and adds the most image and scaling maintenance of all the options.

Official reference: docs.cloud.google.com/vertex-ai/generative-ai/docs/open-models/choose-serving-option

Question 2, Section 4, 4.1 Evaluating agents in development and in production

A telecom company is building a plan-change agent with Agent Development Kit (ADK). The agent needs a customer's account number and the target plan before it calls its change_plan tool, but depending on the conversation it may ask for them together or one at a time. The team has no production traffic yet and found that scripted multi-turn test cases break whenever the agent asks its questions in a different order. They want multi-turn test cases that stay valid regardless of question order and that also reflect less technical customers. What should you do?

1. Record several sessions in the adk web Eval tab, save each as an eval case, and set tool_trajectory_avg_score with the EXACT match type.
2. Write .test.json files that list every expected user turn and the expected change_plan arguments, and run them with pytest in CI.
3. Add ConversationScenario eval cases with a starting prompt, conversation plan, and NOVICE persona, scored with reference-free criteria.
4. Wait for launch, sample production logs into a dataset, and score the sampled sessions with response_match_score against the logged replies.

Show the answer and explanation

Answer: C. ADK user simulation replaces fixed user prompts with a ConversationScenario: a fixed starting prompt plus a conversation plan that an LLM uses to generate each next user turn, so the test adapts when the agent asks for values in a different order. The pre-built NOVICE persona models a goal-oriented, conversational user who waits to be asked for details. Because scenarios have no expected responses, they must be paired with criteria that support user simulation, such as rubric-based or multi_turn_* criteria.

Why the other options are wrong:

• A. Recorded sessions replay fixed user turns, so they still break when the agent changes its question order, and EXACT trajectory matching makes each case even more brittle.
• B. Fully scripted turns are exactly the brittle approach that fails when the agent changes its question order.
• D. There is no production traffic yet, and ROUGE-1 matching against logged replies does not test how the conversation adapts.

Official reference: adk.dev/evaluate/user-sim

Question 3, Section 2, 2.1 Using coding agents effectively

A data engineering team uses the Antigravity CLI to write BigQuery transformations. They want the agent to inspect live dataset schemas through the Google Cloud remote BigQuery MCP server. Security policy forbids storing long-lived credentials, such as API keys or service account keys, in any configuration file, and the MCP configuration must be shared with every engineer through the repository. Every engineer already has Application Default Credentials configured with gcloud and holds the required IAM roles. What should you do?

1. Add an entry to ~/.gemini/config/mcp_config.json on each laptop that sets serverUrl to the BigQuery MCP endpoint and passes a token minted from a service account key in the Authorization header.
2. Commit <workspace>/.agents/mcp_config.json with an mcpServers entry whose serverUrl is the BigQuery MCP endpoint and whose authProviderType is "google_credentials".
3. Commit <workspace>/.agents/mcp_config.json with an entry that sets httpUrl to the BigQuery MCP endpoint and uses the HTTP+SSE transport.
4. Commit a stdio MCP proxy configuration that uses command to launch a local bridge process and passes the path of a downloaded service account JSON key through env.

Show the answer and explanation

Answer: B. The workspace file <workspace>/.agents/mcp_config.json is loaded only for that workspace and can be committed, which satisfies the sharing requirement. Setting authProviderType to "google_credentials" makes Antigravity attach the engineer's own Application Default Credentials, so no long-lived secret is written into the file. Remote MCP servers in Antigravity are configured with serverUrl over Streamable HTTP.

Why the other options are wrong:

• A. The global file is per-laptop and not shared through the repository, and a token derived from a service account key violates the no-long-lived-credentials policy.
• C. Antigravity does not support the legacy HTTP+SSE transport or the httpUrl field for remote MCP servers.
• D. Referencing a downloaded service account key is exactly the long-lived credential the policy forbids, and the local proxy adds unnecessary moving parts.

Official reference: antigravity.google/docs/mcp

Question 4, Section 5, 5.1 Configuring agent security and governance

A software company runs an ADK engineering assistant on Agent Runtime with Agent Identity enabled. Developers ask it to update their own Jira tickets, and Jira must record every change under the requesting developer's account. Security policy forbids storing user refresh tokens in application databases and requires that user consent can be reviewed and revoked centrally. The team also wants to avoid writing custom OAuth callback and token-refresh code. What should you do?

1. Create a 2-legged OAuth auth provider in Agent Identity auth manager with a Jira client ID and secret, and grant the agent identity access to it.
2. Create a 3-legged OAuth auth provider in Agent Identity auth manager, grant the agent identity Agent Identity User on it, and use it in the ADK tool.
3. Build a Cloud Run callback service that completes the Jira OAuth code exchange and stores each developer's refresh token in Firestore encrypted with CMEK.
4. Store a Jira API key for a shared integration user in Secret Manager and let the agent read it at startup through its agent identity.

Show the answer and explanation

Answer: B. Acting on behalf of a specific user is user-delegated authority, which Agent Identity maps to a 3-legged OAuth auth provider in auth manager. Auth manager stores the resulting user tokens in a Google-managed vault, automates sign-in, consent, code exchange and refresh, and provides visibility into and revocation of user-delegated access. The agent's SPIFFE identity needs the Agent Identity User role on the auth provider, and ADK injects the token into the tool call.

Why the other options are wrong:

• A. 2-legged OAuth uses the agent's own authority without user consent, so changes would not be attributed to the individual developer.
• C. This works functionally but stores refresh tokens in an application database and requires custom OAuth code, violating both constraints.
• D. A shared integration user loses per-developer attribution, and a static API key is not a user-delegated credential.

Official reference: docs.cloud.google.com/iam/docs/auth-with-3lo-v2

Question 5, Section 1, 1.1 Configuring agentic workflows and behavior using low-code tools

An insurer's Dialogflow CX claims flow, now reused from CX Agent Studio as a flow-based agent, has 14 pages that collect incident details. Product owners want callers to be able to say "cancel my claim" on any page of the flow and be taken to the flow's Cancel Claim page. The team wants a single place to maintain this behavior and does not want to edit every page whenever the flow changes. What should you do?

1. Add a cancel_claim intent route, targeting the Cancel Claim page, to the flow start page as a flow-level route.
2. Add a condition-only route to the flow start page that checks a cancel_requested session parameter and transitions to the Cancel Claim page.
3. Add an identical cancel_claim intent route, targeting the Cancel Claim page, to each of the 14 pages so every page handles it explicitly.
4. Create an agent-level route group containing the cancel_claim intent route that targets the Cancel Claim page, and reference it from the flow.

Show the answer and explanation

Answer: A. Routes applied to a flow are added on the flow start page, and flow-level routes that have an intent requirement stay in scope no matter which page of the flow is current. That gives one place to maintain the cancel behavior for all 14 pages, and the transition target can be any page in the active flow.

Why the other options are wrong:

• B. Flow-level routes that have only a condition requirement are in scope only while the current page is the flow start page, so this route would not fire on the other 13 pages.
• C. Copying the route onto every page works, but it repeats the work on 14 pages and breaks the single-place maintenance requirement.
• D. Agent-level route groups do not allow routes whose transition target is a non-symbolic page, so a route that targets the Cancel Claim page cannot go in one.

Official reference: docs.cloud.google.com/dialogflow/cx/docs/concept/handler

Question 6, Section 3, 3.1 Designing and building agentic workflows in code

A legal-tech company has standardized on Anthropic Claude for contract analysis because of internal benchmark results. It is now building an ADK agent that will run on Google Cloud. The security team forbids storing third-party API keys in application configuration and requires that all model calls be authorized with Google Cloud IAM through Application Default Credentials and billed to the Google Cloud account. What should the developer do?

1. Pass the Claude on Agent Platform model string to LlmAgent, set GOOGLE_GENAI_USE_ENTERPRISE=TRUE, and install anthropic[vertex].
2. Wrap Anthropic's public API with the LiteLlm connector and store the Anthropic API key in the project's .env file, which is excluded from Git.
3. Download the Claude weights from Model Garden and self-deploy them to a dedicated GPU endpoint that ADK calls by its endpoint resource name.
4. Replace Claude with a Gemma model that is fine-tuned to mimic Claude's contract-analysis outputs.

Show the answer and explanation

Answer: A. Anthropic makes Claude available directly through Agent Platform as a partner model. ADK's registry routes Claude model strings to its Claude wrapper class, and the setup uses ADC with GOOGLE_GENAI_USE_ENTERPRISE=TRUE and the anthropic[vertex] library. As a result, calls are authorized with IAM and billed through Google Cloud without an Anthropic API key.

Why the other options are wrong:

• B. Calling Anthropic's public API requires an Anthropic API key in application configuration, which the security team forbids even if the file is not committed, and usage is not billed through Google Cloud.
• C. Claude is a proprietary partner model that is consumed as a managed API, so its weights are not available for self-deployment.
• D. Replacing the model ignores the company's benchmark-driven standard and adds tuning work that no requirement asks for.

Official reference: adk.dev/agents/models/agent-platform

Question 7, Section 4, 4.1 Evaluating agents in development and in production

A travel company has built a booking agent, and an immutable version of it is already registered in Agent Registry. The agent has not launched, so no production traces exist. The QA analysts who own test design work only in the Google Cloud console and do not write Python or use command-line tools. They need a starting set of multi-turn test cases in which users begin booking a flight and then change their minds, and they want to review and edit the cases before running them. What should they do?

1. Ask a developer to run agents-cli eval dataset synthesize locally with an instruction, and then share the generated trace files with the QA team.
2. On the Agent Platform Evaluation page, select New evaluation > Simulate sessions, enter a generation instruction, and edit the generated table.
3. Create an online monitor that evaluates the agent's traces, and copy the lowest-scoring sessions into a dataset once enough traffic arrives.
4. Write ConversationScenario JSON files by hand, and add them with adk eval_set add_eval_case using a session input file for the agent.

Show the answer and explanation

Answer: B. Agent Platform agent evaluation can generate scenarios in the console: New evaluation, Simulate sessions, a generation instruction such as a user who changes their mind, and an editable table of generated cases. This requires an agent version in Agent Registry, which already exists, and needs no code, so it fits a console-only QA team.

Why the other options are wrong:

• A. The CLI route depends on a developer and a local ADK Python project, which the console-only QA team cannot run themselves.
• C. Online monitors score production traces, and the agent has no production traffic yet.
• D. Hand-writing JSON and running the ADK CLI requires the coding and command-line work that the analysts cannot do.

Official reference: docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-simulated

Question 8, Section 2, 2.1 Using coding agents effectively

Your team uses both the Antigravity App and the Antigravity CLI. You wrote step-by-step instructions and a helper script that validates Cloud Run service YAML before a deployment. Every engineer who clones the repository should get this capability without extra setup. The agent should apply it only when a task involves Cloud Run deployments, and the full instructions should not consume context during unrelated tasks. What should you do?

1. Commit .agents/skills/cloud-run-validate/SKILL.md with a precise description of when to use it, and put the script in a scripts/ subfolder.
2. Save the skill in ~/.gemini/config/skills/cloud-run-validate/ on your workstation, which both the App and the CLI read, and share the folder with the team.
3. Add the full step-by-step instructions and the script contents to an AGENTS.md file at the repository root so that every session can follow them.
4. Wrap the script in a local stdio MCP server, register it in each engineer's global ~/.gemini/config/mcp_config.json, and describe the workflow in the tool description.

Show the answer and explanation

Answer: A. Workspace skills in <workspace-root>/.agents/skills/ are committed to version control and are read by both the Antigravity App and CLI. Skills use progressive disclosure: the agent sees only the name and the required description on each turn and reads the full SKILL.md when the task matches, so a precise description keeps unrelated tasks lean. Bundling the script in scripts/ lets the agent run it as a black box.

Why the other options are wrong:

• B. The global skills folder is shared by the App and the CLI but only on one workstation, so it is not distributed through the repository and requires manual setup by each engineer.
• C. AGENTS.md is always active and injected into every turn, and rules are intended for constraints rather than multi-step workflows.
• D. A per-engineer global MCP configuration is not shared through the repository and adds a server process just to run a validation script.

Official reference: antigravity.google/docs/skills

Question 9, Section 5, 5.1 Configuring agent security and governance

A bank runs five Agent Runtime agents under one shared service account whose JSON key is mounted in a sidecar. An audit found two issues: a developer impersonated the service account to run ad hoc BigQuery queries, and an access token copied from logs was replayed from a laptop. The bank plans to move each agent to Agent Identity. Which two properties of Agent Identity directly address these findings? (Choose two.)

1. Agent identities rotate their JSON keys every 24 hours, so a leaked key expires before it can be reused from another machine.
2. Agent identities are shared by all agents in a project by default, so one IAM binding covers the fleet and the sidecar can be removed.
3. Agent identities can't be impersonated, and developers can't generate long-lived service account keys for them.
4. Agent identities store their Google Cloud access tokens in auth manager, so tokens are never written to application logs.
5. Tokens are bound to each agent's X.509 certificate, and Context-Aware Access enforces mTLS and DPoP so they can't be replayed.

Show the answer and explanation

Answer: C and E. Unlike service accounts, agent identities can't be impersonated and don't allow long-lived service account keys, which closes the impersonation finding. Access tokens are cryptographically bound to the agent's X.509 certificate, and the default Google-managed Context-Aware Access policy enforces mTLS and DPoP binding so tokens can't be replayed outside the trusted runtime, which closes the replay finding.

Why the other options are wrong:

• A. Agent identities don't use JSON keys at all; they use auto-provisioned X.509 certificates that are valid for 24 hours.
• B. Agent identities are per-agent and not shared by multiple workloads by default, which is the opposite of this statement.
• D. Auth manager vaults third-party credentials such as API keys and OAuth tokens; replay protection for Google Cloud tokens comes from certificate binding.

Official reference: docs.cloud.google.com/iam/docs/agent-identity-overview

Question 10, Section 1, 1.1 Configuring agentic workflows and behavior using low-code tools

A telecom's CX Agent Studio application has a root agent and a Payments sub-agent. Security requires that the conversation must never be transferred to Payments until a verification tool has set the boolean variable is_verified to true. The rule must be enforced deterministically, and the business analysts who maintain the agent do not write Python. Instruction-only guidance was already tried and occasionally failed in testing. What should you configure?

1. Add a sentence to the root agent's instructions stating that it must never call {@AGENT: Payments} unless the {is_verified} variable is true, and repeat it in global instructions.
2. Write a before_agent_callback on the Payments agent that returns a refusal message whenever is_verified is false.
3. Create a handoff rule that blocks the transfer by using the advanced code option with a should_trigger_transfer_callback function.
4. Create a handoff rule from the root agent to Payments that blocks the transfer until the variable is_verified equals true.

Show the answer and explanation

Answer: D. Handoff rules control transfers between parent and child agents deterministically, and they can either force a transfer or block it until a condition is met. A block rule is defined with variable conditions in the UI, and boolean variables are supported, so analysts can maintain it without code.

Why the other options are wrong:

• A. Instructions give similar control, but it is not deterministic, which is the failure the team already saw.
• B. A callback can enforce this, but it needs Python code, which the maintainers do not write.
• C. Rules that block handoffs can only be defined with variables, not with the advanced code option.

Official reference: docs.cloud.google.com/gemini-enterprise-cx/cx-agent-studio/handoff