This set builds vocabulary for reproducible, ephemeral cloud development workspaces.
0 / 5 completed
1 / 5
At standup, a dev mentions a configuration file in the repository that declares the exact Docker image, tasks, and ports needed to spin up a ready-to-code workspace. What is this file called?
A workspace configuration file, like Gitpod's .gitpod.yml, declares the exact Docker image, startup tasks, and ports a project needs, letting the platform automatically provision a fully ready-to-code environment from that declarative definition. This removes manual setup steps and keeps the environment definition version-controlled alongside the code itself. It's the core mechanism that makes an ephemeral cloud workspace reproducible on demand.
2 / 5
During a design review, the team wants a workspace to be pre-built in the background as soon as a commit is pushed, so it's instantly ready when a developer opens it. Which capability supports this?
Prebuilds run the workspace's setup steps, like dependency installation, in the background as soon as a commit is pushed, so that when a developer actually opens the workspace it's already prepared rather than making them wait through the full build process. This significantly reduces the perceived startup latency of an ephemeral cloud environment. It's a performance optimization layered on top of the basic on-demand provisioning model.
3 / 5
In a code review, a dev notices closing a workspace without merging discards all its state, since each one is spun up fresh from the repository each time. What does this reflect?
The ephemeral nature of a cloud workspace means it's spun up fresh from the repository's committed state and configuration each time, so any uncommitted local changes or manual environment tweaks are lost once that workspace is closed and not reopened. This disposability encourages committing meaningful changes and configuration into version control rather than relying on undocumented local state. It's a deliberate design tradeoff favoring reproducibility over persistent customization.
4 / 5
An incident report shows a developer lost hours of uncommitted work because an idle ephemeral workspace was automatically terminated. What practice would prevent this?
Since an ephemeral workspace can be automatically terminated after a period of inactivity, regularly committing or otherwise saving work-in-progress avoids losing hours of uncommitted changes when that termination happens. Assuming a workspace will simply persist indefinitely misunderstands the disposable model these platforms are built around. This habit of frequent committing is a reasonable adaptation to working in any ephemeral compute environment.
5 / 5
During a PR review, a teammate asks why the team relies on ephemeral, disposable cloud workspaces instead of a persistent, always-available development machine. What is the reasoning?
A persistent development machine can accumulate undocumented local changes and configuration drift over time, while an ephemeral workspace is rebuilt fresh from the repository's declared configuration every time, guaranteeing it matches what's actually committed. This reproducibility is valuable for catching "works on my machine" issues early. The tradeoff is losing any convenience of long-lived local customization that isn't captured in the workspace configuration.