Your enterprise wants to standardize cloud-hosted developer workspaces across multiple engineering teams using Google Cloud Workstations. The security and DevOps teams have defined the following governance requirements: Developers must access a managed web-based IDE (Code OSS) pre-configured with the Google Cloud Code extension, mandatory organizational security linters, and internal code analysis plugins. IDE settings (such as lint-on-save, formatting rules, and telemetry opt-outs) must be enforced by default across all developer instances. Configuration and rollout must be automated via Infrastructure as Code (IaC) to ensure environment immutability and prevent configuration drift. Which approach should you implement to meet these requirements?

Create and publish a custom container image extending the Cloud Workstations base Code OSS image that pre-installs the required .vsix extensions and injects default workspace settings, then manage Workstation Configurations referencing this image via Terraform.: ### What Custom Cloud Workstations Container Images Are **Google Cloud Workstations** provides managed development environments running inside container instances. By building a custom container image derived from Google's base **Code OSS** (VS Code open-source) image, organizations can package specific runtimes, dependencies, configuration files, and IDE extensions into an immutable artifact. ### How It Meets the Requirements - **Pre-configured Extensions and Linters**: Required extensions (such as **Cloud Code**, linters, and internal security tools) can be downloaded as `.vsix` binaries during the `Dockerfile` build step and installed directly into the global extension directory (`/opt/code-oss/extensions`). - **Default IDE Settings**: Organizational standards (formatting, lint-on-save, telemetry flags) can be baked into the global or template `settings.json` directory in the container image, ensuring immediate compliance when workspaces launch. - **Automated IaC Rollout**: Defining the workstation cluster, workstation configuration, and individual workstation instances using **Terraform** (`google_workstations_workstation_config`) creates a fully automated, auditable, and repeatable delivery pipeline. Updating the container image tag in Terraform triggers managed workstation updates, preventing configuration drift. ### Key Advantages - **Immutable Infrastructure**: Changes to dependencies and tooling are versioned via Git and container registries, avoiding snowflake environments. - **Rapid Onboarding**: Developers launch ready-to-code environments in seconds without running manual setup scripts. - **Enterprise Security**: Integrates natively with **VPC Service Controls**, IAM permissions, and artifact scanning in **Artifact Registry**. - **Central Governance**: Security teams can mandate base image vulnerabilities scans and enforce compliance before images reach production configurations. ### Why This Is Optimal Baking configurations and extensions directly into the workstation container image and deploying them via Terraform ensures absolute reproducibility, high startup performance, and centralized policy enforcement across the entire developer fleet.

Cloud Workstations Ide Custom Image Extension Automation | Professional Cloud DevOps Engineer

Cloud Workstations Ide Custom Image Extension Automation

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your enterprise wants to standardize cloud-hosted developer workspaces across multiple engineering teams using Google Cloud Workstations. The security and DevOps teams have defined the following governance requirements:

Developers must access a managed web-based IDE (Code OSS) pre-configured with the Google Cloud Code extension, mandatory organizational security linters, and internal code analysis plugins.
IDE settings (such as lint-on-save, formatting rules, and telemetry opt-outs) must be enforced by default across all developer instances.
Configuration and rollout must be automated via Infrastructure as Code (IaC) to ensure environment immutability and prevent configuration drift.

Which approach should you implement to meet these requirements?

Define a Cloud Composer DAG that executes remote SSH commands against active developer workstations on a daily schedule to synchronize IDE settings and install missing extensions.

Configure a repository-level .vscode/extensions.json and settings.json file in each Git source repository, requiring developers to manually accept recommended extensions when opening Cloud Shell.

Deploy standard Compute Engine virtual machines with Cloud Init startup scripts that download the VS Code desktop binary and execute runtime extension install commands upon user login.

Create and publish a custom container image extending the Cloud Workstations base Code OSS image that pre-installs the required .vsix extensions and injects default workspace settings, then manage Workstation Configurations referencing this image via Terraform.

Professional Cloud DevOps Engineer

Cloud Workstations Ide Custom Image Extension Automation

Related questions