YOUR BOUNDARY
Keep one toolchain.
Store projects under /home/your-name inside WSL and run Java, Python, Git, and Maven there. Do not work on the same project through /mnt/c with a second Windows toolchain.
Loading…
ENGINEERED BOOTCAMP / WINDOWS / WSL 2
Keep Windows for desktop applications and perform bootcamp work inside one WSL 2 Linux distribution. Treat the Linux shell and Linux file system as the project boundary.
YOUR BOUNDARY
Store projects under /home/your-name inside WSL and run Java, Python, Git, and Maven there. Do not work on the same project through /mnt/c with a second Windows toolchain.
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
INVENTORY
WHAT THIS STEP TEACHES
“I can distinguish the Windows host requirements for WSL 2 from the Linux environment that will run inside it.”
WSL 2 has two layers: Windows supplies virtualization and the WSL platform; a chosen Linux distribution supplies the shell and Linux tools.
A failure in Windows virtualization cannot be repaired inside Linux, while a missing Linux package should not be fixed by installing a second Windows copy.
Before enabling anything, predict which checks belong to Windows: Windows release, architecture, virtualization permission, memory, and WSL availability.
Do not begin installing Linux tools until the Windows host and organizational policy actually permit WSL 2.
Explain the host layer, the future Linux layer, and which administrator action—if any—is required before the first Linux shell can open.
GUIDED ACTION
Record the Windows version, architecture, memory, disk, install privileges, and virtualization status. Open PowerShell and check the installed WSL version or follow Microsoft's install guide if WSL is absent. Complete any required restart yourself.
CHECK BEFORE STEP 02
The Windows host passes the documented WSL 2 requirements, and you can name which future actions happen in PowerShell versus the Linux shell.
STEP
02
DISTRIBUTION
WHAT THIS STEP TEACHES
“I can choose one maintained WSL distribution and understand that its packages are separate from Windows packages.”
A WSL distribution is a Linux user space with its own files, package database, users, and executables running on the WSL 2 kernel.
Installing the same tool on both sides creates two PATHs, two configurations, and two places where a command can unexpectedly run.
Choose the distribution from current Microsoft and distribution support information, then predict where its home directory and package manager will live.
Do not treat a Windows executable visible from WSL as proof that the Linux toolchain is installed correctly.
Explain which Linux distribution you selected, how it differs from the Windows host, and where Linux packages will be managed.
GUIDED ACTION
Choose a maintained WSL distribution whose package instructions you can follow; Ubuntu is the reference path, not a requirement. Open that distribution, create your Linux user when prompted, update it through its official package manager, and record the distribution and release.
CHECK BEFORE STEP 03
The selected distribution is maintained, updated through its own package system, and has one normal Linux user for course work.
STEP
03
FILE SYSTEM
WHAT THIS STEP TEACHES
“I can keep a Linux-tool project in the WSL file system and recognize when I have crossed into a mounted Windows path.”
Paths under /home belong to the Linux file system; paths under /mnt/c expose the Windows file system through WSL.
Mixing file-system semantics can affect performance, permissions, line endings, executable bits, and how editors or build tools observe changes.
Predict what pwd should begin with after you enter the project and what /mnt/c would tell you about the boundary.
Do not edit one project alternately with Windows and Linux toolchains unless the lesson explicitly asks you to test that boundary.
Explain where the project physically lives, which toolchain owns it, and how pwd proves you did not place it under a Windows mount.
GUIDED ACTION
Create your workspace beneath your WSL home directory. Run pwd and confirm the path begins under /home rather than /mnt/c. Open the folder through an editor's supported WSL/remote connection instead of moving it into the Windows file system.
CHECK BEFORE STEP 04
pwd reports a path under /home, Linux owns the project files, and the editor opens that same Linux-side folder.
STEP
04
JAVA
WHAT THIS STEP TEACHES
“I can choose a Java 17 JDK that matches my operating system and architecture and distinguish a JDK from a runtime alone.”
A JDK contains the Java runtime plus development tools such as the javac compiler; a runtime-only package cannot compile your source code.
Professional builds compile and test from source, so both the runtime and compiler must be supported, discoverable, and on the same major version.
Find Java 17, JDK, your operating system, and your architecture on the official page before downloading or invoking a package manager.
Do not select a package because its filename contains Java; confirm JDK, major version 17, operating system, and architecture separately.
Explain why you selected this distribution and package, which architecture it targets, and why a JRE-only installation would fail the course check.
GUIDED ACTION
Ignore any Java installation on the Windows host. Follow the selected distribution's supported package path or Eclipse Temurin's Linux instructions, select the Java 17 JDK, and install it yourself inside WSL. Verify both runtime and compiler in a new WSL shell.
CHECK BEFORE STEP 05
The official source supports your host, and a new shell reports Java 17 for both java and javac from locations you recognize.
STEP
05
PYTHON
WHAT THIS STEP TEACHES
“I can install or select Python 3.14 without replacing an operating-system-managed interpreter.”
The operating system may depend on its own Python, while a project can deliberately select another interpreter and isolate packages in a virtual environment.
Replacing a system interpreter can break package-management or administration tools; project isolation keeps dependencies reproducible and removable.
Identify the exact Python 3.14 launcher or executable the official method will provide and predict how you will call it without changing the system default.
Do not repoint or overwrite an unversioned system Python merely to make a version command look correct.
Explain which interpreter belongs to the operating system, which one belongs to the course, and how your project selects the latter.
GUIDED ACTION
Check whether your distribution provides a maintained Python 3.14 package. If it does not, follow uv's official Python-install guide as a user-space version path or use your recorded fallback. Never relink or remove the Python interpreter owned by the Linux distribution.
CHECK BEFORE STEP 06
The version-specific launcher reports Python 3.14, and the operating-system-managed interpreter remains untouched.
STEP
06
GIT
WHAT THIS STEP TEACHES
“I can identify one Git installation and separate executable configuration from my commit identity.”
Git is the version-control program; user.name and user.email are authorship metadata stored in commits, not login credentials.
Traceable work requires consistent authorship, while duplicate Git installations or copied credentials make failures and provenance harder to diagnose.
Predict which Git executable your chosen shell will find and decide which name and email are appropriate for your own commits.
Do not install a second Git just to obtain the newest number, and never place a password or token in identity fields.
Explain where Git came from, which shell uses it, what identity metadata does, and why it is not a password or access token.
GUIDED ACTION
Install Git through the distribution's package manager if needed. Configure only your own commit identity inside WSL, verify the effective values, and avoid copying a Windows credential file or private key into the repository.
CHECK BEFORE STEP 07
Your chosen shell finds one maintained Git installation and new commits contain only the identity you intentionally configured.
STEP
07
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
Run the Python 3.14 interpreter you installed to create .venv, activate it in the WSL shell, install pytest through python -m pip, and run pytest. Close WSL, reopen it, return to the project, reactivate, and repeat the check.
CHECK BEFORE STEP 08
The project-local interpreter runs pytest, generated files belong to your normal user, and the environment folder is ignored by Git.
STEP
08
PROJECT CHECK
WHAT THIS STEP TEACHES
“I can use project-owned scripts and separate current observations from tools required only in later modules.”
A wrapper script records how the project invokes a build tool; an environment inventory records what is currently present without making every tool an immediate dependency.
Project-owned entry points reduce machine-to-machine differences, while installing future infrastructure early increases cost, privilege, and troubleshooting surface.
Predict which wrapper script belongs to your shell and list later tools you will inspect but intentionally not install yet.
Do not install every named technology during setup or substitute a globally installed build command for the project wrapper.
Explain why the wrapper is portable, which script your shell uses, and why Docker, PostgreSQL, Node, or Kubernetes may remain deferred.
GUIDED ACTION
Use ./mvnw for the Java project in Task 2. Record Node, Docker, and PostgreSQL only if already present inside WSL. Read Docker's WSL requirements now, but defer its installation until the container module.
CHECK TO FINISH THIS PATH
The correct wrapper test passes, and every missing future tool is marked deferred with a supported later path rather than installed early.
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
wsl --versionAsk the Windows WSL management command to report its installed platform version.
Predict whether the command is available on the Windows host and which WSL generation you intend to use.
Read-only: it prints Windows-side WSL metadata.
COMMAND 02
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 03
pwdPrint the absolute path of the directory the shell is currently using.
Write whether the path should begin with /home or /mnt/c before running it.
Read-only: it prints one path.
COMMAND 04
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 05
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 06
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 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
Use the Windows-native route if virtualization or WSL policy is the hard blocker. Use Codespaces if you need a Linux environment but cannot enable WSL and its quota/connectivity checks pass.
SWITCH PATH