YOUR BOUNDARY
Keep one toolchain.
Run course tools as your normal user inside a home-directory workspace. Use sudo only for a documented system package action, never to run the project, editor, Maven, pip, or tests.
Loading…
ENGINEERED BOOTCAMP / LINUX / NATIVE SHELL
Use your maintained Linux distribution as the host, its package system for supported tools, and a user-owned workspace. Match every instruction to the exact distribution and release.
YOUR BOUNDARY
Run course tools as your normal user inside a home-directory workspace. Use sudo only for a documented system package action, never to run the project, editor, Maven, pip, or tests.
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 the exact Linux host, resources, interface, package family, and privilege boundary from evidence.”
Linux is a kernel family; distributions combine it with different releases, package systems, defaults, and support lifecycles.
Vendor support and installation instructions are usually written for named distributions, releases, architectures, and package families.
Predict what you expect each check to report, but leave every inventory field blank until a command supplies the evidence.
An empty desktop variable in an SSH session describes that session; it does not prove that no graphical desktop is installed.
Describe your distribution tuple, architecture, resources, SSH-versus-desktop evidence, package manager, and sudo boundary without rereading the commands.
GUIDED ACTION
Run these read-only checks one at a time inside the Linux host you chose, before installing anything. If you use a remote VM, connect to that VM first: commands run in Cloud Shell inventory Cloud Shell, not your VM.
DO THIS IN ORDER
Type the command exactly as shown, without copying your prompt or a leading $. If /etc/os-release does not exist, try cat /usr/lib/os-release instead.
cat /etc/os-releaseThis reports the machine architecture that your Linux kernel exposes. You will match it to every later package or container image.
uname -mUse the Mem row, not the Swap row. If free is unavailable, run grep '^MemTotal:' /proc/meminfo and record that fallback output.
free -hPassing $HOME asks df about the file system that contains your home directory instead of listing unrelated mounts.
df -h "$HOME"This checks only the session you are using now. SSH normally creates a text session, even when graphical software is installed elsewhere on the machine.
printf 'Current session desktop: %s\n' "${XDG_CURRENT_DESKTOP:-none (normal over SSH)}"Desktop environments commonly install small .desktop launcher files in this directory. The directory may not exist on a command-line server.
ls -1 /usr/share/xsessionsWayland sessions use a separate conventional launcher directory, so check it independently from X11.
ls -1 /usr/share/wayland-sessionsThis asks systemd which target the machine normally starts toward. If systemctl is not found, record that this system does not expose the check through systemctl.
systemctl get-defaultUse ID and ID_LIKE from /etc/os-release to choose the first package manager to test. For Debian or Ubuntu, use the apt-get example below. For another distribution family, use that distribution's official documentation and replace apt-get with its named manager.
command -v apt-getThis checks only command availability. It does not ask for elevation or prove that your account is authorized.
command -v sudoRun these two lines together. sudo executes the harmless true command; -n forbids any prompt. The next line prints the previous command's exit status.
sudo -n true
printf 'sudo check exit: %s\n' "$?"Before each later installation, open that step's official vendor link and check your exact distribution release, architecture, and package family. Record the page URL, the date checked, and supported or unsupported. A generic Linux badge is not an exact match.
WRITE DOWN THESE FIELDS
CHECK BEFORE STEP 02
Step 01 is complete only when every field above has an observed value or an explicit not detected result, and the next tool's official documentation supports your exact distribution, release, architecture, and installation method. Keep the record private and redact usernames, hostnames, IP addresses, and account details before sharing it.
STEP
02
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 beneath your home directory, verify that your normal user owns it, and open it without sudo. Keep its absolute path only in the private decision record and use repository-relative paths everywhere else.
CHECK BEFORE STEP 03
Your normal user can create and edit files there, and a tracked-file search finds no personal absolute path.
STEP
03
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
Use your distribution's maintained OpenJDK 17 package or Eclipse Temurin's matching DEB, RPM, or APK instructions. Select the JDK rather than a runtime-only package. After installation, open a new shell and verify both java and javac report major version 17.
CHECK BEFORE STEP 04
The official source supports your host, and a new shell reports Java 17 for both java and javac from locations you recognize.
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
Check your maintained distribution repositories first. If they do not provide Python 3.14, follow uv's user-space Python installation guide or move to the recorded fallback. Keep /usr/bin/python and any package-manager dependency untouched; the project selects its own interpreter.
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 Git Linux page for your package family, verify the resulting version, and configure only your own commit identity. Record when the distribution intentionally ships a version older than upstream; do not add a third-party repository merely to chase a number.
CHECK BEFORE STEP 06
Your chosen shell finds one maintained Git installation and new commits contain only the identity you intentionally configured.
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
Use the installed Python 3.14 interpreter to create .venv. Activate it, install pytest through python -m pip, and run the tests as your normal user. If any generated file is owned by root, stop and correct the ownership cause before continuing.
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
RESTART 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 the terminal, open a new one, return to the workspace, and rerun the Java, Python, Git, and virtual-environment checks. Record resolved executable paths privately so you can diagnose a later PATH change.
CHECK BEFORE STEP 08
A newly opened standalone shell finds the intended executable and version without repeating an unrecorded setup command.
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
Run ./mvnw for Task 2. Record Docker and PostgreSQL only if present. Before Week 14, confirm that Docker Engine and minikube support the exact distribution, architecture, resources, and driver you plan to use; defer installation until those modules.
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
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
Use Codespaces if your distribution is unsupported, Python 3.14 has no reasonable user-space path, install privileges are unavailable, or later container resources fail. Use another supported local OS when required desktop, device, or accessibility software is the blocker.
SWITCH PATH