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

A repeatable development environment is being defined with Cloud Workstations provisioned declaratively via Terraform. The workstation configuration expresses cluster, machine type, and container image, and IAM bindings for workstation users can be codified in the same plan.

The integration boundary is between the Terraform-managed configuration and the developer-facing runtime state. The container image and machine spec are reproducible, while the persistent home directory is designed to retain user state across stops, starts, and image updates. This creates an unresolved decision about where reproducibility should live: in an immutable, versioned custom container image stored in Artifact Registry, or in flexible startup scripts that run on each start. Ephemeral versus persistent home is a configuration choice that trades reproducibility for convenience.

With that boundary in mind:

• Does disabling persistent home guarantee that a workstation rebuilt by Terraform apply after destroy yields identical developer state, assuming a pinned custom image?
• 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?
• How do organization policy constraints interact with a Terraform-defined workstation configuration to affect whether the configuration can actually launch?