Learning path / 01

System engineer foundations

Follow a browser request, understand virtualization and cloud models, then build Linux, networking, shell, and Git skills.

42 items available10 modules · Learn at your own pace

Start first module

Before you begin

A web browser for the opening walkthrough; no cloud account or Python required.
Use a terminal for the later Linux exercises; prepare OrbStack on a Mac or an equivalent Linux environment in the virtualization module.
Use a regular Linux user account; a full VM is needed for independent kernel and boot exercises.

Your learning progress

0 of 42 available items completed

Self-reported progress. Planned modules are excluded.

Loading saved progress…

Back up or restore this path

Progress and notes stay in this browser. A backup contains only this learning path.

Choose backup

The learning sequence

Explore a module to see its bites and proposed checkpoint.

01From Google Search to a website responseFollow learnwithsk.dev from a search query to DNS, packet routing, HTTPS, and a rendered page.Available

Module checkpoint

Distinguish search and site traffic, draw the packet/response path, and record browser evidence without assuming the hosting topology.

02Virtualization and Linux machine lifecycleCompare hypervisors, VMs, and containers; prepare an OrbStack machine and rehearse controlled patching.Available

Module checkpoint

Record the machine identity, package update, verification, and recovery results. Explain which kernel the machine shares.

03Cloud concepts — public, private, and hybridCompare deployment and service models before deciding who operates each part of a website.Available

Module checkpoint

Write a hosting decision and responsibility map for your personal site without creating cloud resources.

04Linux filesystem and permissionsFind files, explain access, and investigate a permission failure without broad permission changes.Available

Module checkpoint

Record the failure, the smallest effective change, verification, and cleanup.

05Processes, services, and logsFollow a running process and understand how services start, stop, and report failures.Available

Module checkpoint

Explain why a service failed using its exit status and logs, then verify recovery.

06Storage and system maintenanceConnect files to filesystems, capacity, and installed software.Available

Module checkpoint

Distinguish space exhaustion from inode exhaustion and use your findings to propose a repair.

07Networking for service operatorsTrace a request through addressing, resolution, connection, and HTTP.Available

Module checkpoint

Isolate a DNS, connection, or application failure with observations from each layer.

08Users and remote accessUnderstand identities and restrict access to the work that needs it.Available

Module checkpoint

Document an SSH access setup and recovery procedure in the disposable VM.

09Shell automationTurn repeatable terminal work into small scripts with understandable failure behavior.Available

Module checkpoint

Write a diagnostic script that reports failures and avoids changing the inspected system.

10Git and engineering collaborationTrack changes and recover from mistakes while collaborating.Available

Module checkpoint

Make a reviewed change and demonstrate recovery without rewriting shared history.

Start with a request

Jump to interview prep arena

Begin with what happens when you type learnwithsk.dev in Google Search?. Separate the search request from the website visit, then follow DNS, traffic and packet routing, the seven-layer model, HTTPS, and the response back to the browser. The opening observation lab uses your browser; it does not need a VM or a cloud account.

The first four modules follow this sequence:

Order	Module	Why it comes here
1	From Google Search to a website response	Establish the end-to-end request and response before troubleshooting individual components
2	Virtualization and Linux machine lifecycle	Understand the execution boundary and prepare the disposable learning machine
3	Cloud concepts — public, private, and hybrid	Separate hosting/service models and assign operating responsibilities
4	Linux filesystem and permissions	Work with the files and identities needed to operate your own site

Then continue through processes and services, storage and maintenance, deeper networking, users and access, shell, and Git. The opening module gives you the overall request path; the later networking module helps you investigate it with Linux tools and a local server lab.

On a Mac, use the OrbStack setup bite in module 2 before the Linux terminal exercises. Keep Linux fixtures inside the machine’s home directory. OrbStack machines share a Linux kernel; use a full VM for independent guest-kernel, bootloader, and disk-layout experiments.

All ten modules are available: 30 learning bites, ten module labs, a personal-site guided project, and the original permission revision checkpoint (42 items). Each bite includes an explanation, an exercise or investigation, and revision prompts. Content is documentation-reviewed; publication does not mean every Linux/OrbStack exercise has been execution-verified.

Learn the model before the diagnosis

The filesystem lessons begin with paths, directories, file types, and links before access failures. Permissions include annotated listings, numeric modes, and creation defaults. Process and service lessons explain the command output before the recovery lab. Shell starts with argument expansion, conditions, loops, and streams; Git starts with a staged-versus-working-file experiment before review and reversal.

Use the request, kernel, permission, and DNS diagrams with their reading guides. Predict an example's result, then compare your observation with its answer explanation. Each small exercise is practice for the larger personal-site project, not a claim that the site already works.

Advanced work remains optional: independent kernel/boot repair and writable LVM experiments need a suitable full VM; fleet patching, detailed performance profiling, production SSH hardening, large shell frameworks, and complex Git history surgery go beyond these core labs. The interview arena includes deeper discussion prompts, so identify what further measurement or practice an answer would need.

A working rhythm

Read one bite, predict what a command will reveal, then run the corresponding lab step. Keep the observation and your explanation together. The checkpoint is a self-assessment: a completed checkbox records your decision, not an independently verified qualification.

By the end of this path, you should have a locally hosted learning site with your lab notes, a startup and recovery runbook, and reviewed Git changes. Use the module checkpoints to record what you have tried and what happened. Python comes next in DevOps foundations.

With 16 GB RAM and 512 GB host storage, start with one Linux machine and run one deployment track at a time. Stop unused environments and measure actual host memory pressure and free disk space before adding databases or clusters.

Guided project: your personal learning site

Create a personal blog, static profile, or simple PHP website where you showcase evidence from this path and other courses. Choose one format. A static page is the smallest starting point; a Markdown-based blog is useful if you want to keep publishing notes through Git commits. Keep the source in Git and the local runtime in your OrbStack learning machine.

Start with the personal-site project guide, then return to each module as you improve the site. No Docker, cloud account, LocalStack, database, or Python is required for this foundations project.

Foundation	Apply it to your site	Evidence to keep
Browser request journey	Compare search traffic, the site document, and one asset	Observed URLs/status/protocol and a labeled packet/OSI diagram
Virtualization and patching	Prepare the OrbStack machine and rehearse a controlled package update	Machine identity, reviewed patch, recovery-copy result
Cloud concepts	Compare local hosting with a future cloud option	Deployment/service model, responsibility map, and explicit unknowns
Files and permissions	Separate served content from private notes and inspect the runtime account's access	Ownership/mode record and a scoped access repair
Processes and logs	Start, stop, and optionally supervise the local site process	Failure timeline and repeatable startup/recovery steps
Storage and packages	Identify the site's filesystem and its runtime dependencies	Capacity/inode observations and package inventory
Networking	Trace browser → local listener → page response	Bind address, port, HTTP result, and missing-path diagnosis
SSH and identity	Document access to the machine hosting the site	Intended account, transport, and independent recovery route
Shell	Build a read-only check that distinguishes success from failure	Input/output contract and test evidence
Git	Review a site update and rehearse a reversal	Focused commits, review notes, and a recovery commit

Publish what you actually observed: environment, task, change, result, recovery, and limitations. Course checkboxes alone are not evidence of a skill. Public hosting is optional; the guide first establishes a working local site and explains the difference between static hosting and PHP execution.

Source and adaptation

Curriculum adapted from the collaborative Compute Central foundations material↗, with permission. Topic coverage informs this sequence; explanations, fixture exercises, and checkpoints are newly written for LearnWithSK rather than reproduced chapter text. The opening request journey uses Google Search documentation, IETF protocol specifications, the ITU OSI reference, and browser documentation. Cloud concepts use NIST and provider documentation. Virtualization and OrbStack guidance also use the primary product documentation. Technical references appear in each published lesson. This source snapshot identifies the material reviewed; it does not establish that every source example was tested.

Continue the project

Continue to DevOps foundations to introduce MicroBank after learning automation, cloud concepts, containers, and LocalStack. Keep your personal site as the place to publish what you learn. Build, Break & Operate follows the later application and platform implementation.

Interview prep arena

Practice with your personal site and Linux lab. These are discussion prompts, not claims about particular employers. Start with a symptom, gather evidence, compare explanations, choose a reversible action, then verify recovery. Record what you actually observed; a lab example should be described as a lab.

Choose a round: Linux diagnosis · Networking and Git · Project evidence.

Linux diagnosis

Revisit processes, logs, storage, and network diagnosis.

SYS-01. Resource usage and a slow application

How would you investigate high CPU or memory usage? What changes when CPU is only 30% but the application is slow? Compare per-process and per-core activity, runnable versus blocked work, I/O waits, swap activity, and response timing. Explain which observation would distinguish a compute bottleneck from waiting on a disk, lock, network, or dependency. An aggregate utilization number does not settle the diagnosis.

SYS-02. Disk capacity and I/O failure

Disk usage reaches 95% and the application starts failing. What do you inspect before deleting anything? Distinguish full filesystems, exhausted inodes, slow I/O, read-only mounts, and deleted files still held open. Identify the mount and owning process, preserve useful incident evidence, and propose a scoped cleanup or capacity change with a recovery check.

SYS-03. A process is killed unexpectedly

How would you distinguish an application exit, an OOM kill, a signal, and a service-manager restart? Correlate exit status, service history, kernel messages, and resource limits. Missing application errors do not prove the application was healthy. Explain what evidence you would preserve before restarting it.

SYS-04. Memory grows over several days

How would you separate a leak from caching, traffic growth, and allocator behavior? Compare the same workload over time, process RSS and relevant runtime measurements, and behavior after traffic subsides. State what extra profiling you need before claiming a leak; a single memory screenshot is insufficient.

SYS-05. Host or application unreachable

The server responds, but the application does not. How does your investigation change if the whole server becomes unreachable? Work through name resolution, route, packet loss, firewall, listening socket, bind address, service status, and application response. For a completely unreachable host, use available console or provider evidence to separate network failure from OS failure. Test from the affected client's network as well as locally.

Networking and Git

Revisit the opening request journey, packet/OSI model, ports and sockets, DNS, HTTP and proxies, and Git review.

SYS-06. TCP and UDP

Compare TCP and UDP, and explain a use case you have actually observed for each. Discuss connection state, ordering, retransmission, message boundaries, and application responsibilities. DNS can use both transports; avoid reducing the distinction to “web versus DNS.” If you have no production example, inspect a bounded local request and label it accordingly.

SYS-07. DNS resolution from the client

Trace a DNS lookup step by step. Where can caching or a wrong answer occur? Distinguish local resolver/cache behavior, a recursive resolver, authoritative servers, referrals, record types, and TTLs. Explain why a cached answer can avoid parts of the full lookup and how you would compare application behavior with a direct DNS query.

SYS-08. Load balancer and reverse proxy

What responsibilities do a load balancer and reverse proxy perform in your site's request path? Draw browser → DNS → TLS endpoint → proxy → application and identify the listening ports and failure boundaries. A component may perform both roles. Add Kubernetes Ingress only after the Advanced request-flow question; the Linux site does not require a cluster.

SYS-09. Merge and rebase

How do Git merge and rebase differ in the commit graph? Sketch a diverged branch, a possible merge commit, and replayed commits with new identities. Include fast-forward behavior, conflict handling, recovery, and why rewriting a shared branch requires coordination. Demonstrate on disposable branches, not another contributor's active history.

Foundation project evidence

These optional projects give you more examples to discuss. Choose one that interests you and record what you actually try; they are not additional completion requirements.

Project idea	Practice and evidence
Nginx reverse proxy for a personal site	Extend the personal-site project; explain one successful request and one upstream failure.
Linux log analyzer CLI	Use text pipelines to summarize a small sanitized log fixture; state malformed-line behavior. Python belongs in the next path.
Simple cron automation	Optional extension of the shell lab: schedule a harmless local report, account for the reduced environment and overlapping runs, then remove the schedule.
Shell backup and cleanup	Use a disposable site directory; prove a restore before proposing retention cleanup. A successful copy alone is not restore evidence.
Service health-check script	Extend the network lab with bounded timeouts and useful exit codes; distinguish connection success from an expected response.

Primary reading: Linux pressure stall information↗, systemd service execution↗, DNS concepts↗, and Git branching and rebasing↗. Continue with the DevOps foundations arena after its Python, cloud, and delivery modules.