Prepare and test your skills
Prepare and test your skills
Integrate AI-assisted tooling and contextual protocols means connecting an integrated development environment (IDE) to AI coding help and to live Google Cloud context so suggestions match the real project. This combination uses Cloud Code (opens in a new tab) for IDE integration, Gemini Code Assist Standard and Enterprise for in-editor help, Antigravity for agent-based work, and a Model Context Protocol (MCP) server for official documentation context. Cloud Code (opens in a new tab) integrates with the Google Cloud software development kit (SDK) (opens in a new tab) to provide unified authentication, so the IDE, cloud project, and AI assistant share the same identity and project selection.
AI-powered coding assistance in the IDE brings Google Kubernetes Engine, Cloud Run, and other Google Cloud services directly into the editor through Cloud Code. Cloud Code works in Visual Studio Code, IntelliJ IDEA and other supported JetBrains IDEs, and Cloud Shell Editor, and it supports Go, Java, Node.js, Python, and .NET Core. Developers can build, run, deploy, and monitor without leaving the IDE, while Gemini Code Assist Standard and Enterprise acts as the AI collaborator that generates code, fixes problems, and provides inline suggestions while coding.
Gemini Code Assist Standard and Enterprise depends on explicit cloud setup and is not enabled by default. First the developer connects Cloud Code to Google Cloud, then selects a Google Cloud project, then enables the required Identity and Access Management (IAM) permissions before AI assistance can run. Gemini Code Assist is now a separate plugin from Cloud Code, and organizations that previously used the combined plugin must update Virtual Private Cloud (VPC) Service Controls to allow incoming traffic to the Cloud Code API. The Google Cloud console provides related integrated assistance, where AI-assisted features answer architecture questions or troubleshoot errors as they appear.
Exam tip: Gemini Code Assist Standard and Enterprise requires selecting a Google Cloud project and enabling IAM permissions, and it runs as a separate plugin that needs the Cloud Code API allowed through VPC Service Controls.
Agent orchestration with Antigravity moves beyond single-file completion toward delegated work by coordinating AI agents across editor, terminal, and browser. Antigravity 2.0 is a graphical environment that manages parallel autonomous subagents, runs scheduled tasks, and coordinates multi-step workflows. Antigravity CLI is the AI-powered command-line companion that lets developers manage Google Cloud resources and build applications using natural language.
Google has unified IDE and command-line AI tools into Antigravity as a single, multi-agent platform. Starting June 18, 2026, Gemini Code Assist IDE extensions and Gemini CLI stopped serving requests for the Gemini Code Assist for individuals, Google AI Pro, and Google AI Ultra tiers, and affected users migrate to Antigravity and Antigravity CLI. Choose in-IDE Gemini Code Assist when the work is code generation and inline help inside Cloud Code, and choose Antigravity 2.0 when the work needs parallel subagents and scheduled, cross-tool orchestration.
| Tool | Where it runs | Choose when |
|---|---|---|
| Cloud Code with Gemini Code Assist | Inside VS Code, IntelliJ, or Cloud Shell Editor | The work is generating code, fixing code, and getting inline suggestions without leaving the IDE |
| Antigravity 2.0 | GUI across editor, terminal, and browser | The work needs parallel subagents, scheduled tasks, and orchestrated workflows |
| Antigravity CLI | AI-assisted command line | The work is managing cloud resources and development tasks with natural language |
Contextual protocols with MCP servers and Developer Knowledge give coding agents access to official Google documentation during development. The Developer Knowledge remote MCP server lets an agent search official developer documentation and retrieve information for products such as Google Cloud, Firebase, Android, and Maps. Requests flow from the agent to the MCP server to the documentation source, and answers flow back into the editor or terminal with project-aware context, so recommendations reflect current product behavior.
The google-cloud-developer plugin is the package that connects agents such as Claude Code, Antigravity CLI, and Codex CLI to Google Cloud tasks and to that MCP server. The plugin provides three related capabilities:
finding-google-skills skill, which locates and runs the right Google product skill on demand without preloading all skills.Setup for the plugin depends on the agent, and the agent depends on the Developer Knowledge API being enabled in the selected project. For Claude Code, the documented order is:
google-cloud-developer.gcloud services enable developerknowledge.googleapis.com for the project to allow documentation lookup.DEVELOPERKNOWLEDGE_API_KEY in the environment before starting Claude Code so the agent can authenticate to the MCP server.For Antigravity CLI, installation runs through the Google Agent Skills repository with agy plugin install, followed by the same API enablement step for developerknowledge.googleapis.com in the target project.
Configure Cloud SDK and authentication frameworks means setting up local tools and identity so an IDE can securely reach a specific Google Cloud project. The Google Cloud SDK (opens in a new tab) is a suite of libraries and tools for interacting with Google Cloud services from a local workstation. The suite includes the Google Cloud command-line interface (CLI) for managing resources, Cloud Client Libraries for calling APIs from code, IDE extensions, and local emulators.
Prerequisites for secure project access establish the identity, permission, and billing foundation that the SDK depends on before authentication can succeed. An administrator must complete this organization setup, because the gcloud CLI cannot create identities or enable billing on its own. Without these prerequisites, sign-in succeeds but resource and API calls fail.
The gcloud CLI is the primary command-line tool for managing Google Cloud resources, configuring defaults, and starting authentication. Initialization links the local workstation to one default project so commands and IDE extensions act on the correct project without repeating flags. Configuration persists locally, which keeps connectivity stable across terminal and IDE sessions.
Setup follows an ordered workflow where each step depends on the previous one:
gcloud commands are available in the terminal.gcloud init: Sign in with a user identity and select the default project that resource commands will target.gcloud auth application-default login: Create a local Application Default Credentials (ADC) file so Cloud Client Libraries can authenticate automatically against the project.After initialization, use gcloud config set to change the default project and region without repeating initialization, and use gcloud components update to keep installed CLI components current. If no local install is possible, Cloud Shell provides a zero-install browser terminal that already includes the gcloud CLI as an alternative.
Application Default Credentials (ADC) is the authentication framework that lets application code running locally authenticate to Google Cloud without embedded keys. Credentials flow from the developer sign-in to a local ADC file on the workstation, then from that file through Cloud Client Libraries to Google Cloud APIs. This separation matters because gcloud init authenticates the CLI for administrative commands, while ADC authenticates application code and local debugging sessions.
Exam tip: Use gcloud auth application-default login for local code and IDE debugging that calls Google APIs; gcloud init alone only signs in the gcloud CLI and selects the default project.
When local debugging finishes, run gcloud auth application-default revoke to remove the local ADC credentials from the workstation. Revocation breaks the link from local code to cloud APIs while leaving the project and IAM grants unchanged.
Cloud Client Libraries are language-idiomatic libraries that call Google Cloud APIs directly from application code. The libraries are available for Java, Python, Go, Node.js, C++, .NET, Ruby, PHP, and Rust. Code using these libraries depends on two project-specific requirements: the required Cloud APIs must be enabled for the project, and a valid ADC file must exist locally. When both are present, requests flow from the application through the client library to the enabled API in the configured project.
Cloud Code (opens in a new tab) extends supported IDEs, including Visual Studio Code and IntelliJ IDEA, so developers can build, deploy, and debug without leaving the editor. Cloud Code signs the IDE into Google Cloud and shows the active project in the status bar, where the developer can choose Switch Project and then select or search for a different project. For local run and debug sessions that call Google APIs, Cloud Code depends on ADC, so the workstation must also have run gcloud auth application-default login; otherwise the IDE shows an error when the application attempts the API call.
Optimize inner-loop development with Cloud Code means using an IDE extension to edit, run, debug, and monitor containerized apps without constant context switching. Cloud Code (opens in a new tab) brings Google Kubernetes Engine (GKE) and Cloud Run development directly into the editor so code, configuration, deployment, and monitoring happen in one place. Cloud Code supports the full cycle from creating an app from a template to monitoring deployed resources, and it includes run-ready samples and out-of-the-box configuration snippets that reduce setup work.
Cloud Code runs inside supported editors and connects local tools to Google Cloud through shared authentication and container tooling. Cloud Code is available for the following editors:
Cloud Code integrates with the Google Cloud SDK (Cloud SDK) (opens in a new tab) to provide unified authentication when the IDE calls Google Cloud services. Cloud Code also works with Skaffold, minikube, and kubectl to build, edit, run, and deploy applications locally or in the cloud with continuous feedback. Cloud Code supports Go, Java, Node.js, Python, and .NET Core for containerized development.
Local GKE application development with Cloud Code means creating, editing, running, and debugging Kubernetes applications against a local cluster before using a cloud GKE cluster. A developer can create a new GKE application from a template or open an existing application and customize its Kubernetes YAML with intelligent authoring support. The application can run on a local minikube cluster for fast validation or on any GKE cluster for cloud testing. Because Skaffold configuration is shared, the same build and deploy definitions move from the local loop toward staging and production.
Cloud Code supports Skaffold modules for developing parts of a large GKE application independently. Dependencies can be defined between skaffold.yaml configuration files and to specific modules, so one service can depend on another module without building the whole system. The module under active development rebuilds and redeploys while its dependencies remain available for local calls. This dependency model keeps team development isolated while preserving realistic integration between services.
Local Cloud Run service development with Cloud Code means building and testing a Cloud Run service in the IDE using a local emulator before deploying to hosted Cloud Run. A developer creates a new service from a template or opens an existing service, then develops and debugs it locally with the built-in Cloud Run emulator. The emulator reproduces the Cloud Run runtime on the workstation, so HTTP handling, container startup, and service behavior can be validated without deploying. Only after local validation does the developer deploy the same container to hosted Cloud Run.
The local and cloud paths use different IDE surfaces that complement each other. Local sessions depend on the emulator for rapid code changes, while deployed services depend on the Cloud Run Explorer for service status and the Log Viewer for output. Code flows from the IDE to the emulator during local work and from the IDE to hosted Cloud Run during deployment. This separation keeps experimental changes local while deployed revisions remain stable and observable.
Real-time log and resource monitoring with Cloud Code means service output flows from the running environment back into the IDE without opening a separate console. For Cloud Run, service progress and status appear in the Cloud Run Explorer while service logs stream into the Log Viewer. For GKE, deployed workloads and cluster resources can be created, browsed, and monitored from inside the IDE. The boundary is clear: execution happens in the emulator, minikube cluster, GKE cluster, or hosted Cloud Run, while observation happens in the IDE views.
The feedback order stays consistent across local and cloud runs. First, Cloud Code builds the container and starts it in the selected target. Then, runtime events and application output flow from that target to the Explorer and Log Viewer. Then, the developer edits code and reruns or redeploys to see new output in the same views. This tight loop shortens debugging because the cause in code and the effect in logs stay connected.
Exam tip: Use the built-in Cloud Run emulator for local develop-and-debug work, and use Cloud Run Explorer with Log Viewer for a deployed Cloud Run service; use minikube for local GKE validation and a GKE cluster for cloud runs.
Automated secret management with Cloud Code means sensitive values are stored in Secret Manager and referenced by the application instead of being written into source code. Cloud Code provides a Secret Manager view inside the IDE for creating, viewing, updating, and using secrets. The secret value flows from Secret Manager to the running application at runtime, while the codebase contains only a reference. This trust boundary keeps passwords, API keys, and tokens out of files, shell history, and version control.
The lifecycle keeps secrets manageable during iteration because creation, rotation, and consumption stay in one workflow. A developer creates a secret once in the Secret Manager view, updates its value when rotation is needed, and binds the same secret name to local and cloud runs. The application depends on Secret Manager for the value, not on a local configuration file. As a result, moving from the emulator to GKE or Cloud Run does not require copying secrets between environments.
Fast iteration with watch mode and buildpacks shortens the change-to-feedback cycle by removing repetitive packaging work from the inner loop. Watch mode keeps a development or debug session active and automatically applies code changes to Kubernetes sessions and emulated Cloud Run sessions. Google Cloud buildpacks create secure, production-ready container images directly from source code without requiring the developer to write or maintain a Dockerfile. Together, they let developers stay focused on code edits while Cloud Code handles rebuilds.
The inner-loop sequence runs in a fixed order that preserves parity with later environments:
The choice between GKE and Cloud Run targets depends on the workload shape, not on the editing experience:
| Workload | Local emulation target | IDE operations |
|---|---|---|
| GKE application | minikube cluster managed with Skaffold and kubectl | Intelligent YAML authoring, modular Skaffold builds, deploy to any GKE cluster |
| Cloud Run service | Built-in Cloud Run emulator | Local develop and debug, deploy to hosted Cloud Run, monitor in Cloud Run Explorer with Log Viewer |
Skaffold configuration links these paths so local validation, staging, and production share the same rendering and deployment format.
gcloud init signs in the gcloud CLI and selects the default project, while gcloud auth application-default login creates the local Application Default Credentials file used by application code.developerknowledge.googleapis.com and the DEVELOPERKNOWLEDGE_API_KEY.gcloud init signs in the Google Cloud command-line interface (CLI) and selects the default project for resource commands, while gcloud auth application-default login creates the local Application Default Credentials (ADC) file used by application code. Cloud Client Libraries and local IDE debugging sessions depend on that ADC file to authenticate to Google Cloud APIs, so gcloud init alone is not sufficient for local code that calls Google APIs.
Use Cloud Code with Gemini Code Assist Standard and Enterprise inside Visual Studio Code, IntelliJ IDEA, or Cloud Shell Editor when the work is generating code, fixing code, and getting inline suggestions without leaving the IDE. Choose Antigravity 2.0 when the work needs parallel autonomous subagents, scheduled tasks, and orchestrated workflows across editor, terminal, and browser, and choose Antigravity CLI when the work is managing Google Cloud resources and development tasks with natural language from the command line.
For Claude Code, add the Google plugins marketplace and install the google-cloud-developer plugin, then enable developerknowledge.googleapis.com in the selected project to allow documentation lookup. Create and secure an API key for the Developer Knowledge API and export DEVELOPERKNOWLEDGE_API_KEY in the environment before starting Claude Code so the agent can authenticate to the MCP server and search official Google documentation.
Last updated