1 Linux Server & SSH
Build LINUX01 using a common distribution (Ubuntu Server, Debian, Rocky Linux, AlmaLinux — and if you're interested in Red Hat enterprise environments, get comfortable with the RHEL ecosystem too). Configure static IP, hostname, DNS, SSH, users, groups, permissions, firewall, services and logging, using tools like ip addr, ip route, ping, ss -tulpn, systemctl, journalctl, df -h, free -m, top, ps, chmod, chown, grep, and find.
Enable SSH and connect from another machine (ssh student@linux01). Understand password authentication versus SSH keys (public key, private key, known_hosts, authorized_keys), then configure key-based authentication yourself — this exact pattern shows up constantly in Linux administration, cloud engineering, DevOps, automation, and cybersecurity.
2 Linux Web Server & PKI
Install Nginx or Apache and get http://linux01 working, with DNS pointing intranet.corp.cybersecuritycafe.lab at the Linux server — now you can see DNS, networking and web services working together in one request. Add HTTPS next.
Certificates are frequently misunderstood by junior engineers, and the lab is a perfect place to fix that: private key, public key, certificate, Certificate Authority, CSR, subject, SAN, expiration, trust chain, root CA, intermediate CA. If you want to go further, install Active Directory Certificate Services, create an internal CA, and issue certificates for web servers, users, computers and applications — then configure HTTPS for https://intranet.corp.cybersecuritycafe.lab using one of them.
You deliberately let a certificate expire, then browse to the site. What error should you expect — and how is that different from a hostname mismatch, an untrusted CA, or an incomplete certificate chain?
Reveal the answer
Expiry gives a clear "certificate expired" warning tied to the validity dates. A hostname mismatch triggers a different warning because the browser is comparing the URL against the certificate's Subject/SAN, not its dates. An untrusted CA fails because the client doesn't have that CA in its trust store at all — common for internal CAs on devices that were never given the root certificate. An incomplete chain fails because the server didn't present the intermediate certificate(s) needed to link the leaf certificate back to a trusted root. All four look similar to a user ("the padlock is broken") but point at completely different fixes — and all four happen constantly in real enterprise environments, which is exactly why it's worth breaking each one deliberately here.
3 Database Servers: SQL Server, SQL Basics & Oracle
Almost every significant enterprise application eventually talks to a database, so build DB01. Microsoft SQL Server is a strong choice if you're interested in Microsoft enterprise environments — learn databases, tables, rows, columns, primary/foreign keys, indexes, logins, database users, roles, permissions, and backups. Create an Employees database with an Employees table (EmployeeID, FirstName, LastName, Department, Email, StartDate) and practice basic SQL:
SELECT * FROM Employees;
SELECT FirstName, LastName
FROM Employees
WHERE Department = 'IT';
INSERT INTO Employees (FirstName, LastName, Department)
VALUES ('Alice', 'Smith', 'Finance');
UPDATE Employees
SET Department = 'Security'
WHERE EmployeeID = 5;You don't need to become a database developer, but this level of SQL is valuable across technical support, application support, IAM, SOC, cybersecurity, DevOps and data engineering. Oracle is also worth understanding — it remains heavily used in banks, telecommunications, government, airlines, healthcare, insurance and large enterprise applications. A learning edition (Oracle Database Express Edition or another suitable development offering, where licensing and platform support permit) is enough to get comfortable with database/instance/schema/tablespace/datafile/control file/redo logs/listener/service name/SID/users/roles, SQL*Plus, and connection details like hostname, port, service name, username and password — historically a listener defaults to TCP 1521, but treat that as configurable, not guaranteed.
4 Database Security & Troubleshooting
Create separate accounts — application_user, database_admin, reporting_user — and don't give everything administrative privileges: application account gets SELECT/INSERT/UPDATE, reporting account gets SELECT only, DBA gets administrative privileges. This is least privilege again, and it directly answers a question worth internalising: why an application should never normally connect to a production database using a DBA-level account.
Three deliberate failures: (1) the application can't connect to the database at all; (2) authentication fails; (3) the application becomes slow. What's your checklist for each?
Reveal the checklists
Can't connect: DNS, network, firewall, port, database listener, credentials, database permissions, database availability — work outward from the client, same layered approach as Module 16.
Authentication fails: wrong password, locked account, expired account, missing database role, wrong service — note this overlaps heavily with the login-troubleshooting checklist from Module 9/16, because databases authenticate too.
Slow application: CPU, RAM, storage, network, connections, query performance, indexes, logs. The core lesson across all three: "database problem" does not automatically mean the database software itself is broken — it's often the network, the credentials, or the query in front of it.
5 Docker & Docker Compose
Build DOCKER01, install Docker, and understand images, containers, volumes, networks, ports, registries, and environment variables. Start with docker run hello-world, then deploy a real web server, and internalise the relationship: Docker image → container → application.
Then learn basic Docker Compose by wiring together a small multi-service application — a web application, a database, and a reverse proxy (Frontend → Nginx → Application → PostgreSQL is a common shape). This is exactly the architecture pattern behind most modern web applications, and it sets up the DMZ/reverse-proxy work in Lesson 5.
6 Legacy Servers vs. Containers
Compare three deployment models directly: traditional (physical server → OS → application), virtualised (physical server → hypervisor → VM → OS → application), and containerised (physical server → OS → container runtime → containers). Enterprise environments frequently run all three at once — a global bank might have 20-year-old legacy applications, VMware-hosted Windows applications, modern Kubernetes applications, and cloud SaaS services simultaneously. Recognising which model you're troubleshooting in matters more than having a strong opinion about which one is "best."