Terraform and Cloud Workstations: Reproducibility at the IaC to Persistent Home Boundary

Answer to the Questions

1. Does disabling persistent home guarantee that a workstation rebuilt by Terraform after destroy yields identical developer state, assuming a pinned custom image?

Yes – when persistent_home_enabled is set to false, the workstation starts from the container image alone. The image must be immutable (e.g., a pinned tag or digest). No runtime modifications can survive a destroy/apply cycle, so the environment is reproducible across rebuilds.

2. When a workstation configuration is updated to a new image tag, what state from the persistent home directory survives and can cause divergence between developers using the same configuration?

• All files under $HOME that were written during a session (dotfiles, local caches, SSH keys, installed packages that write to $HOME, etc.) remain untouched.
• Any user‑specific configuration (e.g., .bashrc, .zshrc, IDE settings stored in $HOME) will persist even if the base image changes.
• Consequently, developers who previously added custom tools or altered their shell environment will see those changes after an image upgrade, while new developers will start with the fresh image state.

3. How do organization policy constraints interact with a Terraform‑defined workstation configuration to affect whether the configuration can actually launch?

• Org policies are evaluated at request time. If a policy forbids a property used in the workstation definition (e.g., compute.requireOsLogin set to TRUE but the workstation uses a non‑OS‑Login account), the terraform apply will fail with a permission‑denied error.
• Location restrictions (e.g., compute.machineTypeLocationPolicy) can block creation in a region where the chosen machine type is not allowed.
• IAM policy constraints on service account creation or use of custom images can likewise prevent launch even if the Terraform code is syntactically correct.

Assumptions and Constraints

• The custom container image is stored in Artifact Registry and is referenced by a fixed tag or digest in the Terraform google_cloud_workstation resource.
• Persistent home is backed by a Filestore or Persistent Disk that is not automatically deleted when the workstation is destroyed.
• Organization policies are inherited from the folder or organization root and are not overridden by the Terraform project unless explicitly allowed.

Practical Steps for This Case

1. Pin the image in Terraform:

   resource "google_cloud_workstation" "dev_ws" {
     name              = "dev-ws"
     location          = "us-central1"
     machine_type      = "n2-standard-4"
     persistent_home_enabled = false
     image {
       image_uri = "us-docker.pkg.dev/my-project/my-repo/my-image:1.0.0"
     }
   }
   

2. Apply the plan:

   terraform init
   terraform apply
   

3. Verify that no user‑made changes survive a destroy/apply cycle:

   terraform destroy -auto-approve
   terraform apply
   # Check that installed packages, dotfiles, etc., match the image contents
   

4. If persistent home is desired, enable it and ensure the Filestore/PD has appropriate IAM:

   resource "google_cloud_workstation" "dev_ws" {
     ...
     persistent_home_enabled = true
   }
   

5. To inspect organization policy conflicts, run:

   gcloud resource-manager org-policies list --project=$PROJECT_ID
   

   and compare the output to the workstation settings. If a policy blocks a required feature, adjust the policy or the workstation configuration accordingly.

Diagnostic Question

If you encounter an unexpected launch failure after applying the configuration, please confirm whether any organization policy (e.g., compute.requireOsLogin, compute.machineTypeLocationPolicy) is set to TRUE or DENY for the target project. This detail will determine whether the policy is the root cause and whether you need to modify the policy or the workstation definition.