ENGINEERED BOOTCAMP / BROWSER / REMOTE LINUX
Use a browser-accessible Linux development container and commit its reproducible configuration. Treat account access, reliable internet, usage limits, and a separate Week 14 Kubernetes path as required constraints.
YOUR BOUNDARY
Your project lives in one GitHub repository and one configured Linux codespace. Stop the codespace when you finish, commit source and environment configuration, and never commit credentials or private course records.
BEFORE STEP 01
YOUR PATH
Stop at a failed checkpoint, read the linked official source, and make one bounded correction before you continue.
STEP
01
COST GATE
WHAT THIS STEP TEACHES
“I can translate a remote-workspace billing model into a hard usage boundary before creating compute.”
Remote development consumes metered compute and storage even though the interface appears inside a browser.
Stopped, idle, and retained environments can have different cost behavior; a visible budget and cleanup rule prevent accidental spending.
Read the current included allowance and predict which actions consume compute, storage, or both before clicking Create.
Do not interpret free to start as unlimited free use, and do not attach a payment method merely to continue the lesson.
Explain the allowance, stop-usage behavior, storage retention, and the exact event that makes you use the no-cost fallback.
GUIDED ACTION
Open GitHub's current included-usage and Codespaces billing pages. Record your remaining core-hours and storage, set a budget that stops usage rather than permitting overage, and decide how often you will stop and delete unused codespaces.
CHECK BEFORE STEP 02
You recorded the current allowance, a stop-usage budget, cleanup timing, and a no-payment fallback before creating a codespace.
STEP
02
REPOSITORY
WHAT THIS STEP TEACHES
“I can explain why a remote workspace begins from a repository and how Git provides durable state outside the disposable machine.”
The codespace is replaceable compute; the repository is the durable, versioned source of project files and environment configuration.
A rebuild or deletion should not erase committed work, while secrets and private learning records must remain outside the project repository.
Predict which files must survive deletion through Git and which private records must never enter this repository.
Do not treat an uncommitted file inside a running codespace as backed up or mix the private course-records repository into the project.
Explain what the repository preserves, what the codespace provides temporarily, and which files or data remain outside both public history and images.
GUIDED ACTION
Create an empty private java-gradebook-cli repository yourself so the codespace has a durable home. Do not create the private course-records repository inside it. Record that this path reorders only the project-repository action; you still create the Agile board and course repository in Task 3.
CHECK BEFORE STEP 03
The project repository exists with the intended visibility, and you can classify durable source, generated files, secrets, and private records correctly.
STEP
03
FIRST LAUNCH
WHAT THIS STEP TEACHES
“I can inspect a disposable remote environment and distinguish observed defaults from requirements I have declared.”
A default image is a vendor-controlled starting point whose tools and versions may change; an inventory is evidence, not a reproducible specification.
Work that succeeds only because of an undocumented preinstalled tool can fail after a rebuild, image update, or teammate launch.
Predict which tools might already exist, then record actual versions and resources without treating a convenient default as permanent.
Do not configure the disposable environment manually and mistake that session state for a reproducible project setup.
Explain which values came from the disposable image, which values the course requires, and which mismatch the later configuration must resolve.
GUIDED ACTION
Create the smallest available codespace from the project repository, open it in the browser, and record the Linux distribution, architecture, Java, Python, Git, memory, disk, and repository path. Treat default tool versions as observations, not requirements you can assume later.
CHECK BEFORE STEP 04
The inventory records distribution, architecture, tools, memory, disk, and repository path, with defaults clearly separated from requirements.
STEP
04
CONFIGURATION
WHAT THIS STEP TEACHES
“I can describe a development environment as versioned configuration instead of a sequence of remembered clicks and commands.”
A dev-container configuration declares the base image and features needed to reconstruct the development environment.
Versioned configuration can be reviewed, rebuilt, and shared; manual changes disappear or drift without an auditable explanation.
List the minimum declared requirements—Java 17 and Python 3.14—and predict which unrelated future tools should remain absent.
Do not add Docker, databases, cloud CLIs, or Kubernetes merely because the configuration file can install them.
Explain what the base image supplies, what each feature adds, what remains project-local, and how Git captures the declaration.
GUIDED ACTION
Follow GitHub's Java project guide and dev-container documentation. Add a .devcontainer/devcontainer.json yourself using a maintained Java 17 image or Java feature and the maintained Python feature set to 3.14. Keep Maven available only to bootstrap the project Wrapper and do not add Docker, PostgreSQL, Node, or cloud CLIs yet.
CHECK BEFORE STEP 05
The committed configuration declares only the current requirements and contains no secret, personal path, or unnecessary future service.
STEP
05
REBUILD
WHAT THIS STEP TEACHES
“I can rebuild from declared configuration and use the result to test reproducibility.”
A rebuild discards or replaces environment state and applies the versioned declaration again; it tests the declaration rather than your memory.
CI, onboarding, disaster recovery, and image updates all depend on reconstructing a working environment from source-controlled inputs.
Predict which tools, versions, files, and uncommitted changes should remain or disappear after the rebuild.
Do not repair a failed rebuild only by typing an unrecorded install command; fix the declaration or document the missing prerequisite.
Compare the prediction with the rebuilt environment and explain whether each surviving capability came from Git, configuration, or persistent platform storage.
GUIDED ACTION
Commit the dev-container configuration, choose Rebuild Container, and wait for the rebuild to finish. Run the checks below and compare them with the declared versions. Diagnose the build log before editing configuration when a feature fails.
CHECK BEFORE STEP 06
A rebuild produces the required Java and Python versions from the committed declaration, and any mismatch has a named source.
STEP
06
PYTHON PROJECT
WHAT THIS STEP TEACHES
“I can create a project-local Python environment and prove that its interpreter—not a global one—runs pytest.”
A virtual environment is a project-specific interpreter context with its own package location; activation only changes how the current shell resolves commands.
Projects need different dependency versions, and CI must be able to reproduce those dependencies without modifying the machine-wide Python installation.
Predict which new folder will appear and which Python executable should run after activation or when addressed explicitly.
Do not use sudo or a global pip command to repair a project-local dependency problem.
Explain what the virtual environment isolates, what activation changes, what it does not change, and how you proved pytest ran inside it.
GUIDED ACTION
Create .venv with the declared Python 3.14 interpreter, activate it, install pytest through python -m pip, and run the tests. Add .venv to .gitignore; do not commit an environment created on remote storage.
CHECK BEFORE STEP 07
The project-local interpreter runs pytest, generated files belong to your normal user, and the environment folder is ignored by Git.
STEP
07
PERSISTENCE
WHAT THIS STEP TEACHES
“I can distinguish stopping, rebuilding, deleting, and recovering a remote workspace.”
Stop preserves a workspace for later use, rebuild reconstructs its environment, and deletion removes the workspace; committed Git history is the recovery boundary.
Remote systems are intentionally disposable, so reliable work depends on knowing what the provider retains and what only a commit preserves.
Predict the fate of committed source, uncommitted source, installed packages, and generated files for stop, rebuild, and delete.
Do not delete a codespace while required work is uncommitted or assume rebuild and restart mean the same thing.
Explain each lifecycle action and demonstrate how a clean clone or recreated codespace recovers the project from Git.
GUIDED ACTION
Push the configuration and a harmless README change, stop the codespace, reopen it, and rerun the checks. Then rebuild once more from the committed configuration. Confirm which uncommitted files persist and which environment state must be recreated.
CHECK BEFORE STEP 08
You successfully stop and reconnect, rebuild from configuration, and can state which recovery requires committed Git history.
STEP
08
LIMITS
WHAT THIS STEP TEACHES
“I can recognize when a remote development container cannot safely host the later container-orchestration exercise.”
Running containers or Kubernetes inside an already containerized remote workspace adds nesting, privilege, network, resource, and billing constraints.
A workaround that grants broad privilege or consumes unexpected compute is not equivalent to a supported, no-cost local lab.
Compare the later Docker and minikube requirements with the provider limits and predict which requirement is most likely to fail.
Do not enable privileged nesting or paid compute simply to keep the same environment for every module.
Explain whether the remote route can support the later lab and name the local or other approved fallback before reaching that week.
GUIDED ACTION
Use ./mvnw for Task 2 and stop the codespace when finished. Recheck usage after the session. Because Codespaces gives limited access to its outer host, do not assume minikube will satisfy Week 14; name and verify a separate supported machine, approved sandbox, or equivalent local-cluster path before accepting this as your full-course environment.
CHECK TO FINISH THIS PATH
A documented, supported later path exists for Docker and minikube, or a separate fallback machine is already named.
YOUR COMMANDS
Type each command in the shell for your selected path. Do not include a prompt symbol. Keep redacted output and explain what each result proves.
COMMAND 01
cat /etc/os-releaseRead the standard operating-system identification file provided by the Linux distribution.
Predict the distribution, then compare the prediction with PRETTY_NAME, ID, and VERSION_ID.
Read-only: it prints a public system metadata file.
COMMAND 02
uname -mAsk the operating system for the machine hardware name exposed to this environment.
Predict x86_64 for an Intel/AMD 64-bit environment or arm64/aarch64 for an ARM environment, then verify the exact output.
Read-only: it prints architecture metadata.
COMMAND 03
java --versionAsk the Java runtime selected by this shell to identify its version.
Write which major version and vendor you expect before running it.
Read-only: it prints version information and changes no project file.
COMMAND 04
javac --versionAsk the Java source compiler selected by this shell to identify its version.
Predict whether javac exists and whether its major version matches java.
Read-only: it prints compiler metadata.
COMMAND 05
python3.14 --versionUse the selected Python launcher to identify the interpreter it resolves to.
Write the exact 3.14 patch line you expect and which installation should supply it.
Read-only: it starts the interpreter only long enough to print metadata.
COMMAND 06
git --versionAsk the Git executable selected by this shell for its version.
Predict which Git installation the shell will find if more than one could exist.
Read-only: it does not create a repository or change tracked files.
COMMAND 07
python3.14 -m venv .venvAsk the chosen Python 3.14 interpreter to create an isolated environment in a folder named .venv.
Predict which folder will be created and confirm that your normal user owns the project directory.
Creates or populates .venv inside the current directory; it should not change the system Python.
COMMAND 08
source .venv/bin/activateLoad the virtual environment's activation script into the current shell.
Predict which python command will resolve after activation and what will return when the shell closes.
Changes only the current shell session; it does not install a package or permanently replace Python.
COMMAND 09
python -m pytestRun the pytest module using the Python interpreter currently selected by the shell.
Predict how many tests pytest should discover and whether they should pass before running them.
Executes test code and may create test caches; it should not modify production source files.
COMMAND 10
./mvnw testUse the project-owned Maven Wrapper script to execute Maven's test lifecycle.
Predict which tests should run and whether the wrapper may need to download its pinned Maven distribution the first time.
May download the declared Maven distribution and writes generated build output such as target; it should not edit your source.
YOUR CHOICES
PASS CHECKS
FALLBACK TRIGGER
Move to a local Windows, WSL, macOS, or Linux path when internet reliability, account access, included usage, storage, latency, or Week 14 host requirements fail. Export no secrets; push sanitized source and recreate the environment from the repository.
SWITCH PATH