Cybersecurity Track
The path from a first shift on a security team to shipping code that holds up. Below you can read what each stage covers, what it assumes you already know, and where it points next.
Four stages · SOC fundamentals · Cloud security · Secure delivery
Who this track is for
This is a working path for people who want to hold a security job, not collect a certificate and stop. If you are moving out of IT support, finishing a degree, or returning after a break, the track assumes you can already read a command line, understand what an operating system does with a process, and follow a written procedure without hand-holding. It does not assume you have worked on a security team before.
Read the four stages in order. Each one ends with a piece of work you produce yourself — a written triage note, a hardened configuration, a review of a change request, a short incident writeup. Those artifacts are what a hiring manager can look at, so we build the track around producing them rather than around watching lectures.
If you already work on a security team and want to move toward cloud or application security, you can start at stage three — the first two stages are where newcomers enter, and they cover material you likely already use daily.
The four stages
What the track covers, stage by stage
Four stages, each with a target role in mind. The ledger below lists what you study, what you build, and what a reader of your work will expect to see.
Stage one
SOC fundamentals
Target role: SOC analyst, tier one
You learn how an alert travels from a log source to a queue, how to read a ticket without guessing, and how to tell a false positive from something worth escalating. The work covers log formats you will actually meet, the difference between an event and an incident, and how to write a triage note a shift lead can act on. You finish with a written assessment of a set of events, including the reasoning behind each call you made.
Stage two
Security+ preparation
Target role: junior security generalist
A structured pass through the domains an entry-level security role expects you to reason about: access control, cryptography in practice, network and host hardening, risk language, and incident response basics. We read the objectives, then work through scenarios so the terms have somewhere to land. Exam scheduling, fees, and pass rules belong to the certification body, not to us — we prepare the material and tell you honestly where your practice scores are still thin.
Stage three
Cloud security
Target role: cloud or platform security analyst
Cloud changes the shape of a security job, so this stage changes with it. You work through identity and permission design, logging and monitoring in a hosted environment, network boundaries, storage exposure, and the review habits that keep a growing account from drifting open. The lab work is done in a real account you control, with a written configuration review as the deliverable at the end.
Stage four
Secure software delivery
Target role: application or DevSecOps engineer
The last stage moves security into the build itself. You add dependency and secret scanning to a pipeline, write review comments that a developer can act on, set up a staging check that fails loudly when something is wrong, and learn how to say no to a release without stalling the team. You finish with a documented review of a change request, including the checks you ran and the risks you accepted.
How a stage is structured
Every stage runs the same way, so you always know what the week looks like. Short readings set the vocabulary. A lab session makes you use it. A review session is where we look at your work together and name what is missing. Then you produce the deliverable and move on. Nothing is graded on how fast you finish; the pace is yours, and the review sessions are where most of the learning happens.
Lab sessions use real equipment you configure yourself. Written notes from each session become part of your portfolio by the end of the stage.
Hands-on work
What you will actually build
Labs are where the material stops being vocabulary. You stand up a logging pipeline and watch it collect from a host you configured. You write a rule that fires on the wrong thing first, then fix it. You build a permission policy, review it a week later, and find the assumption you made. None of these run on a simulated diagram — you work against a system, break it safely, and write down what you learned.
- A logging pipeline you configured and can explain end to end
- A cloud account with a documented permission and boundary review
- A pipeline with dependency and secret checks running on every change
- Written triage notes and review comments a lead can act on
Does it prepare you for the role you want?
Four common entry points. Find the row that describes you and read what the track assumes, what you would produce, and where it points next.
Coming from IT support
You already know how machines fail and how to talk to users. Start at stage one and move fast through it; the vocabulary will be new but the instincts are not. Your deliverable will show a hiring manager you can reason about events, not just read a screen.
Coming from a CS degree
You can code, so stages three and four are where the value sits. Stage two fills in the security vocabulary your coursework skipped. Expect the lab work to feel uncomfortable at first — writing is as much the deliverable as running the tool.
Already on a security team
Skip to stage three if you want cloud security, or stage four for application work. The early material will be familiar, but the review habits and the writing expectations in the later stages are usually where the real gap is.
Not sure which row fits? The course tracks page lays the three tracks side by side so you can compare what each one prepares you for.
Compare the tracksWhat you leave with
A stage is done when you can show the work, not when you finish a video. Here is what sits in your hands at the end of the track.
These are working documents, not trophies. They are meant to be read by someone who will ask you why you made a call, and you will be able to answer, because you made the call yourself and wrote the reasoning down. We do not grade them for polish — we read them for whether the reasoning holds.
Before you start
Set aside a regular block of time each week — six to eight hours is enough to move steadily through a stage. Install the tools you will use on your own machine so the labs are not the first time you touch them. Keep a running notes file from the very first session; the reviewers will read it, and you will thank yourself later.
If you are weighing this track against the DevOps and cloud or AI and MLOps tracks, read the course tracks page first — the first stages overlap in places, and it is worth knowing which direction you are pointing before you commit. If you have a question about fit, the team answers email during working hours and will tell you honestly if a different track is the better starting point.
Questions people ask before enrolling
Do I need prior security experience?
No. Stages one and two assume you can use a command line and understand how an operating system works, but they do not assume you have worked on a security team. If you are comfortable with the everyday tools of IT work, you are ready to start.
Does the track include certification exams?
No. Stage two prepares you for the Security+ material, but the exam itself is scheduled, paid for, and passed through the certification body. We tell you where your practice scores are thin so you know when you are ready to book it — we cannot schedule or guarantee the outcome for you.
How long does each stage take?
It depends on the hours you can give it. At six to eight hours a week, most learners move through a stage in a matter of weeks rather than days, and the later stages take longer because the deliverables are bigger. We do not publish a fixed schedule because a rushed stage shows in the work.
Can I skip straight to the cloud or delivery stages?
Yes, if you already work on a security team or have a computer science background. Talk to us first — we will ask what you have done and tell you honestly which stage is the right entry point for you. Skipping a stage you needed is the most common way people struggle later.
What happens if I get stuck in a lab?
You bring the problem to a review session and we work through it with you. Getting stuck on a lab is normal and usually the point — the fix is to describe clearly what you tried and where it stopped making sense. That habit is the same one a real security team will expect from you.
Still deciding if this is the right track?
Ask a question and we will answer it plainly — including if the answer is that a different track suits you better. Or compare the three tracks side by side and see which one lines up with the role you are aiming at.
Email us at info@rob-inhood.digital, or call +1-415-555-0192 during working hours, Monday to Friday, 9:00 AM – 6:00 PM.