YOUR BOUNDARY
Keep one toolchain.
Store this path's projects in the Windows file system and run them with Windows tools. Do not create a second copy inside WSL.
Loading…
ENGINEERED BOOTCAMP / WINDOWS / NATIVE SHELL
Keep your Java, Python, Git, project files, and commands on the Windows side. Use PowerShell as the reference syntax or translate each command deliberately when you choose Command Prompt.
YOUR BOUNDARY
Store this path's projects in the Windows file system and run them with Windows tools. Do not create a second copy inside WSL.
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 identify my exact Windows release, architecture, resources, and permission boundary before choosing software.”
Software support applies to a specific operating-system release and processor architecture, not to the word Windows by itself.
Installers, container backends, and workplace policies can differ between Windows releases and between x64 and ARM64 computers.
Predict which two facts an installer must match: your Windows release and your System type. Then locate those facts rather than guessing from the computer brand.
Do not treat the marketing name of the computer or the word 64-bit alone as the complete compatibility check.
Explain which Windows release and architecture you have, how much memory and disk are available, and which installation actions your account is allowed to perform.
GUIDED ACTION
Open Settings → System → About. Record the Windows edition and version, System type, installed memory, free disk, and whether your account may install software. Stop if the operating system is outside the selected tool's supported versions.
CHECK BEFORE STEP 02
Your record contains the exact Windows edition, version, system type, memory, free disk, and permission boundary, with no field inferred from appearance.
STEP
02
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
For x64, choose the Java 17 JDK—not a JRE—from Eclipse Temurin or another compatible OpenJDK distribution. For ARM64, use a distribution whose current download table explicitly lists Windows ARM64, such as the Microsoft Build of OpenJDK. Download and run the official installer yourself; record whether it changes PATH or JAVA_HOME.
CHECK BEFORE STEP 03
The official source supports your host, and a new shell reports Java 17 for both java and javac from locations you recognize.
STEP
03
JAVA CHECK
WHAT THIS STEP TEACHES
“I can prove that a tool is configured persistently rather than available only in one lucky terminal session.”
A shell resolves command names through its current environment, especially PATH; installers and activation commands may change only one process or future processes.
Builds, CI jobs, new terminals, and restarted computers do not inherit accidental state from a terminal you configured manually.
Predict which executable a new standalone shell will find and whether its version will match the one you just installed.
Do not verify only inside an editor terminal or an already-activated environment and assume the configuration is persistent.
Explain what closing the old shell removed, what the new shell loaded, and what the version and executable-location checks prove.
GUIDED ACTION
Close every terminal, open your selected Windows shell from the Start menu, and run the Java runtime and compiler checks below. Confirm that both report major version 17 and come from the distribution you selected before continuing.
CHECK BEFORE STEP 04
A newly opened standalone shell finds the intended executable and version without repeating an unrecorded setup command.
STEP
04
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
Follow Python's Windows guide and install the Python Install Manager from python.org or the Microsoft Store. Use the manager to obtain Python 3.14, then select the version-specific launcher in the commands below. Do not rely on whichever unversioned python command happens to resolve first.
CHECK BEFORE STEP 05
The version-specific launcher reports Python 3.14, and the operating-system-managed interpreter remains untouched.
STEP
05
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
Follow the maintained Git for Windows download page. Record the installer choices you change, especially default branch naming and line-ending behavior. You may use Git Bash later for comparison, but run this route's evidence in the Windows shell you selected.
CHECK BEFORE STEP 06
Your chosen shell finds one maintained Git installation and new commits contain only the identity you intentionally configured.
STEP
06
WORKSPACE
WHAT THIS STEP TEACHES
“I can create a workspace owned by my normal user and keep project paths portable.”
A workspace is the file-system boundary where source, generated files, and project-local dependencies live under predictable ownership.
Root-owned files, mixed Windows/Linux paths, and committed personal absolute paths cause permission failures and make a project fail on another machine or in CI.
Choose a location your normal user owns and predict its absolute path, but plan to use repository-relative paths inside tracked files.
Do not create or open the project with administrator or sudo privileges merely to bypass an ownership error.
Explain who owns the workspace, which operating-system side contains it, and why tracked files must not depend on your personal home path.
GUIDED ACTION
Choose a folder you can write without elevation. Record its absolute location only in your private environment decision; use repository-relative paths in every tracked file. Open that folder from your selected shell before creating project files.
CHECK BEFORE STEP 07
Your normal user can create and edit files there, and a tracked-file search finds no personal absolute path.
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
Use the version-specific Python 3.14 launcher to create .venv. Install pytest through the virtual environment's own interpreter, run its version check, close the shell, and repeat the pytest check without relying on a global package.
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
When you create the Java project in Week 0 Task 2, run mvnw.cmd from your selected Windows shell. Record Node, Docker, and PostgreSQL only if they already exist; do not install them until their modules. Check Docker Desktop's Windows and WSL requirements now so you know whether WSL or a remote fallback will be needed later.
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
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 02
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 03
py -V:3.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 04
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 05
py -V:3.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 06
.\.venv\Scripts\python.exe -m pip install pytestRun pip through the virtual environment's own Python and install pytest into that environment.
Predict where the package will be installed and verify that the path is inside .venv rather than a global directory.
Changes the project-local environment and may download packages; it should not modify the system interpreter.
COMMAND 07
.\.venv\Scripts\python.exe -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 08
.\mvnw.cmd 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 the WSL 2 path if Linux tooling becomes a requirement and virtualization is supported. Move to Codespaces if install rights, architecture support, or later container requirements remain unavailable and its cost/connectivity checks pass.
SWITCH PATH