Practice securing live Linux hosts and Docker workloads through 30 focused DevSecOps challenge labs. Across six progressive stages, you will inspect real runtime state, identify an unsafe exposure or privilege boundary, apply a targeted correction, and prove that the protected application still works.
This intermediate path emphasizes operational hardening rather than security theory or step-by-step instruction. The Linux half covers services, web content, permissions, identities, secrets, and privileged automation; the Docker half moves from runtime audits to least privilege, Compose isolation, image hygiene, and incident cleanup.
What You Will Learn
After completing this course, you will be able to:
- Audit listening sockets, host bindings, web directory behavior, and exposed artifacts to establish an accurate Linux exposure baseline.
- Tighten secret, upload, environment, and log permissions without breaking the service users and write paths that legitimately need access.
- Move services away from root, assign dedicated identities, and preserve the ownership boundaries required for configuration and logging.
- Remove credentials from scripts and process environments, narrow an overly broad sudo rule, and harden command resolution and root-run cron paths.
- Inspect Docker and Compose runtime facts including images, published ports, users, mounts, environment values, volumes, and networks.
- Reduce container privilege with read-only mounts, non-root users, removal of privileged mode and Docker socket access, and narrowly scoped secrets.
- Segment Compose networks, remove runtime and build-time token exposure, pin a base image, and clean up temporary incident overrides.
- Verify every hardening change through process, permission, HTTP, container, image-history, and service-connectivity checks.
Who This Course Is For
This course is for learners with Linux and Docker fundamentals who want realistic practice reviewing and correcting common operational security drift. It suits aspiring DevSecOps engineers, platform engineers, and operations practitioners who can follow a security requirement but need more experience preserving application behavior while reducing exposure and privilege.
Prerequisites: You should be comfortable navigating Linux, editing configuration and shell files, interpreting permissions and process output, using sudo, and running basic Docker and Docker Compose commands. The challenges provide requirements and hints, but they do not teach these foundations from scratch.
Learning environment: The first 15 challenges use provided Ubuntu 22.04 terminal environments; the final 15 use supplied Docker-capable Ubuntu 22.04 environments with prepared applications, images, scripts, and Compose stacks. All targets are local to the labs, and no external cloud, registry, or production system is used.
Frequently Asked Questions
Is this a guided security course or a challenge-based practice path?
It is challenge based. Each lab defines the scenario, target state, requirements, hints, and validation, while you decide which runtime evidence to inspect and which focused change to make. A guided Linux and Docker fundamentals course is a better starting point if those tools are new to you.
Does this course cover vulnerability scanning and the full DevSecOps software lifecycle?
No. The scope is deliberately concentrated on operational misconfiguration in Linux and Docker: network exposure, permissions, identities, secrets, least privilege, Compose isolation, image cleanup, and post-incident drift. It does not teach SAST, dependency scanning, cloud IAM, or end-to-end security pipeline design.
Do I need a cloud account, container registry, or my own Docker host?
No. The required Linux services, containers, images, and Compose projects are already prepared in isolated lab environments. You will not push images to an external registry or modify a real production host.
Must I complete one challenge every day?
No fixed schedule is enforced. The 30 challenges are ordered as a progressive 30-day practice route, but you can use another pace. Keeping the stage order is recommended because later container challenges assume confidence with inspection, least privilege, and verification.
