From shift work to security work.

CAREER TIMELINE / FIRST FULL GUIDE — OCTOBER 14, 2026 · ~10 MIN READ

How long does it take to become a SOC analyst with no experience?

I asked this exact question when I started. The internet answered with everything from "90 days" to "you need a degree and years of experience." Neither was useful. Here is the honest version: the real range, what fills it, and the shift-worker's math for getting there.

Why I'm qualified to write this (and why I'm not a SOC analyst yet)

I'm a shift supervisor studying cybersecurity between shifts: CompTIA A+ certified, a couple of years of remote tech support behind me, and a WGU cybersecurity degree in progress. I am documenting the path in, not speaking from a finish-line podium. What I can honestly give you is the research, the plan I'm following, and the proof as I build it — not a success story I haven't lived yet.

What actually fills those months

The timeline isn't one big block of "studying." It breaks into four buckets, and most of them overlap:

• IT foundations (1–3 months with A+; 2–4 without). Networking, operating systems, troubleshooting. Security is layered on top of these; a weak floor turns every later topic into memorization. My A+ got this mostly covered — this is phase one of the 90-day roadmap. For networking review, I recommend this CompTIA Network+ study guide (affiliate link).
• Security fundamentals and Security+ (2–4 months). The baseline cert most junior postings ask for. No prerequisites, and it's the fastest credential that HR departments actually recognize. For a study guide, I recommend Darril Gibson’s Get Certified Get Ahead (affiliate link).
• Hands-on proof (runs alongside everything, 2–6 months). Labs, documented investigations, SIEM practice. This is the bucket most beginners under-invest in — and it's the one interviewers care about most. For deeper web application security study, I recommend The Web Application Hacker's Handbook (affiliate link).
• The job search itself (1–3 months). Applications, screening calls, technical interviews. Budget for this; nobody's timeline ends the day they pass Security+.

If you're choosing what to study after A+, I put the Security+ vs CySA+ decision through the same role-first filter I'd use myself: read the postings, count what repeats, pick the exam that fills the gap.

The shift-worker's math: hours matter more than months

"6–12 months" assumes something like 10–15 focused hours a week. That's the part nobody advertises. The same calendar period means very different things depending on your week:

• 15 hours/week (study blocks protected around shifts, like the between-shifts system I'm using): ~9 months from zero is realistic.
• 8 hours/week: expect closer to 12–15 months — not because you're slower, but because the arithmetic is just slower.
• Under 5 hours/week: you will forget faster than you learn, and the timeline stops being meaningful. Fix the schedule before buying anything.

My honest position: on heavy work weeks I hit 8, on good weeks 15. So I plan on the longer end and treat anything faster as a bonus. Don't compare your month six to someone else's month six.

What doesn't count as progress

• Passive video watching. If you can't retrieve the concept tomorrow without the video, it didn't happen.
• Collecting credentials by habit. A second cert before you have proof of the first one is usually procrastination with a receipt.
• Paid bootcamps as shortcuts. Structure can help, but thousands of dollars don't compress the hands-on hours. Nothing on this site will tell you a price tag replaces reps.

What actually speeds things up

Three things move the needle more than any study hack. First, existing troubleshooting experience — if you've done any kind of tech support, that transfers directly to alert triage, which is the core SOC analyst job. Second, documenting your labs in public: write the walkthrough, keep the screenshots clean, build the portfolio before anyone asks for it. Third, applying early: "entry-level" postings listing 1–2 years of experience are often wish lists, and every interview teaches you what to study next.

The practice that has moved the needle most for me is guided labs with actual feedback. I started on TryHackMe's free rooms (my TryHackMe link — note: this will be an affiliate link once the program approves this site) because the SOC-focused paths walk you through real investigations instead of throwing you into a terminal. Free tier first; pay only when the learning path matches your target role.

My plan, stated plainly

A+ is done. The degree is in progress (my honest WGU notes are in the library). I'm working through the 90-day roadmap phases — foundations, practice in public, aim at a role — with Security+ as the current target and the CySA+ decision made the role-first way when I get there. The one-week proof I ship is a lab note or a write-up. No shortcuts, no expensive promises, just the system.

The bottom line

Stop asking "how long" as if the calendar decides. Ask instead: how many focused hours can I protect each week, and what proof will I have at the end of them? Six months of documented labs beats twelve months of half-watched videos. Pick the pace you can repeat after a hard shift, then start the clock.

Keep reading: certification decisions, guide library, 90-day roadmap, whether A+ is worth it in 2026, how long Security+ takes while working full-time, whether you need a degree for cybersecurity, TryHackMe vs Hack The Box for absolute beginners, whether WGU cybersecurity is worth it, Security+ vs CySA+ — which one after A+, Network+ vs Security+ — which one first?, is Security+ worth it in 2026?, what is a realistic A+ study plan with zero IT experience?, how do you get cybersecurity experience when every entry-level job asks for experience?, how do you study for Network+ while working full-time?, what does a SOC analyst actually do all day?, CompTIA A+ vs Google Cybersecurity Certificate: which should you do first?, how to pass Network+ — the ports and cables drill method, subnetting for Network+ — turn a mask into CIDR in two checks, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate note: This article contains a placeholder affiliate link to TryHackMe. Per this site's disclosure policy, recommendations that may earn money are disclosed next to the recommendation, and no real affiliate links exist on this site until each program approves it.

DEGREE / CAREER GUIDE — OCTOBER 16, 2026 · ~8 MIN READ

Do You Need a Degree to Get Into Cybersecurity? An Honest Answer

Every week somebody asks me some version of this: "Do I need a degree to get into cybersecurity, or are certifications enough?"

I asked myself the same thing before I did anything. I was working as a shift supervisor, no IT degree, and I wanted to know if I could get hired on certs alone — or if I was going to have to spend four years in college first.

Here's the honest answer: you do not need a degree to get your first cybersecurity job. But a degree opens doors that certs alone don't, and it protects you later in your career. Let me break down exactly where it matters and where it doesn't.

What employers actually hire for

When a hiring manager looks at a SOC analyst resume, they're looking for three things:

1. Can you do the work? (skills — networking, logs, incident triage)
2. Can you prove it? (certifications, home labs, projects)
3. Will you show up and learn? (work history, attitude)

None of those require a degree. I know this because I'm living it — I earned my CompTIA A+ while working full-time, built my own study plan around my actual job hours, and I'm documenting the whole path in my 90-day roadmap.

Entry-level certs like Security+ carry real weight. Hiring managers filter resumes for them. TryHackMe's SOC Level 1 rooms prove you can actually triage alerts. None of that needs a bachelor's.

Where a degree actually matters

That said, there are four places a degree genuinely helps:

1. Government and defense jobs. If you ever want to work for the DoD or a contractor, Security+ plus the right degree checks boxes that nothing else does. Some of those roles literally require a degree in the posting.

2. HR keyword filters. Big companies run resumes through automated filters. "Bachelor's degree or equivalent experience" is the most common line you'll see. "Equivalent experience" is doing real work here — two or more years of IT support counts. But the degree makes it automatic.

3. Promotions. Getting in without a degree is one thing; getting promoted to senior, lead, or management is where the degree quietly becomes the tiebreaker between two good candidates.

4. Visa and relocation paths. If you ever want to work abroad, many countries score degrees directly. Niche, but real.

Why I'm getting the degree anyway (while applying for jobs without it)

Full honesty about where I am: I'm a WGU cybersecurity student, CompTIA A+ certified, working toward the degree while applying for entry-level roles right now. I'm not waiting four years to start my career.

My logic was simple:

• Certs get me in the door now (Security+ is the target — see my guide on picking your first cert)
• The degree protects me later — promotions, management, federal work
• WGU is competency-based and affordable, and I can study around a job — no quitting work to sit in lectures

That's the move most people miss: you don't have to choose. Start with certs and get hired, then finish the degree while you're earning. Your employer might even pay for it — tuition assistance is common in IT and security roles, and it's the first benefit you should ask about in interviews.

The money math (real numbers)

Rough, honest costs so you can compare:

• Cert path (first year): Security+ exam voucher around $400, study materials free to $50 (Professor Messer on YouTube is free; a study book runs about $40), TryHackMe premium around $14/month. Total: under $700 to be job-eligible.
• Degree path: a competency-based program like WGU runs roughly $4,000–$4,500 per six-month term. Finish in three to four terms: roughly $12K–$18K. A traditional school: $10K–$40K+ per year.

Neither number includes your time, which is the real cost. Both are cheaper than staying stuck in a job that doesn't pay.

If you skip the degree: your checklist

Do this and you can absolutely get hired:

1. Get Security+. It's the entry-level cert employers actually filter for.
2. Prove hands-on skill. TryHackMe's SOC Level 1 and Pre Security paths — I've been recommending TryHackMe throughout this site (sign up with my link) because it's the fastest way to prove you can do the work before you have the job.
3. Build a home lab. Free: Security Onion or the Splunk free tier, attack yourself with Kali. Write it up — that's portfolio material.
4. Frame your work history. I came from shift supervisor and 2+ years of remote tech support. Customer service, troubleshooting under pressure, documentation — all of it transfers. Don't apologize for non-IT work; translate it.

If you get the degree: don't pay sticker price

• Look at competency-based programs (WGU and similar) where finishing faster costs less.
• File FAFSA. You'd be surprised what you qualify for.
• Ask every employer about tuition assistance — and ask in the interview, not after you're hired.
• A cybersecurity degree specifically beats a generic IT degree for this field, but either works.

The bottom line

A degree is a door-opener and a career shield, not a job ticket. Certs plus proven skills get you the first job. The degree makes the second, third, and fourth jobs easier.

If I had to start over with $0 and a deadline: Security+, TryHackMe daily, home lab, applications — degree in the background once the paychecks start.

Related on this site: 90-day roadmap · Certification decision guides · Full guide library

This site is free to read because of affiliate support. If you sign up for TryHackMe through my link above, I may earn a commission at no cost to you. See the affiliate disclosure for details.

COMPTIA SECURITY+ / CERT GUIDE — OCTOBER 19, 2026 · ~9 MIN READ

Is Security+ Worth It in 2026? An Honest Breakdown for Beginners

Security+ is the cert I get asked about most, and it's the one I'm studying for myself right now — A+ done, WGU cybersecurity degree in progress, squeezing study sessions in around shifts as a shift supervisor. So this isn't a sales pitch. It's the breakdown I wish someone had handed me before I spent money: what the exam actually covers, what it costs, who it genuinely moves forward, and who should wait.

What Security+ (SY0-701) actually covers

The current exam is SY0-701. It's a broad fundamentals exam, not a deep hands-on one — it tests whether you understand security concepts well enough to recognize them in scenarios. Five domains:

• General security concepts (12%). Zero trust, cryptography basics, access control models, security controls and why they exist.
• Threats, vulnerabilities, and mitigations (22%). Malware, phishing and social engineering, application and network attacks, and how you actually respond to each.
• Security architecture (18%). Network design, firewalls, cloud and virtualization security, secure protocols, data protection.
• Security operations (28%). The biggest chunk: identity and access management, monitoring, incident response, digital forensics basics, automation. This is the domain that maps closest to daily SOC work.
• Security program management and oversight (20%). Governance, risk management, compliance, audits, and awareness training — the business side of security.

Two things surprise people. First, the exam includes performance-based questions — short simulated tasks, not just multiple choice — so pure memorization won't carry you. Second, it is genuinely wide and shallow: you'll learn a working vocabulary across all of security, not mastery of any one tool. That breadth is exactly why employers use it as a baseline, and exactly why it isn't enough on its own (more on that below).

Exam cost and format, plainly

• Price: the exam voucher lists at $404 USD on CompTIA's site as of this writing. Student and bundle discounts exist, but verify the exact exam version and the seller before you pay — that rule is in my certification decision guides for a reason.
• Format: up to 90 questions in 90 minutes, a mix of multiple choice and performance-based questions.
• Passing score: 750 on a 100–900 scale.
• Prerequisites: none are enforced. CompTIA recommends Network+ and about two years of IT experience, but nothing stops a beginner from booking it — which is why so many beginners book it too early and fail it.
• Renewal: the certification lasts three years, renewable through continuing education or a higher cert.
• One structural bonus: Security+ is on the U.S. Department of Defense's approved baseline certification list (DoD 8140), which is why it shows up in so many government and contractor postings. If those roles are anywhere in your future, that alone can justify it.

Who it helps most

• Help desk and tech support workers. This is the classic on-ramp, and it's mine: 2+ years of remote tech support taught me troubleshooting and documentation, and Security+ is the credential that translates that experience into "security candidate" for a hiring filter.
• A+ holders aiming at SOC roles. A+ proves you can fix machines; Security+ proves you understand how they're attacked and defended. Together they cover most of what Tier 1 SOC postings ask for on the cert line.
• Career changers with some IT exposure. If you've touched networks, accounts, or systems in any job, Security+ gives that scattered experience a recognized shape.
• Anyone targeting DoD or contractor work, for the baseline-approval reason above.

Who should skip it — or at least delay it

• Total beginners with no IT foundation. If you can't explain what DNS does or how an IP address works, Security+ will feel like memorizing a foreign language. Do A+ (or honest fundamentals study) first — I explain my reasoning in whether A+ is worth it in 2026. The exam will still be there, and you'll pass it in one attempt instead of two.
• People whose target postings don't list it. Pull ten real postings you'd actually accept. If none of them name Security+, the cert is a detour, not a shortcut. This role-first check is the whole point of the decision guides.
• Experienced sysadmins and network engineers moving sideways. Your experience may already outweigh it; CySA+ or a specialization may be the better spend (comparison below).
• Anyone hoping the cert alone gets them hired. Security+ gets your résumé past a filter. Labs, write-ups, and a home lab get you through the interview. If your budget forces a choice between the voucher and months of hands-on practice, practice first, voucher when you're ready.

A realistic study timeline for a working adult

If you're coming in with A+ or help desk experience — the foundations already in place — 6–10 weeks at about an hour a day is a realistic, sustainable plan. That's roughly 45–70 total hours, and it fits around a job because it's a small daily block, not weekend marathons you'll abandon by week three.

• Weeks 1–2: threats, vulnerabilities, and security concepts. Learn the vocabulary; take notes in your own words.
• Weeks 3–5: architecture and security operations — the two heaviest domains. This is where most of your hour a day goes.
• Week 6: governance, risk, and compliance, plus your first full practice exam.
• Weeks 7–8 (up to 10 if you need them): practice exams, review every miss against the objectives, and drill the performance-based question style. Book the real exam when your practice scores are consistently at or above passing — not before.

Coming from zero IT background? Be honest with yourself and double it. I break the hours-per-week math down in how long Security+ takes while working full-time, and the daily study loop lives in the 90-day roadmap. The pace you can repeat after a hard shift beats the pace that looks impressive in week one.

What jobs actually list it

Search any major job board for these titles and you'll see Security+ in the requirements or "preferred" line again and again:

• SOC analyst (Tier 1) — the most common target role for this cert.
• IT security analyst / junior security analyst
• Help desk and IT support roles with a security lean — often the stepping stone into a SOC.
• Systems administrator and junior network/security roles at smaller organizations.
• Government and defense contractor positions at many levels, because of the DoD baseline approval.

Notice the pattern: Security+ is an entry-level filter, not a senior credential. It opens the first door. Nobody is hiring a security architect because of it, and any course seller who implies otherwise is selling you something.

Salary context, without the fantasy

I won't invent a precise number, because precise numbers for "Security+ salary" are mostly marketing. Honestly framed: entry-level security and SOC roles in most U.S. markets commonly post in a band roughly around $50K–$75K, varying a lot by region, shift (overnight SOC shifts often pay a differential), and whether the role is government-contracted. The U.S. Bureau of Labor Statistics reports a median well into six figures for information security analysts as a whole — but that figure covers experienced professionals, not first jobs. The fair way to read it: Security+ helps you enter a field whose ceiling is high; it does not start you at the ceiling.

Security+ vs Network+ vs CySA+: what comes before and after

• Network+ comes before if networking is your weak spot. A large share of Security+ assumes you understand ports, protocols, and network design. If that material makes you sweat, a few weeks of Network+ study (or the exam itself, if a posting asks for it) will make Security+ cheaper in the long run — one pass instead of a retake.
• CySA+ comes after. It's CompTIA's analyst-level cert: more log analysis, threat detection, and incident response depth, aimed at people already in or near security roles. It's a strong second cert for SOC career growth — not a starting point. My Security+ vs CySA+ decision guide runs both through the role-first filter.

The sane default order for a beginner: A+ → Security+ → hands-on proof → CySA+ when your target roles start asking for it.

The bottom line

Is Security+ worth it in 2026? For the help desk worker or A+ holder trying to break into SOC and security roles — yes, it's still the baseline credential those jobs screen for, and SY0-701's heavy security-operations weighting makes it more relevant to real analyst work than older versions. For the true beginner, it's worth it second, after foundations. And for everyone, it's worth it only as part of a package: cert plus labs plus documented proof. That's the path I'm on, and it's the one laid out in the roadmap and the rest of the guide library.

If you want one study resource to anchor the 6–10 week plan, the book most working adults I talk to actually finish is Darril Gibson's Get Certified Get Ahead for SY0-701 — it's written in plain language and organized around the objectives, which suits an hour-a-day schedule. You can find it here: Get Certified Get Ahead: SY0-701 Security+ on Amazon (affiliate link, once this site's program is approved — the free alternative that also works is Professor Messer’s SY0-701 series on YouTube).

Keep reading: 90-day roadmap, certification decisions, guide library, how long Security+ takes while working full-time, how long it takes to become a SOC analyst, whether you need a degree for cybersecurity, TryHackMe vs Hack The Box for absolute beginners, whether WGU cybersecurity is worth it, Security+ vs CySA+ — which one after A+, Network+ vs Security+ — which one first?, is Security+ worth it in 2026 — the short version, what is a realistic A+ study plan with zero IT experience?, how do you get cybersecurity experience when every entry-level job asks for experience?, how do you study for Network+ while working full-time?, what does a SOC analyst actually do all day?, CompTIA A+ vs Google Cybersecurity Certificate: which should you do first?, how to pass Network+ — the ports and cables drill method, subnetting for Network+ — turn a mask into CIDR in two checks, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This article contains one affiliate link (marked above). If you buy through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

LABS / HANDS-ON PRACTICE — OCTOBER 21, 2026 · ~8 MIN READ

TryHackMe vs HackTheBox for Beginners: Which One Should You Start With?

This is the first real fork in the road for most beginners, and it's the one I hit myself: A+ done, Security+ study underway, WGU cybersecurity classes in progress — and two lab platforms everyone recommends, both asking for time and money I don't have much of. I study in short sessions around shifts as a shift supervisor, so the question was never which platform is "better" — it was which one would teach me something in about an hour a day.

Side by side

Both platforms run in your browser and both are legitimately good — they just assume different starting points. Here's how they differ where it actually matters to a beginner:

What TryHackMe actually teaches

TryHackMe is built like a course that happens to contain labs. Three paths matter most when you're starting out:

• Pre Security. The true floor: how computers, networks, and the web actually work, plus your first Linux commands. If terms like DNS, IP address, and port are fuzzy, start here and don't skip ahead — everything later assumes this layer.
• Complete Beginner. Builds on that base with networking in more depth, web basics, and the common tools you'll keep meeting in security work.
• SOC Level 1. The path that matters most for my job search: alert triage, log analysis, and blue-team thinking — a beginner's version of what a Tier 1 analyst actually does all day.

The skills compound quietly: Linux fluency, networking you can picture instead of just recite, web fundamentals. And because each room teaches first and tests second, an hour-long session almost always ends with something finished and understood — the finish-line feeling that keeps a working adult coming back past week two.

What HackTheBox actually teaches

HackTheBox is built like a gym, not a course. You show up, pick a machine, and the learning happens because the machine refuses to cooperate:

• Starting Point. The on-ramp: a small tier of very easy machines with official write-ups. This is where a beginner belongs on HackTheBox — full stop.
• Academy. Structured modules that come closest to coursework, covering enumeration, web attacks, and privilege escalation in real depth.
• Retired boxes. The deep back catalogue of past machines, where most of the platform's reputation — and most of its frustration — lives.

What HackTheBox teaches best is enumeration: the disciplined habit of probing a system methodically until something gives, plus privilege escalation and real problem-solving under uncertainty. Those are valuable skills — but they're offensive-leaning, and the platform assumes you can already read network output and drive a terminal. Without that floor, your first sessions are mostly copying walkthrough steps you don't understand: activity that looks like hacking and teaches like a screensaver.

A realistic 30-day starter plan (working a job, ~1 hour a day)

This is the plan I'd hand a coworker in my exact situation. It assumes about an hour a day, fitted around shifts — the same constraint that shapes everything in my 90-day roadmap:

• Weeks 1–2: TryHackMe Pre Security. One room at a time, notebook open beside you. Goal by day 14: you can explain what DNS does, move around Linux without a cheat sheet, and say what a port is in your own words.
• Week 3: TryHackMe networking and Linux rooms from the Complete Beginner path. This is the week your Security+ reading starts clicking, because you're touching the concepts instead of just highlighting them.
• Week 4: your first HackTheBox Starting Point boxes. Use the official walkthroughs without guilt — read a step, do the step, then write down why it worked. Finishing two or three boxes with understanding beats staring at one box for a week and learning to hate the platform.

After day 30, keep SOC Level 1 as your main track if SOC is the goal, and treat HackTheBox as a weekly challenge session rather than a second daily obligation.

Who should skip each one — and the mistakes I see beginners make

• Skip HackTheBox for now if you can't yet navigate Linux or explain basic networking. You'll spend your whole hour decoding walkthroughs instead of learning, and that's exactly where most beginners quietly quit.
• Skip paying for TryHackMe premium for now if you haven't finished the free beginner material. A subscription doesn't fix unfinished free rooms; finish what's free, then pay when you hit an actual wall.
• Mistake: jumping to hard HackTheBox boxes too early. Difficulty labels are relative to people who already hack. Starting Point exists for a reason — ego is an expensive tutor.
• Mistake: collecting rooms without taking notes. Fifty finished rooms you can't explain are entertainment, not evidence. Slow down and write.
• Mistake: no lab notebook. One short page per session — what I tried, what broke, what I'd do next. It feels optional until an interviewer asks what you've actually done, and then it's the whole answer.

How this fits a SOC analyst job search, next to Security+

Security+ study is my main track, because it's the credential the SOC postings actually filter for — that sequencing is the whole argument of my Security+ breakdown and the decision guides. Labs are the supporting track: they turn "currently studying for Security+" into a sentence you can back up in an interview. TryHackMe's SOC Level 1 path maps most directly onto Tier 1 work, so it gets most of my lab time. HackTheBox still earns its place — understanding how an attacker enumerates a machine makes your triage sharper — but for a SOC application it's seasoning, not the main course. Cert for the filter, labs for the conversation, notebook for the proof.

If you're starting where I'd start: TryHackMe (affiliate link) — begin with the free Pre Security path and only pay when you hit the wall the free tier puts in front of you. When you've got 30–60 days of basics down and want the challenge-based side, add HackTheBox (affiliate link) and start at Starting Point, no matter what your pride says. The Hack The Box link above is a live affiliate link; the TryHackMe link is a placeholder until that program approves this site.

Keep reading: 90-day roadmap, certification decisions, guide library, is Security+ worth it in 2026, how long it takes to become a SOC analyst, the short version of this comparison, Security+ vs CySA+ — which one after A+, Network+ vs Security+ — which one first?, is Security+ worth it in 2026?, what is a realistic A+ study plan with zero IT experience?, how do you get cybersecurity experience when every entry-level job asks for experience?, how do you study for Network+ while working full-time?, what does a SOC analyst actually do all day?, CompTIA A+ vs Google Cybersecurity Certificate: which should you do first?, how to pass Network+ — the ports and cables drill method, subnetting for Network+ — turn a mask into CIDR in two checks, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This article contains affiliate links to TryHackMe and HackTheBox (marked above). If you sign up through them, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — the recommendation order here follows the learning order, not the commission.

COMPTIA NETWORK+ / SECURITY+ / CERT GUIDE — OCTOBER 23, 2026 · ~10 MIN READ

Network+ vs Security+: Which Should Beginners Take First?

Network+ vs Security+ — which first? It's the sequencing question I hear most from people standing exactly where I stood: A+ in hand, tech-support time logged, a SOC analyst job as the goal, and two CompTIA exams both claiming to be the next step. I'm a shift supervisor, CompTIA A+ certified, and a WGU cybersecurity student working through this exact order between shifts. Here's the honest answer, with the specifics most advice skips.

What each exam actually covers

These are different exams testing different jobs. Network+ (N10-009) is about building, running, and fixing networks:

• Networking concepts (23%). The OSI model, ports and protocols, DNS, DHCP, IP addressing and subnetting, and cloud and virtualization networking basics.
• Network implementations (20%). Routing and switching, wireless standards and deployment, VLANs, and physical installations.
• Network operations (19%). Monitoring, documentation, disaster recovery, and the policies that keep a network running day to day.
• Network security (14%). Common attacks against networks, hardening, and access controls — real, but introductory.
• Network troubleshooting (24%). The biggest domain: a formal troubleshooting methodology, cable and tool issues, and diagnosing service problems.

Security+ (SY0-701) is about defending systems, and it assumes the networking layer above is not foreign to you:

• General security concepts (12%). Zero trust, cryptography basics, access control models, and security controls.
• Threats, vulnerabilities, and mitigations (22%). Malware, phishing and social engineering, application and network attacks, and how you respond to each.
• Security architecture (18%). Secure network design, firewalls, cloud security, and data protection.
• Security operations (28%). The heaviest domain — identity and access management, monitoring, incident response, and forensics basics. This is the part that maps to daily SOC work.
• Security program management and oversight (20%). Governance, risk, compliance, and audits — the business side.

Notice the overlap is thinner than people think: Network+ teaches you how traffic moves; Security+ teaches you how it's attacked and defended. My full breakdown of the second exam is in is Security+ worth it in 2026.

Exam facts, side by side

That last row is the one people get wrong: you do not need Network+ on your résumé before CompTIA will let you sit Security+. Plenty of beginners book Security+ first and pass it. The real question is whether you know enough networking to understand what Security+ is defending.

Who should take Network+ first

• True beginners with no IT job yet. If you can't explain DNS, subnetting, or the OSI model in plain words — not recite them, explain them — Security+ will feel like memorizing a foreign language. Network+ study builds the floor first, and the exam gives you a credential while you build it.
• People targeting NOC or network technician roles first. If the job you actually want next is network-heavy, Network+ is the cert those postings name, and the security cert can come after you're hired.
• Anyone whose target employer requires it. If a specific posting or contract lists Network+, that settles the order. Read real postings before you decide — that's the whole point of the decision guides.

Who should take Security+ first

• A+ holders and help-desk workers who already handle basic networking. If your day job has you touching DNS records, DHCP scopes, VPN clients, and IP conflicts, you have more networking than you think. This was me: 2+ years of remote tech support covered the floor A+ tested.
• Anyone on a job-search deadline. If you need to be applying to SOC roles in the next few months, go where the postings point. I lay out what that timeline honestly looks like in how long it takes to become a SOC analyst.
• Anyone targeting SOC or help-desk-to-SOC roles that list Security+ and DoD 8140 baseline. Security+ is an approved baseline certification under DoD 8140, which is why government and contractor postings name it. Network+ doesn't open that particular door.

Who can skip Network+ — for now

Two groups can reasonably skip the Network+ exam and go straight to Security+:

• WGU students whose degree plan already includes networking coursework. My cybersecurity degree plan covers networking as coursework, so paying $369 to certify the same material separately would buy me a line on a résumé, not new knowledge. If your program does the same, let the degree carry it.
• A+ holders who pass this five-question self-check. Answer out loud, in plain words, without looking anything up: (1) What does DNS do, and what breaks when it fails? (2) What does DHCP hand out, and what happens when the pool runs dry? (3) In a /24 subnet, how many usable host addresses are there, and why? (4) TCP vs UDP — what's the real difference, and name one use for each. (5) What does a VLAN actually do? If all five come out clean, your networking floor is probably fine for Security+. If two or more come out fuzzy, that's your answer — study networking first, whether or not you sit the exam.

The decision, in one table

Study time at an hour a day — and a combined plan

At roughly an hour a day — the pace that fits around shifts, and the pace my 90-day roadmap is built on — realistic estimates look like this: Security+ takes about 8–10 weeks if you're coming in with A+ or help-desk foundations. Network+ takes about 10–12 weeks for a true beginner, because subnetting and troubleshooting only stick with repetition. Neither number is a weekend project, and anyone selling you one is selling.

The combined order I'd hand someone in my position: spend weeks 1–10 on Security+ and sit the exam while it's fresh. Then spend 3–4 weeks filling networking gaps with targeted Network+ topics — subnetting until it's automatic, the troubleshooting methodology, VLANs, wireless — without necessarily booking the Network+ exam at all. You end up with the cert the postings filter for, plus the networking knowledge the job actually uses, for one exam fee instead of two.

If you learn better from a structured course than from a book, a guided sequence that walks the networking fundamentals into security topics in order can be worth it — this is the kind of course I'd use for the gap-filling weeks: CompTIA networking and security courses on Coursera (affiliate link, once this site's program is approved — the free alternative that also works is Professor Messer's N10-009 and SY0-701 series on YouTube).

The honest cost note

Two vouchers at list price run about $773 before retakes, study materials, or the gas to the testing center. That's real money on a shift supervisor's budget, so hear this plainly: it is completely fine to study Network+ material without paying for the Network+ exam. The knowledge is what makes Security+ cheaper — one pass instead of a retake — and what makes you useful in an interview. But be equally clear about the trade: when money forces a choice, Security+ is the one that shows up in SOC job postings. Skills matter most; the credential that gets your résumé past the filter is Security+.

Mistakes that waste months

• Collecting certs in perfect order while never applying. The "correct" sequence is worthless if no applications go out. A cert order is a study plan, not a career — apply while you study, not after the shelf is full.
• Studying Network+ for months to avoid the harder Security+. Networking study feels productive and safe, which is exactly why it becomes a hiding place. If the self-check says you're ready, book the harder exam.
• Assuming Network+ is required before Security+. It isn't — not by CompTIA, and not by most SOC postings. Treating a recommendation as a requirement costs you months and $369 you may not have needed to spend yet.

The bottom line: pick the order from the job you want and the knowledge you actually have, not from a ladder. For most A+ holders and help-desk workers headed for a SOC seat, that's Security+ first, networking gaps filled deliberately after — which is exactly the order I'm running myself.

Keep reading: 90-day roadmap, certification decisions, guide library, is Security+ worth it in 2026, how long it takes to become a SOC analyst, TryHackMe vs HackTheBox for beginners, Security+ vs CySA+ — which one after A+, Network+ vs Security+ — which one first?, is Security+ worth it in 2026?, what is a realistic A+ study plan with zero IT experience?, how do you get cybersecurity experience when every entry-level job asks for experience?, how do you study for Network+ while working full-time?, what does a SOC analyst actually do all day?, CompTIA A+ vs Google Cybersecurity Certificate: which should you do first?, how to pass Network+ — the ports and cables drill method, subnetting for Network+ — turn a mask into CIDR in two checks, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This article contains one affiliate link (marked above). If you buy through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

CAREER / RÉSUMÉ GUIDE — OCTOBER 26, 2026 · ~10 MIN READ

Cybersecurity Resume With No Experience: What Actually Gets You Interviews

Writing a cybersecurity resume with no experience feels like a rigged game: every "entry-level" posting seems to want two years you don't have yet. I'm a shift supervisor, CompTIA A+ certified, and a WGU cybersecurity student — and before this chapter I worked as an Apple Support Advisor and did field support for local business clients. None of that is a security job title. All of it counts, if you present it honestly and in the language the job actually uses. Here's how.

What recruiters actually scan for first

Before a human reads your résumé, software usually does: applicant tracking systems filter on keywords from the posting — the cert it names, the tools it lists, the job title family. If your résumé survives that, a recruiter gives it roughly ten seconds. In those seconds they're not reading; they're hunting for four answers. Do you have — or are you close to — the credential the posting names? Is there any hands-on proof, or only coursework? Does your work history show the support skills the job runs on: troubleshooting, documentation, dealing with frustrated people calmly? And is anything here obviously inflated? A résumé built to answer those four questions fast beats a longer one that buries them.

The one-page structure, in order

Order matters: for a career changer, skills and projects sit above education because they're the proof. And if you're deciding whether Security+ belongs on your résumé yet, my breakdown of whether Security+ is worth it in 2026 covers what that cert actually signals to the people doing this scanning.

Translating non-IT experience — honestly

This is where career changers undersell or oversell. The rule: describe the real work using the vocabulary the target job uses for the same work — never upgrade the work itself. Support jobs run on tickets, documentation, troubleshooting, de-escalation, training, and process. If you've done those things anywhere, you've done them.

• Shift supervisor — before: "Ran shifts and handled customer complaints." After: "Supervised shifts and trained new team members on store procedures; de-escalated customer issues in person and documented incidents and hand-offs in shift notes so the next team started informed." Same job — now a hiring manager can see supervision, training, de-escalation, and documentation.
• Apple Support Advisor — before: "Helped people with iPhone problems." After: "Resolved technical support cases by phone: diagnosed hardware and software issues, walked users through step-by-step troubleshooting, and documented each case so the next advisor could pick it up cold." That is ticket work and troubleshooting, because that's what it was.
• Field work — before: "Fixed computers for local businesses." After: "Provided on-site and phone support for local business clients; troubleshot device and connectivity problems and left written notes clients could follow after I was gone." Field work is help desk work with a drive attached.
• Customer service — before: "Answered phones and emails." After: "Handled customer inquiries by phone and email; logged, prioritized, and followed up on open issues until they were resolved — including the angry ones."

Notice what none of those bullets do: invent software, invent numbers, or invent a job title. If a bullet would embarrass you when an interviewer says "tell me about that," rewrite it until it wouldn't.

The Projects section: proof when there's no security job yet

Projects are where a no-experience résumé stops asking to be believed and starts showing evidence. Two or three done properly beat eight listed by name only. Strong beginner projects: a home lab — a couple of virtual machines on your own hardware, a Windows box and a Linux box that talk to each other. Packet captures — pull real traffic in Wireshark, find the DNS lookups and the TCP handshake, and write up what you saw. Active Directory practice — build a small domain, create users and groups, break a permission, fix it. SIEM practice — feed your lab's logs into a free or trial SIEM and write up one alert you investigated. Guided lab work counts too: a finished TryHackMe room with your own notes is a project; a room you clicked through is not.

The test for every project: could you explain it for two minutes in an interview — what you built, what broke, what you learned? If not, it doesn't go on the résumé yet. Finish it, or shrink it until the answer is yes.

ATS keywords without lying

Yes, mirror the posting's language — where it's true. If a SOC posting asks for "log analysis" and you've genuinely reviewed logs in your lab, use their words. If it names a SIEM you've actually practiced in, name it. But the line is bright: never list a tool you haven't touched. I get asked about tools like Zendesk and Jira on applications, and my honest answer is that I haven't used them — my support work ran on other systems — so they don't appear on my résumé. Recruiters can smell a keyword-stuffed skills block, and the interview finds the gap in about ninety seconds. A shorter, true skills section beats a long, borrowed one every time.

What to leave off

• An "objective" paragraph. Your summary already does that job in two lines.
• Skills you can't demonstrate. Every operating system ever made, "expert" anything, a tool from one YouTube video you watched once.
• Certs listed as earned when they're in progress. Label them in progress — that's respected. The other version is disqualifying.
• Full home address, a photo, and "references available upon request." All space spent on nothing.
• Jobs from a decade ago with no transferable thread, and hobbies with no connection to the work. Space is argument; spend it on proof.

Tailor it to each posting — it takes fifteen minutes

Keep one master résumé, then adjust per application: rewrite the summary's last line to name the role you're applying for, reorder your skills block so the posting's requirements come first — among the true ones — and swap in whichever project matches the posting best. SOC postings want monitoring, logs, and triage language up top; help desk postings want troubleshooting, documentation, and patience with users. Same honest material, different order. My SOC analyst timeline lays out how this fits the longer path, and the 90-day roadmap shows where résumé-building sits in the overall sequence.

Common mistakes

• Two pages for an entry-level application. You don't have two pages of relevant proof yet; pretending otherwise reads as padding.
• A skills section longer than the experience. Ten tools and no bullets showing any of them convinces nobody.
• Applying everywhere with the identical file. The tailoring above is the cheapest interview-rate improvement there is.
• Waiting until everything is "done" to apply. Cert in progress, degree in progress, projects in progress — apply while you build. The decision guides on this site exist because sequencing beats stalling.

The 7-day build plan (about an hour a day)

• Day 1 — Raw material. List every job, date, cert, and project in one ugly document nobody will ever see.
• Day 2 — Header and summary. Contact block with your LinkedIn URL, then the two-to-three-line summary. Get those lines right before anything else.
• Day 3 — Translate experience. Rewrite your bullets using the before/after pattern above. This is the longest day, and the one that matters most.
• Day 4 — Skills and certifications. Group the skills honestly, list certs earned, and mark in-progress items "in progress."
• Day 5 — Projects. Pick your best two or three, write two bullets each, and cut anything you couldn't explain out loud.
• Day 6 — Tailor and keyword-check. Take three real postings you'd accept, make a tailored copy for each, and add only the keywords that are true of you.
• Day 7 — The ten-second test. Proofread it aloud, export a clean PDF, then hand it to someone for ten seconds and ask what you do and what you're aiming at. If they can't answer, the top third needs work.

The bottom line: "no experience" is not the same as "no evidence." Your support work, your labs, and your in-progress certs are evidence — the résumé's job is to present them in the order and the language a busy stranger can scan. Do that honestly and the interviews stop being a mystery.

One resource note, since projects are the section beginners get stuck on: the guided rooms on TryHackMe (affiliate link) are how I build projects I can actually explain — each finished room becomes a résumé bullet plus notes I can talk through in an interview, which is the whole test from the Projects section above. Start with the free rooms; pay for nothing until the free material runs out.

Keep reading: 90-day roadmap, certification decisions, guide library, how long it takes to become a SOC analyst, is Security+ worth it in 2026, Network+ vs Security+ — which should beginners take first?, what is a realistic A+ study plan with zero IT experience?, how do you get cybersecurity experience when every entry-level job asks for experience?, is the Google Cybersecurity Certificate worth it?, how do you study for Network+ while working full-time?, what does a SOC analyst actually do all day?, CompTIA A+ vs Google Cybersecurity Certificate: which should you do first?, how to pass Network+ — the ports and cables drill method, subnetting for Network+ — turn a mask into CIDR in two checks, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This article contains one affiliate link (marked above). If you buy through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

GOOGLE CYBERSECURITY / CERT GUIDE — OCTOBER 28, 2026 · ~9 MIN READ

Is the Google Cybersecurity Certificate Worth It in 2026? An Honest Breakdown for Beginners

This is the credential beginners ask me about most after Security+, and it's the one I answer most carefully. I'm a shift supervisor, CompTIA A+ certified, and a WGU cybersecurity student — and I came into this field through an Apple Support Advisor job and help-desk field work, not a Google course. That path is exactly why I can tell you who this certificate genuinely helps, who it wastes money on, and what it can't do no matter how the ads frame it.

What the program actually is

The Google Cybersecurity Certificate is a Google-built Professional Certificate hosted on Coursera: eight courses, taken in order. Together they cover security foundations and frameworks, networks and network security, Linux, SQL, and Python basics, assets, threats, and vulnerabilities, detection and response — including SIEM and SOAR concepts at an introductory level — and a final job-preparation course on applications and interviews. It's fully online and self-paced, with no proctored final exam: you pass course quizzes, hands-on labs, and projects as you go. Google pitches it as under six months at around ten hours a week. For working adults, the honest range is three to six months at five to ten hours a week — faster if you study daily, slower if life intervenes, which it will.

What it costs, honestly

You don't buy this certificate outright; you rent access to it. It runs through a Coursera subscription — around $49 a month after a free trial, at the time of writing — so check Coursera's site for current pricing before you budget, because that number moves. That makes your total cost a speed question: finish in two months and you've spent about $100; drift for six and you're near $300. Now compare honestly with Security+, where the exam voucher alone lists at $404 before study materials. The Google certificate can cost fewer dollars. What it doesn't buy is the same credential weight — and that trade is the rest of this article. If you make money decisions before purchases the way I do, my decision guides run every cert through that filter first.

What it teaches well — and where it stops

What it does well is real. The structure is the product: you're told what to learn next every single day, which is the thing true beginners actually lack. The explanations assume nothing, the instructors are clear, and the hands-on labs sprinkled through the courses — Linux commands, SQL queries, reading packets — mean you're doing things, not just watching slides. For someone who has never touched IT, that on-ramp is worth paying for.

The gaps are just as real. Networking depth is thin: you'll meet ports, protocols, and subnetting, but you won't build the fluency SOC work demands. There's no proctored exam behind it, so it proves you finished a course — not that you can perform under exam conditions the way a CompTIA credential proves. And it leaves you thin for technical interviews: you can describe what a SIEM does without ever having triaged a queue of real alerts. None of that is failure; it's the boundary of an introductory course. The mistake is expecting it to be more than that.

Google Cybersecurity Certificate vs Security+, side by side

Who it helps most

Career changers with zero IT or security background who need structure more than depth. If you're coming from retail, food service, a warehouse — anywhere with no overlap with IT — the certificate replaces "what do I even learn first?" paralysis with a sequence you can just follow an hour at a time. It also suits anyone still deciding whether they even like this field: a month or two of guided courses is a cheaper way to find out than an exam voucher and a failed first attempt.

Who should skip it — or at least delay it

• People who already have A+ or help-desk experience. You already stand on the floor this course builds. That was me: Apple support and field work for local clients meant the introductory material would have been review, so my money and months went to Security+ instead. If that's your background, go straight there.
• Anyone expecting a certificate alone to get them hired. No credential does that, and this one least of all — it's a starting line, not a finish line. If your plan ends at the certificate, the plan is the problem.
• People whose target postings never mention it. Pull ten real postings you'd accept and count what they name. If the Google certificate never appears and Security+ appears in eight, the market has already made this decision for you.

What to do after it: build proof

Finishing the certificate is the end of the introduction, not the end of the plan. The sequence I'd hand anyone coming out of it: first, hands-on labs — a path like TryHackMe's SOC Level 1 turns the SIEM and SOAR vocabulary into actual alert-triage reps. Second, one small project you own: a home lab, or a packet-capture write-up where you pull real traffic in Wireshark, find the DNS lookups and the TCP handshakes, and explain what you saw in your own words. Third, Security+, for the credential the postings actually filter on. Then apply — using the realistic expectations in my SOC analyst timeline, where this certificate slots into the foundations months, not the whole journey.

What the job search actually looks like

Some entry-level SOC and cybersecurity analyst postings do mention the Google certificate — usually in an "or equivalent" line, or as an acceptable entry credential at larger companies that hire in cohorts. But scroll ten real postings and count: Security+ appears by name far more often, because it's proctored, standardized, and on the DoD baseline list, and hiring software filters on what postings name. So treat the Google certificate the way a recruiter will: as evidence that you started something structured and finished it. The convincing gets done by your projects and your résumé — my guide to writing a cybersecurity resume with no experience shows how to present exactly this kind of credential honestly, next to the labs that back it up.

An 8-week starter plan (about an hour a day)

Already decided it's the right on-ramp for you? Here's how I'd run the first eight weeks at roughly an hour a day — the pace that survives a work schedule, the same constraint behind my 90-day roadmap:

• Weeks 1–2: the first two courses — security foundations and frameworks. Notebook open, one page of notes per session, in your own words.
• Weeks 3–4: the networks course, plus Linux and SQL. Slow down on ports and subnetting; that layer is what everything later stands on.
• Weeks 5–6: assets, threats, and vulnerabilities. On days off, add one beginner lab room elsewhere to watch the concepts happen live.
• Week 7: detection and response — the SIEM and SOAR material. This is your SOC preview; take the best notes of the whole program here.
• Week 8: the job-preparation course, then a decision, not a drift: start Security+ study, start a lab path, or both. Don't let the subscription roll into a ninth month by default.

The bottom line

So, is the Google Cybersecurity Certificate worth it in 2026? For a true beginner with no IT background who needs a structured on-ramp — yes: priced by the month, beginner-friendly, and honest about being an introduction. For anyone with A+, help-desk time, or a SOC target date, Security+ is usually the better spend, and the rest of the guide library lays that path out piece by piece. Either way, remember what the certificate is: the start of your proof, never the proof itself.

If you do start it, the program itself lives here: Google Cybersecurity Professional Certificate on Coursera (affiliate link, once this site's program is approved — per this site's disclosure policy, placeholder links stay placeholders until each program approves this site). Use the free trial first and finish the opening course before you pay for a month; the subscription clock is the one cost you fully control.

Keep reading: 90-day roadmap, certification decisions, guide library, is Security+ worth it in 2026, how long it takes to become a SOC analyst, cybersecurity resume with no experience, Network+ vs Security+ — which should beginners take first?, how do you get cybersecurity experience when every entry-level job asks for experience?, how do you study for Network+ while working full-time?, what does a SOC analyst actually do all day?, CompTIA A+ vs Google Cybersecurity Certificate: which should you do first?, how to pass Network+ — the ports and cables drill method, subnetting for Network+ — turn a mask into CIDR in two checks, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This article contains one affiliate link (marked above) — the Coursera link for the certificate itself. If you enroll through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

CAREER / HELP DESK TO SOC GUIDE — OCTOBER 30, 2026 · ~10 MIN READ

Help Desk to Cybersecurity: How to Make the Jump Without Starting Over

If you are searching how to go from help desk to cybersecurity, I am not writing this from the other side of the jump. I am in the middle of it. I am CompTIA A+ certified, a WGU cybersecurity student, and currently studying Network+. Before school, I worked remote tech support as an Apple Support Advisor and at Concentrix and Wipro, and I did field work for Hardy, where local clients called me directly. I also work as a shift supervisor. That mix is the point: support work is not wasted time. It is the first half of the career, if you translate it honestly and add the parts it never taught you.

What your help desk work already proves

Start by seeing your job the way a SOC hiring manager sees it. The tasks feel routine, but each one maps to a security skill — if you describe it in the language the next job uses. That is also how you should rewrite your résumé: name the skill honestly, without upgrading the work itself.

Notice what that table does not do: it does not invent a security title you never held. It takes real tickets and names the skill underneath them — and true examples hold up when an interviewer asks follow-up questions.

The real gaps: what help desk does not teach you

Help desk teaches you to close tickets. Security work asks what the evidence shows, and what happened before the user noticed. That shift is where the real gaps live.

First, reading logs instead of just error messages. An error message says something failed; a log shows the sequence — the successful sign-ins, the failures before them, the times and accounts. Second, basic networking depth: I could fix a connection long before I could explain why it broke. That takes DNS, DHCP, TCP versus UDP, and subnetting a /24 until it is automatic — the exact things I am drilling for Network+, ports and cables included. Third, Linux command line basics: moving around, reading files, and checking processes and permissions without a mouse. Fourth, how a SIEM alert queue and triage workflow actually work — an alert arrives, you judge whether it looks real, gather context, and escalate or close it with notes. Fifth, packet captures with Wireshark, so “the network did it” becomes something you can point to, packet by packet.

Cert order for someone already in support

If you already hold A+, do not redo beginner certs just to feel busy. A+ built my troubleshooting floor; repeating that level spends months proving what I already proved, while the gaps above stay just as wide.

Instead, study Network+ material for the networking gaps. Sitting the Network+ exam is worth it if networking is your weak spot and you want a credential that proves you fixed it; if the material becomes solid through study alone, that knowledge still helps. I work through that exact call in my Network+ vs Security+ guide.

Then take Security+ as the cert SOC postings actually list — the filter my A+ alone did not clear. I lay out what it covers in my Security+ breakdown. Security+ assumes the networking layer, so learn that first, even when you skip the separate exam. For true beginners with no IT background who need structure first, the Google Cybersecurity Certificate is a plain resource worth knowing about; I cover who it helps in my guide to whether the Google Cybersecurity Certificate is worth it. With support experience, you are likely past most of it — go straight to the gaps. That role-first sequencing is the same filter I use in my certification decision guides.

A concrete 90-day plan, at about an hour a day

The plan below assumes about an hour a day while you are still working shifts, and follows the same protect-a-small-block logic as my 90-day roadmap. One repeatable hour beats a weekend marathon you abandon by week three.

• Days 1–14 — Inventory and translate. Go through your recent tickets and pick the ones with real troubleshooting, account, malware, or connectivity work in them. Rewrite five of them as security-style incident notes: what was reported, what you checked, what the evidence showed, and how it was resolved or escalated. This becomes résumé material and interview material at the same time.
• Days 15–45 — The networking block. Work DNS, DHCP, subnetting, and TCP versus UDP until you can explain each one out loud in plain words. Alongside it, do one Wireshark capture a week on your own home network traffic — a lookup, a page load, a device joining — and write up what you saw until you can explain every capture without guessing.
• Days 46–75 — Security+ study plus log practice. Study Security+ in the same daily block, and pair it with real logs: read Windows Event Viewer on your own machine and simple authentication logs, and write down what normal looks like for you — your usual hours, your usual successes — versus what would look suspicious, like repeated failed logons at 3 a.m.
• Days 76–90 — Build the application packet. Finish the translated résumé, finish the two projects below so you can explain both, and start applying while you finish studying. Do not wait until you feel “ready.” That feeling does not arrive on its own; applications and interviews are what tell you what to study next.

Two projects only — and both explainable

Projects are where beginners either build real proof or build a problem for the interview. A project only helps if you can explain it line by line — what you did, what each part shows, what you would check next. If you cannot explain it, shrink it until you can, or leave it off entirely.

Project one: a home packet capture. On your own network, capture a DNS lookup and a failed connection in Wireshark. Annotate what each packet proves — the question your machine asked and the answer that came back, and where the failed handshake stopped and what that says about the address, port, or service. Save the capture and a one-page note.

Project two: a log review. Collect a week of your own Windows sign-in events from Event Viewer. Summarise failed versus successful logons in a one-page note: how many of each, when they happened, and whether the pattern matches your real life — and what a worrying pattern would look like. That comparison, normal versus suspicious, is the analyst skill in miniature.

Job titles to actually apply for

“Cybersecurity” is too wide to search well, so search the titles that actually hire from support: SOC Analyst Tier 1, Security Operations Analyst, Junior Security Analyst, and IT Security Analyst. Also look at security-minded help desk and desktop roles at smaller companies as a bridge — at a small shop, support often also handles accounts, endpoint protection, and phishing reports, which is security work with a support title.

Start applying once Security+ study is underway and you have the two projects above — not after collecting a third cert. Pay and timelines vary a lot by market and employer, so judge postings by the work described. My SOC analyst timeline shows where this window sits in the longer path, and my guide to a cybersecurity resume with no experience shows how to present the translated work and projects.

Common mistakes

Most of these I have either made or watched someone in support make. All of them are avoidable.

• Quitting the support job before you have an offer. You lose your income and your freshest experience at the same time. The support job is funding the jump and feeding your résumé — keep it until an offer is signed.
• Collecting certificates with nothing to show. A shelf of certs with no logs read, no captures taken, and no notes written convinces nobody. Proof beats another line on the résumé.
• Inventing tool experience you do not have. Do not claim SIEM, Zendesk, Jira, or any other tool you have not actually used. I will use myself as the example: I have said plainly that I have no Zendesk and no Jira experience, so neither appears on my résumé. The interview finds an invented tool in about ninety seconds, and it costs you the honest experience you did have.
• Applying only to postings that say “3+ years security experience.” That filter skips the Tier 1 postings that list help desk experience as a plus — which are exactly the postings written for you.
• Hiding your support background instead of leading with it. Your troubleshooting, documentation, and de-escalation are the strongest evidence you have. Translate them and put them first; do not bury them under coursework.

Once the networking and Security+ basics stop feeling new, Hack The Box Academy's defensive / SOC learning material is a reasonable next step for structured, hands-on practice beyond beginner labs. That link is an affiliate link — if you sign up through it, I may earn a commission at no extra cost to you, as explained in this site's disclosure.

Keep reading: the full guide library, the 90-day roadmap, how long it takes to become a SOC analyst, how to write a cybersecurity resume with no experience, how do you study for Network+ while working full-time?, what does a SOC analyst actually do all day?, CompTIA A+ vs Google Cybersecurity Certificate: which should you do first?, how to pass Network+ — the ports and cables drill method, subnetting for Network+ — turn a mask into CIDR in two checks, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This article contains one affiliate link (marked above). If you buy through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

LABS / HOME LAB GUIDE — NOVEMBER 2, 2026 · ~11 MIN READ

How to Build a Cybersecurity Home Lab for Beginners (Starting at $0)

If you are searching for a cybersecurity home lab for beginners, you have probably seen the photos: a rack in a closet, three monitors, a server humming away. I am not building that, and you do not need to either. I am a Starbucks shift supervisor, CompTIA A+ certified, a WGU cybersecurity student currently studying Network+, learning between shifts on a tight budget. Before school I worked as an Apple Support Advisor and in remote support at Concentrix and Wipro, plus field work for Hardy where clients called me directly — and all of that troubleshooting taught me the lesson this lab runs on: you learn by seeing and doing, not by buying gear.

This guide follows the same order as my 90-day roadmap: foundations first, proof second, spending last. It complements the guided platforms rather than replacing them — my TryHackMe vs HackTheBox guide covers guided labs in a browser, while this home lab is where you break your own systems, read your own logs, and learn what normal looks like. You need both kinds of practice eventually. This one costs nothing to start.

Safety and legality rules — read these before you install anything

A home lab is legal and safe when it stays a lab. Only scan, attack, or test systems you own, inside your isolated lab network — nowhere else. Put deliberately vulnerable VMs on a host-only or internal virtual network in VirtualBox, never bridged straight onto your home LAN or the internet, because a bridged vulnerable VM is exposed to everything else on your network. Snapshot every VM before you break something, so a bad experiment costs five minutes instead of a reinstall. And never scan a school network, an employer's network, or anyone else's network, even to “help” — without written permission, that is not practice, it is a problem you cannot undo. These rules are the difference between a portfolio project and a story you have to explain to someone with a badge.

Phase 1: the $0 starter lab

Your starter lab is one free program — VirtualBox — on the laptop or desktop you already own. The specs that work: ideally 16GB of RAM, which runs two VMs comfortably, but 8GB is workable if you run one VM at a time. An SSD helps more than a faster CPU, because VMs spend their lives loading and snapshotting disk images. If your machine meets that, you already own a lab. Install three VMs, each with a single clear job:

That is the whole lab for the first few weeks: three VMs, one job each. If you are still deciding which cert or platform deserves your money and hours, work that out in my certification decision guides instead of buying hardware.

Your first week: about an hour a day

Here is the exact build sequence I would hand a beginner. One hour a day, in order, no skipping ahead to the fun-looking parts:

• Day 1 — Install and snapshot. Install VirtualBox, then install Kali and Ubuntu Server. The moment each one boots cleanly, take a snapshot and name it “clean install.” That snapshot is your undo button for everything that follows.
• Day 2 — Build the isolated network. Create a host-only / internal virtual network in VirtualBox and attach your lab VMs to it. Confirm the VMs can ping each other, then confirm the important negative: a vulnerable VM is not bridged onto your home LAN. If you cannot explain which network each VM is on, stop and fix that before anything else.
• Day 3 — First packet capture. Open Wireshark and capture three things on your own lab network: a ping, a DNS lookup, and an HTTP login on your own lab site. Save the file as a .pcap and write notes on what each capture proves — the question your machine asked, the answer that came back, and where the traffic went.
• Day 4 — Linux basics in Ubuntu. Practice file permissions until chmod stops feeling like trivia, then go to the logs: look in /var/log, run journalctl, and read auth.log until you find a failed login — ideally one you deliberately caused. Write down the exact line and what each field means.
• Day 5 — Windows logging. In the Windows VM, open Event Viewer and find failed logon events alongside successful ones. Compare the pattern: account, time, source. This is not a detour — failed-logon review is literally what a Tier 1 SOC analyst looks at on real alerts.

By the end of that week you have done the three things screenshots of other people's labs never teach: built an isolated network, captured real traffic, and read real logs. As a hands-on learner, that week taught me more than any gear list — I could see the ping succeed, watch the DNS answer come back, and find my own failed login in the log.

Phase 2: logging and SOC practice

Once the basics feel ordinary, add one logging step — and only one. The two honest free options are Splunk's free tier and Wazuh, an open-source platform; both can collect and search your Windows and Linux logs. Do not stall a week picking the “best” one: pick Splunk's free tier to start, because its search language shows up constantly in SOC postings, and Wazuh will still be there later. Forward or ingest the logs from your Ubuntu and Windows VMs, then build exactly ONE detection: an alert on repeated failed logins — several failures for the same account in a short window. Trigger it yourself with bad passwords on your own lab account, watch it fire, and write up what you saw: how many failures, from which machine, over what period, and how you confirmed it was you. That write-up is SOC work, not hacking tricks — my SOC analyst timeline shows where this practice sits in the longer path to applying.

Phase 3: an Active Directory lab — only when you are ready

Later — not first — add a simple Active Directory lab: one Windows Server evaluation VM as the domain controller, joined by the Windows client VM you already have. It teaches what enterprise SOC work runs on: users and groups (who exists and what they belong to), Group Policy (settings pushed out centrally, like password rules applied to every machine at once), and Kerberos — in plain English, the ticket system Windows uses to prove a user is who they claim to be without sending their password around the network repeatedly. Do it after the logging basics: AD generates a flood of new event types, and if you cannot yet tell a normal failed login from a suspicious one in a single-machine log, a domain's worth of logs is just noise. Sequence is the strategy, the same way I argue for translating support experience first in my help desk to cybersecurity guide instead of starting over.

Budget tiers: what to spend, and when

Here is the complete spending ladder. Notice how short it is:

When you reach that under-$100 tier, you can find the SSD, RAM, or used gigabit switch through budget lab upgrades on Amazon (affiliate link — if you buy through it, I may earn a commission at no extra cost to you; see this site's disclosure). And be explicit about the “do not buy” list: do not buy a server, do not buy enterprise gear, and do not buy courses to compensate for not starting. A course watched instead of building is a more expensive way to stay at day zero.

Turn the lab into résumé and interview proof

A lab nobody can see is just a hobby claim. Document exactly two projects — both from the free tier — and be able to explain each out loud. First, a packet-capture write-up: what you built (the isolated network and capture setup), what you observed (the ping, the DNS exchange, the HTTP login, packet by packet), and what you would check next (whether an unexpected host appears in a capture of the same traffic). Second, a failed-login detection write-up: what you built (log forwarding into your SIEM and the repeated-failed-login alert), what you observed (the alert firing on your own bad-password test, with counts and times), and what you would check next (whether the failures came from one source, one account, or a pattern suggesting password spraying). Keep screenshots and notes for both in one simple portfolio folder. My cybersecurity resume with no experience guide shows where a Projects section like this belongs. And the warning that matters most: never list a tool you cannot explain in an interview, and never invent tools you have not used — I have no Zendesk and no Jira experience, so neither is on my résumé, and an interviewer finds an invented tool in about ninety seconds.

Common mistakes

Every one of these is the same mistake — doing the impressive-looking thing instead of the useful one:

• Buying gear first. A rack with no hours on it proves nothing; the $0 phase proves everything an interviewer asks about.
• Bridging vulnerable VMs. A deliberately vulnerable machine on your home LAN or the internet is a risk to you and your household, not a lab.
• Following a six-hour mega-tutorial without snapshots. One typo in hour four with no snapshot means starting over instead of rolling back five minutes.
• Building Active Directory on day one. AD before logging basics means drowning in event types you cannot interpret yet.
• Collecting VMs and never reviewing a single log. Ten installed VMs and zero logs read is a download folder, not a lab.
• Having no notes to show an interviewer. If it is not written up, you cannot prove it happened — and “trust me, I did it” loses to a one-page write-up every time.

Your 14-day starter checklist

Fourteen days, about an hour a day, all free. If you finish this list, you own a working lab and two documented projects:

1. Install VirtualBox; confirm your RAM and storage against the Phase 1 specs.
2. Install Kali Linux, boot it, and snapshot the clean install.
3. Install Ubuntu Server, boot it, and snapshot the clean install.
4. Create the host-only / internal lab network and attach both VMs.
5. Ping between the VMs; verify nothing vulnerable is bridged.
6. Install the Windows evaluation VM and snapshot it.
7. Capture a ping in Wireshark; save the .pcap with notes.
8. Capture a DNS lookup and an HTTP login on your own lab site; save both.
9. Practice Linux permissions in Ubuntu for one focused hour.
10. Read /var/log and auth.log; find and explain one failed login.
11. Open Windows Event Viewer; find failed and successful logons.
12. Install your chosen SIEM and ingest one VM's logs.
13. Build the repeated-failed-login alert and trigger it yourself.
14. Write up both projects — capture and detection — in your portfolio folder.

That is the whole pitch: the lab is not a purchase, it is a habit. An hour a day inside systems you own, with notes you can show, beats any shopping cart. Browse the guide library for the next step — and start tonight, with the computer you already have.

Affiliate disclosure: This article contains one affiliate link (marked above). If you buy through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

CAREER / SOC ANALYST GUIDE — NOVEMBER 4, 2026 · ~10 MIN READ

What Does a SOC Analyst Do All Day? Tasks, Tools, and Shifts Explained

If you search “what does a SOC analyst do,” most answers are either job-posting word salad or a movie scene — someone in a hoodie stopping an attack one-handed. I am not a SOC analyst yet: I am a shift supervisor, CompTIA A+ certified, a WGU cybersecurity student currently studying Network+, with 2+ years of remote customer and tech support at Concentrix and Wipro, including Apple support work. So this is not a memoir — it is built from real Tier 1 SOC job postings and day-in-the-life accounts from working analysts, answering the question the way I needed it answered: what actually fills the shift?

This guide picks up where my SOC analyst timeline leaves off — that one covers how long it takes to get hired; this one covers what you do once you are in the chair. It follows my 90-day roadmap: understand the job first, then build the exact skills it asks for.

What a SOC actually is, in plain terms

A SOC — Security Operations Center — is the team that watches an organization's systems for signs of attack, around the clock. Some companies run their own in-house; others hire a managed provider watching many clients at once. Either way, the work is organized in tiers — and the tier system is the first thing to understand, because “SOC analyst” in a job posting almost always means Tier 1:

Tier 1 is genuinely a beginner job: postings ask for fundamentals — networking basics, log reading, a cert like Security+ — not years of security experience. What Tier 1 does, all shift long, is one loop: watch the queue, triage alerts, investigate the basics, document, escalate. Everything below is about that loop.

A realistic Tier 1 day, block by block

No two shifts are identical, but postings and analyst accounts describe the same skeleton. A typical Tier 1 shift breaks into these blocks:

• Start-of-shift handover and queue check. You take over from the previous analyst: what fired overnight, what is still open, which incidents are mid-investigation. You read the handover notes before you touch anything — they are the difference between continuing an investigation and accidentally restarting it.
• Alert triage. The bulk of the shift. New alerts land in the SIEM queue and you work them in priority order: open, understand what fired, and make the first call on whether it matters.
• Investigation. For alerts that survive the first look, you pull the surrounding evidence — logs, related events, the user's and machine's recent history — until the picture is clear enough to decide.
• Ticket documentation. Every alert you touch becomes a ticket: what fired, what you checked, what you found, what you decided. This is not extra work bolted onto the job; on most shifts it is a third of the job.
• Escalation. When something is real and beyond Tier 1 scope, you package it — evidence, timeline, your working theory — and hand it to Tier 2. A clean escalation is a skill in itself, covered below.
• Quiet-period learning and lab time. Queues have slow stretches, especially overnight. Analysts use them to study alert types they handled badly, read write-ups, or run lab reps. The good SOCs expect this; it is how Tier 1 analysts become Tier 2 analysts.

Now the part the brochures soften. Attacks do not keep office hours, so many SOCs run 24/7 — nights, weekends, and holidays are part of the deal, especially for the newest analyst on the team, and 12-hour shifts on rotating schedules are common. Coming from shift work myself, I will not pretend that is nothing: night shifts cost sleep and social time. But be honest about the trade — the 24/7 schedule is exactly why SOCs are always hiring Tier 1, and it is one of the most reliable doors into this field. If you have run closing or holiday shifts, you already know whether you can live with it.

The core loop: what happens when an alert fires

Strip everything else away and Tier 1 work is one loop, repeated dozens of times a shift:

1. An alert fires in the SIEM. The SIEM — the system collecting logs from across the network — raises a flag when activity matches a detection rule, like repeated failed logins.
2. Check who, what, where, and when. Which account? Which machine? From what source address? At what time? These four answers frame everything after.
3. Enrich with logs. Pull the surrounding evidence: firewall logs for the connection, DNS logs for what the machine looked up, the endpoint console for what the device was doing, Windows Event logs or Linux auth logs for the login record itself.
4. Decide. True positive (real malicious or unauthorized activity), false positive (normal behavior that tripped a rule), or needs escalation (real or unclear, and beyond Tier 1 scope). “Unclear” is a legitimate outcome — escalating uncertainty with evidence is doing the job, not failing it.
5. Document and escalate with what you checked. Write the ticket so the next person sees your evidence and reasoning, not just your conclusion. If it escalates, Tier 2 starts from your notes.

Worked example: the failed-login burst

Here is the loop on a real alert type. The SIEM flags a burst of failed logins for one user account, followed by a single successful login. That can be an attacker who finally guessed the password — or an employee who mistyped it five times. The analyst checks four things. The source IP: the company's own network, the user's usual VPN exit point, or a random address overseas? The geography: does this user ever log in from that place? The user history: has this account succeeded from this address before, at these hours? And the MFA result: did the success pass a push approval or a code, or sail through on password alone? If the answers match the user's normal life — same IP as always, work hours, MFA passed — it closes as a false positive, with notes. Foreign IP, 3 a.m. their time, MFA never challenged: that is an escalation.

A good escalation note is specific enough that Tier 2 never redoes your work. It contains the account and machine involved, the exact times, the source IP and what your lookup found, the counts (how many failures, over what window), the MFA result, which log sources you checked, and your working theory in a sentence or two — for example: “Pattern matches password guessing followed by success; recommend forcing a password reset and reviewing the account's recent activity.” Vague notes like “looks suspicious, please check” are how alerts die.

The tools of the job — and what is actually expected of a beginner

Job postings name the same short list of tools again and again. You need not master any of them before applying — just know what each is for and talk about it without bluffing:

Read that table the right way: employers teach their stack, but they hire people who already think in logs, tickets, and evidence — and that thinking is trainable before you apply, which is the point of the plan at the end of this guide.

What the job is NOT

Two myths to drop before you apply. First, Tier 1 is not penetration testing: you are not breaking into systems all day, you are defending them by watching — red-team work belongs to a different team and a later career stage. Second, it is not a paperwork-free job; writing is half the skill. Every alert becomes a ticket another human reads at 3 a.m., and analysts who document clearly tend to advance faster than analysts who are merely clever. This is where support experience translates directly, and I say that from my own years on support queues: triage (which problem first?), calm communication with a stressed person, and documenting every step are the same three muscles, pointed at alerts instead of customers. If that is your background, my help desk to cybersecurity guide maps the translation in full.

The skills checklist that maps to getting hired

Read enough Tier 1 postings and the same skill list repeats. Here it is as a checklist — every item provable before you are hired:

• Log reading. Open a Windows Event log or a Linux auth log and find the failed logins, the successes, and the story they tell together. This is the daily bread of the job.
• Networking basics. DNS (how names become addresses), DHCP (how devices get addresses), subnets, and the common ports — exactly the material I am drilling for Network+ right now, because alerts make no sense without it.
• Windows and Linux basics. Accounts, permissions, services, and where each system keeps its logs. You do not need to administer either like a veteran; you need to navigate both without getting lost.
• One SIEM at a concept level. Know what a SIEM ingests, what a detection rule is, and how to run a filtered search. Depth on a specific platform comes on the job.
• Ticket writing. Findings, evidence, and a decision, written so a stranger can follow them. Practiced in the 14-day plan below.

The proof matters as much as the skills. My cybersecurity home lab guide builds the log-reading and SIEM reps for $0, and a packet-capture write-up from that lab proves the networking — those projects then become the Projects section in my cybersecurity resume with no experience guide. Still deciding whether the cert behind most of these postings is worth your money? That argument lives in my Security+ guide, and the wider cert-and-platform calls are worked through in the decision guides. For structured practice beyond the home lab, Hack The Box Academy runs detection and log-analysis labs that mirror the loop above (affiliate link — if you sign up through it, I may earn a commission at no extra cost to you; see this site's disclosure).

Beginner mistakes that get analysts in trouble

Analyst accounts warn about the same failure modes — all avoidable, all about judgment rather than knowledge:

• Chasing every alert equally. A queue has priorities for a reason. Treating a low-severity noise alert with the same urgency as a possible account takeover means the real one waits. Triage means ranking, not just processing.
• Closing alerts without notes. An unexplained closure teaches the next analyst nothing, hides patterns across shifts, and falls apart the first time anyone audits the ticket. If you checked it, write what you checked.
• Escalating with no evidence. “Looks bad, sending up” forces Tier 2 to start from zero and burns your credibility fast. Escalate late with evidence rather than early with a shrug.
• Ignoring handover notes. The previous shift's notes are open investigations in progress. Skipping them means re-checking settled questions — or worse, contradicting a decision without knowing it was made.

A 14-day starter plan (about an hour a day)

You cannot rehearse on a real SOC queue before you are hired, but you can rehearse every part of the loop in a home lab — about an hour a day:

1. Day 1 — Get one machine's logs flowing into a free-tier SIEM in your lab, and run your first filtered search by user and time.
2. Day 2 — In Windows Event Viewer, find five failed logons and five successful ones. Write down what differs between them.
3. Day 3 — In a Linux auth log, find the failed-login lines and explain each field out loud: time, service, user, source.
4. Day 4 — Wireshark: capture a DNS lookup and a login on your own lab network; annotate what each packet proves.
5. Day 5 — Study alert type one: failed-login bursts and password spraying — what each looks like in a log, and how they differ.
6. Day 6 — Study alert type two: endpoint malware detections — what a quarantine alert is actually asking Tier 1 to do.
7. Day 7 — Write a sample ticket for the login burst as a false positive: the user, the evidence, the decision, the notes.
8. Day 8 — Write the same burst as an escalation note: foreign IP, no MFA, counts and times included, working theory stated.
9. Day 9 — Study alert type three: phishing email reports — sender checks, header basics, and what you never click.
10. Day 10 — Wireshark again: follow one full conversation and name its source and destination ports without peeking at notes.
11. Day 11 — Networking drill: write out by hand how a device gets an address from DHCP and resolves a name through DNS.
12. Day 12 — Threat-intel practice: look up sample IPs and file hashes, and write down what convincing “malicious” evidence actually looks like.
13. Day 13 — Mock handover: write the shift-handover note covering this week's sample tickets, as if a real analyst takes over from you tonight.
14. Day 14 — Timed rehearsal: trigger a fresh alert in your lab and run the whole loop — triage, logs, decision, ticket — in under an hour.

Honest expectations before you apply

On pay, I am not going to print a salary figure, because Tier 1 pay varies a lot by location, night-shift differential, in-house team versus managed provider, and company size — a night role in a big metro and a remote managed-service role are different jobs wearing the same title. Read the ranges on actual postings in your market instead of trusting any site's average, this one included. There is no guaranteed hiring date either: certs and labs make you eligible; applications and interviews do the rest. What I can say that is narrower and truer — everything above is learnable by a support worker studying an hour a day, because every piece of it is a skill built from reps, not a talent. The rest of the guides live in the guide library; the next rep is yours.

Affiliate disclosure: This article contains one affiliate link (marked above). If you sign up through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

CAREER / CODING FOR BEGINNERS — NOVEMBER 6, 2026 · ~9 MIN READ

Do You Need Coding to Get Into Cybersecurity? What Beginners Actually Need

“Do you need coding for cybersecurity?” is the question that stalls more beginners than any exam on the path. It stalled me. I am a shift supervisor, CompTIA A+ certified, a WGU cybersecurity student currently studying Network+, with 2+ years of remote customer and tech support at Concentrix and Wipro behind me. I am not a software engineer, I am not a professional developer, and I am not working in a SOC yet. What I have learned from real entry-level postings and from building things in my own home lab is that the honest answer is smaller and more specific than the internet makes it sound.

This guide sits inside the same system as everything else here: it follows the roadmap, it belongs with the decision guides where I work through cert-and-path calls, and it lives in the guide library alongside them. If you only take one sentence from it, take this one: learn to be comfortable in a terminal and able to read logs first, and let coding grow from there.

Three different things people call “coding”

Most of the fear around this question comes from one word doing three jobs. “Coding” in a beginner's head usually means building software for a living. What entry-level security work actually asks for is two smaller, different skills. Keeping them separate changes what you study:

Notice the order hiding in that table: command line first, scripting second, software development — if ever — much later. Almost every beginner I see online has it backwards, starting with the biggest, slowest skill and wondering why nothing feels relevant to the jobs they want.

What Tier 1 and entry-level work actually uses, day to day

My guide to what a SOC analyst does all day breaks down the full shift; the technical slice of it is smaller than people fear. Postings and analyst accounts describe the same short list of hands-on tasks, and none of them is “write an application”:

• Searching and filtering logs in a SIEM. The core motion: filter events by user, source IP, and time window, then read what comes back. It is searching with intent, not programming.
• Basic Linux commands. cd and ls to move around, cat and tail to read files and watch new lines arrive, grep to pull the lines that matter out of a thousand that do not, and chmod understood conceptually — who is allowed to read, write, or run a file — because permission questions show up in alerts.
• Windows Event Viewer and basic PowerShell. Finding failed and successful logons in Event Viewer, and knowing that PowerShell's Get-EventLog and its modern successor Get-WinEvent pull those same events from the command line, so a search can be repeated instead of clicked through.
• Reading a script someone else wrote. A teammate's Python or Bash snippet lands in front of you and you need to follow what it does — what file it opens, what it searches for, what it prints — well enough to run it safely and explain the output. Reading comes long before writing.
• Regex basics for log searches. A small set of patterns — matching an IP address shape, “starts with,” “contains Failed” — that make SIEM and grep searches precise instead of hopeful.

That list is why my support background counts for more than I first thought. Two-plus years of remote support at Concentrix and Wipro was tickets, troubleshooting, and documenting what I checked — and the same honesty as my other guides applies: no Zendesk, no Jira, no named support tools I can claim. The transferable part is the thinking: work a queue, check the evidence, write it down. My help desk to cybersecurity guide maps that translation in full.

It depends on the role you actually want

“Cybersecurity” is not one job, and the coding answer changes completely depending on which seat you are aiming at. Pick by the job, not by the loudest advice:

Read the table as a map, not a verdict on your worth. The left-hand column is a legitimate, hireable starting point — it is the one I am aiming at — and the right-hand column stays available years later if you discover you enjoy building things.

What to learn, in this order

I learn by seeing and doing — packet captures and live builds stick for me in a way re-reading never has — and this order is built for that kind of learner. Each step is useful on its own, so you are never more than one step away from something you can demonstrate:

1. Linux command line first. A few weeks of daily reps in a virtual machine: navigate, read files, search with grep, follow a live log with tail. This is the floor everything else stands on.
2. How to read logs. Open a Linux auth log and a Windows Event log and practice finding the story: the failed logins, the success after them, the user, the source. This is the daily bread of Tier 1 work.
3. Python basics — only for log parsing and automation. Variables, loops, opening a file, and one concrete skill: count the lines that contain “Failed password.” That is the whole starting scope. Not app development, not frameworks — one script that reads a log and tells you something true about it.
4. PowerShell and Bash as a second step. Once the Python reps feel ordinary, add the shells: the same searching and counting ideas in the environments Windows and Linux admins actually live in.

One warning, stated as plainly as I can: do not pause Security+, networking, or applying to jobs in order to learn advanced programming first. The cert question is settled in my Security+ guide — it is the credential entry-level postings name — and the hiring sequence is laid out in my SOC analyst timeline. Programming learned slowly alongside those beats programming learned instead of them, every time.

One project you can explain in an interview: the failed-login parser

If scripting feels abstract, here is the single project I point beginners at — it grows directly out of my cybersecurity home lab guide, and it is scoped to what a Tier 1 analyst actually does. Build a small Python script that reads a log file from your own lab — a Linux auth log is perfect — finds every line containing “Failed password,” and counts the failures by source IP and by username. Then it prints a short summary: which IP failed most, which account was targeted, and how many attempts happened in total.

The whole thing is the Python basics from the list above and nothing more: open the file, loop over the lines, keep a running count for each IP and user you see, print the results. Mine fits on one screen, and that is the point. Run it against the lab machine you have been deliberately failing logins on — your own VM, your own account — and the summary is a real finding about a real system, one you can walk an interviewer through line by line. That goes on a résumé under Projects as exactly what it is: a log-parsing script you wrote, ran, and can explain. Safety note, non-negotiable: run this only on your own systems and your own logs. Never scan, probe, or test systems you do not own — the lab exists precisely so you never need to.

Common mistakes

Every one of these is a version of learning the wrong thing in the wrong order — I know because the first two nearly caught me:

• Trying to learn full software development first. Months on app-building tutorials before networking or Security+ means months with nothing a SOC posting asks for. The postings set the syllabus; follow them.
• Tutorial hell with nothing explainable to show. Forty finished courses and not one project you can walk through out loud. Interviewers do not ask how many videos you watched; they ask what you built and what it found.
• Copying scripts you cannot explain. Pasted code you cannot narrate line by line is worse than no code — the follow-up question ends the interview. Small and yours beats impressive and borrowed.
• Skipping Linux. Logs, servers, and security tooling live there. Avoiding the terminal because it feels unfamiliar guarantees it stays unfamiliar — and it is the first skill on the day-to-day list above.
• Thinking no coding will ever be needed. The opposite trap. Tier 1 may not require it, but promotion past Tier 1 runs on scripting and automation. “Not needed to start” is not “never needed.”

A 14-day starter plan (about an hour a day)

Fourteen days will not make you a programmer. It will make the terminal feel like a place you work, which is the actual goal:

1. Days 1–4 — Linux command line in a VM. Spin up a Linux VM in your lab. Day 1: cd, ls, and moving around without the mouse. Day 2: cat and tail on real log files. Day 3: grep for one string, then for one user. Day 4: permissions — read what chmod controls and check who can read the auth log.
2. Days 5–7 — Log searching with grep and regex. Pull every failed login from the auth log, then narrow by user, then by hour. Add one regex pattern a day — an IP shape, a line starting with a month, a count of matching lines — until searching feels like asking questions.
3. Days 8–11 — Python for log parsing. Day 8: variables and printing. Day 9: open a file and loop over its lines. Day 10: count the lines containing “Failed password.” Day 11: count them by IP and by user.
4. Days 12–14 — Run it on your lab and write it up. Point the parser at your home lab logs, fail some logins on purpose on your own VM, and re-run it. Then write the summary the way you would say it in an interview: what you built, what it found, what you would check next.

If you want that progression laid out as a structured path rather than self-directed reps, Hack The Box Academy runs guided Linux and Python-for-security material that lines up with the order above (affiliate link — if you sign up through it, I may earn a commission at no extra cost to you; see this site's disclosure). Free resources can cover the same ground; the structure is what you are paying for.

Honest expectations

Coding is not the gate for the first job. Networking, logs, and triage thinking are — the ability to look at evidence, decide what it means, and write the decision down clearly. That is what Tier 1 postings describe and what my own support years actually trained. What a little scripting does, learned early and in small doses, is make everything else stick: Security+ concepts stop being vocabulary when you have grepped a real auth log, and log reading stops being theory when your own parser has counted the failures. I am not through this door yet myself — I am a student between shifts, building the reps in public. But the reps are the point, and none of them require you to become a developer first.

Affiliate disclosure: This article contains one affiliate link (marked above). If you sign up through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, affiliate recommendations are labeled where they appear, and placeholder links stay placeholders until each program approves this site — recommendations here are based on usefulness, not commission.

CAREER / SOC INTERVIEW GUIDE — NOVEMBER 9, 2026 · ~10 MIN READ

Cybersecurity Interview Questions for Beginners: SOC Analyst Edition — And How to Answer Them Honestly

If you are searching for cybersecurity interview questions for beginners, you may picture a trivia exam. Real Tier 1 SOC interviews are not built that way. I come from a shift supervisor and shift manager background, CompTIA A+ certified, a WGU cybersecurity student studying Network+, with 2+ years of remote tech support behind me. I am not working in a SOC yet — this guide is built from real SOC postings, analysts' accounts, and my own support-interview experience, not from a seat I have not sat in.

This guide follows the roadmap, assumes my SOC analyst timeline, and prepares you to talk about the work in what a SOC analyst does all day. Learn the pattern and most beginner questions stop being surprises.

How a beginner SOC interview is actually structured

Across postings and analyst accounts, the process repeats in four stages:

The recruiter screen. A short call that checks your résumé is true, asks why SOC, and confirms the practical facts: shift availability, start date, work authorisation. Nothing technical to perform — accuracy is the test, which is why your application should already read the way my cybersecurity resume with no experience guide insists: honest titles, real bullets, nothing you cannot explain out loud.

Technical basics. A hiring manager or senior analyst asks the fundamentals in plain language. They listen for understanding with an example attached, not textbook wording — a definition you cannot apply reads as memorised, because it is.

A scenario or triage walkthrough. You are handed a pretend alert — failed logins, a reported email — and asked to talk through your steps out loud. This is the heart of the interview: they score the sequence — verify, check scope, document, escalate. Nobody expects you to close the incident solo.

Behavioral and shift questions. Stories from your real work history, plus the logistics of a 24/7 operation: nights, weekends, holidays, handovers. These decide whether a manager trusts you on a quiet night shift with a loud queue, so they carry more weight than beginners expect.

The technical basics, with model-answer guidance

These questions repeat across beginner postings — the fundamentals behind the Security+ worth-it question. Say each aloud until it sounds like a person, not a flashcard:

“Explain the CIA triad.” Plainly: confidentiality means only the right people can see the data, integrity means it has not been changed without authorisation, availability means authorised people can reach it when they need it. From my support work: confidentiality was verifying a caller's identity before touching their account, integrity was never changing details the customer had not confirmed, availability was the service being up at shift start.

“TCP vs UDP — and what does DNS do?” TCP connects first: it checks delivery and resends what got lost, which is why logins and web pages ride on it. UDP skips the checking and just sends — fast enough for voice and lookups, where a lost packet matters less than a delay. DNS turns a name humans remember into the IP address networks use — so when a user says “the site is down,” DNS failure is among the first things I would check.

“Phishing vs spear phishing — and what would you inspect in a reported email?” Phishing is cast wide: one lure, thousands of inboxes. Spear phishing is aimed: your name, your company, your boss's name, a detail scraped from public posts. I would inspect the real sender address against the display name, a Reply-To pointing elsewhere, the header authentication results — SPF, DKIM, DMARC alignment — links' true destinations versus their visible text, unexpected attachments, and urgency language. Then document what I found instead of deleting the message.

“Firewall vs IDS?” One sentence each. A firewall decides: it allows or blocks traffic by rule, like a gate guard checking a list. An IDS watches and reports: it alerts when traffic looks wrong, like a camera flagging motion — detection without blocking, unless it is an IPS in line. Add “the firewall acts; the IDS informs the people who act” and you have answered past the definition.

Two scenarios, walked through step by step

Both walkthroughs use one skeleton, because real triage does. One boundary first: everything below stays inside your authorised job scope. Never scan, probe, or touch systems outside your own lab or your job's authorisation — curiosity is not authorisation, in an interview answer or on shift.

Scenario A: an alert fires for many failed logins against one account, followed by a single success.

1. Verify the alert. Go to the authentication logs themselves, not just the alert summary. Confirm the failures are real, note the exact timestamps, the account, and the event source.
2. Check scope. One user or many? One source IP or a spread? Is the success from the same source as the failures, and inside the same time window? A success from the failing IP looks like a brute force that landed; a success from the user's usual location may be a forgotten password finally remembered.
3. Preserve and document. Record the event IDs, source IP, timestamps, and what you checked — in the ticket, as it happens. Do not delete log entries or “tidy up” the account history; that evidence is the next tier's starting point.
4. Contain only within Tier 1 authority. Do what your playbook actually gives Tier 1 — for example flagging the account and prompting a password reset if that is in your remit. Anything beyond the playbook is not yours to improvise.
5. Escalate with a clear note. Who: the account and user. What: repeated failures, then a success. When: the time window. Source: the IP and whether it matches the failures. What was checked: logs reviewed, scope confirmed, actions taken. Five facts, no adjectives.

Scenario B: a user reports a suspicious email — and tells you they already clicked it.

1. Verify the report. Get the original message with full headers preserved. Confirm what the click actually did: a page opened, a file downloaded, credentials typed in, or nothing visible at all.
2. Check scope. Who else received the same email? One user or a company-wide run? Same sender and subject across the team changes this from one person's mistake to a campaign.
3. Preserve and document. Keep the email and headers intact — do not delete them. Write down the user's own timeline: when it arrived, when they clicked, what happened next, in their words.
4. Contain only within Tier 1 authority. Follow the playbook steps your tier owns — commonly a credential reset if they entered a password, and ticket notes for the team — and nothing beyond it. Do not wipe the machine or pull network access on your own call unless the playbook says Tier 1 does.
5. Escalate with a clear note. Who reported it and who clicked, what the email was and what the click did, when each step happened, the source sender and links, and what you already checked. The next tier should never have to re-ask the user the first five questions.

Behavioral questions: translating non-cyber experience honestly

“Tell me about a difficult customer.” Support and shift work earn their keep here. Mine: an angry caller, mid-shift, convinced the problem was being ignored. What worked was de-escalation in order — let them finish, repeat their problem back in their own words, state the one next step and when I would update them, then document the call so the next person never made them start over. That is alert triage with a person attached: calm intake, verified facts, clear notes. My help desk to cybersecurity guide maps the full translation.

“How do you feel about nights and weekends?” Answer honestly: a SOC runs 24/7, and the roster is not a surprise to negotiate away later. Shift work is the honest evidence — I have worked the hours others plan around, and I know what a night rotation costs and how I manage sleep around it. If you genuinely cannot do nights, say so here, not in week two; a truthful no protects you and the team, and some SOCs run day-weighted schedules.

“Tell me about learning something hard.” Use a real stuck point, not a humble-brag. Subnetting was mine: masks and CIDR would not stick from reading, however many charts I re-read. Hands-on fixed it — building each mask from its switch values, counting, then proving the answer a second way with block size, on a fresh address, out loud. That is now my pattern for anything stuck, packet captures included — the method behind my cybersecurity home lab for beginners: see it, do it, write down what it did.

The honest-answer framework: what I know, what I would check, when I would escalate

Run any answer you are unsure of through three beats. What I know — the part you genuinely have, said plainly. What I would check first — a concrete step: a log, a header, a source, not “I would investigate.” When I would escalate — the condition that hands it up, named before anyone asks. It works because it is a good Tier 1 shift in sentence form.

In full, for a tool touched only in a lab: “I have practised Splunk searches in my home lab; I have not used it in a production SOC, but here is the search I would start with for failed logins: pull the authentication events, filter to failures, group by user and source IP, and look for one source failing against many accounts, or one account failing repeatedly before a success. If that pattern appeared, I would document it and escalate.” Every clause true, checkable, useful.

And the warning under it all: never claim production SIEM, Zendesk, Jira, or ticketing experience you do not have. My applications say it outright — no Zendesk, no Jira — because the platforms I actually used were not those, and inventing them is a lie with a follow-up question attached. Interviewers probe tool claims immediately; a lab-honest answer survives probing a padded one cannot.

Common mistakes

• Memorised definitions with no example. A perfect CIA triad recital with no work story reads as a flashcard. Attach one real example to every definition.
• “I would fix it myself.” Promising to solve everything solo tells a manager you do not understand tiers, playbooks, or escalation — the opposite of the judgment they are hiring for.
• Guessing instead of verifying. When you do not know, say how you would check: which log, which header, which source. “I would verify it in the auth log” beats a confident wrong answer every time.
• Bad-mouthing a previous employer. Every complaint about your last manager is heard as a preview of what you will say about this one. Describe what you learned; leave the verdict out.
• No question ready for the interviewer. Silence at “any questions for us?” reads as indifference. Three a beginner can honestly ask:

1. “What does a good Tier 1 escalation note look like on this team — can you show me an example?”
2. “How is the shift structured, and how are handovers run between tiers?”
3. “What do the analysts who succeed here in their first ninety days do differently?”

A 14-day prep plan (about an hour a day, working full time)

1. Days 1–3 — Technical basics, out loud. One topic a day from the section above: CIA triad and TCP/UDP/DNS first, phishing and headers second, the five ports and firewall vs IDS third. Say each answer to the room, not in your head — interviews are spoken, so prep should be too.
2. Days 4–6 — The two scenarios, out loud. Walk Scenario A until the five steps come in order without notes, then Scenario B, then alternate. Record yourself on your phone once; the gaps you hear are the study list.
3. Days 7–9 — Behavioral stories, written from real work. One story a day, taken only from your actual support or shift history: the difficult customer, the shift question, the hard thing learned. Write each as situation, what you did, what changed — four or five lines each, true ones.
4. Days 10–12 — Home-lab proof you can describe. Capture one packet capture in your lab and talk through what it shows; review one failed-login log — your own lab's, with failures you caused on purpose — and write the escalation note for it. Two artefacts, both explainable line by line.
5. Days 13–14 — Mock interview and your questions. Day 13: a full mock run, ideally with another human, timed answers, framework on anything unknown. Day 14: light review, your three questions for them written down, and the logistics — route, documents, sleep — settled like a shift.

For structured reps behind those answers, Hack The Box Academy runs log-analysis and SOC-fundamentals material practising exactly what these interviews test (affiliate link — if you sign up through it, I may earn a commission at no extra cost to you; see this site's disclosure). The wider cert-and-path calls sit in the decision guides; the rest of the shelf is the guide library.

You do not need to have done the job to interview well for it — only to show, truthfully and in order, how you would think through its first hour. That is learnable between shifts.

Affiliate disclosure: This article contains one affiliate link (Hack The Box Academy, marked above). If you sign up through it, I may earn a commission at no extra cost to you. Per this site's disclosure policy, recommendations are based on usefulness, not commission.

COMPTIA / CERT COMPARISON — NOVEMBER 8, 2026

A+ vs Network+ vs Security+: Which Cert First?

Three CompTIA certs, three different jobs. A+ proves you can fix computers, Network+ proves you can run the network they talk over, and Security+ proves you can defend both. Picking the wrong first one does not ruin anything — it just costs you months and an exam fee you did not need to spend yet. Here is the whole decision on one page.

Paid links — book prices change, so the buttons check the current Amazon price instead of quoting one here.

The 30-second decision

1. No hands-on IT experience yet?Start with A+. It is the floor the other two stand on, and it is the one that gets you a paying help-desk job while you keep studying.
2. Have A+ or help-desk experience, but networking feels fuzzy?Study the Network+ material first — subnets, ports, protocols, troubleshooting. Sit the Network+ exam itself only if your target role names it, or your networking self-check comes out weak.
3. Aiming at a SOC or junior security role?Go Security+ first. It is the cert entry-level security postings and the DoD 8140 baseline actually name — then fill networking gaps deliberately instead of collecting both certs before you ever apply.

What a summary cannot tell you

A comparison table picks the cert; it does not get you through it. The order only pays off inside a weekly rhythm you can keep between shifts: one objective at a time, one lab a week as proof, and a stuck log you actually review. That rhythm is the 90-day roadmap — days 1–30 build the floor, days 31–60 turn study into documented practice, and days 61–90 aim everything at a real role. When you are ready to buy, buy in the order on the study kit page: free resources first, one book for the cert you picked, and the exam voucher last — only when your practice scores say you are ready.

One honest limit, because this site does not do guarantees: none of these certs promises a job. Each one clears a specific filter. The labs, write-ups, and experience you stack on top are what get you picked — which is why the free practice comes before the paid book on the kit page.

Keep reading: the study kit, in purchase order, Network+ vs Security+ in depth, is Security+ worth it in 2026, is A+ still worth it in 2026, the 90-day roadmap, the full guide library, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This page contains paid affiliate links to Amazon (marked above). If you buy through them, I may earn a commission at no extra cost to you. As an Amazon Associate I earn from qualifying purchases. Exam prices above are CompTIA voucher list prices as of this writing — verify the current price and exam version on CompTIA's site before you pay.

STUDY KIT / BOOKS & GEAR — NOVEMBER 8, 2026

The Beginner Study Kit: What to Buy, In Order

Every book and piece of gear this site recommends, collected on one page and put in the order you should actually get them: free resources first, one book for the cert you picked, a little gear only when you will use it, and the exam voucher dead last. If you buy nothing this week, start at step 1 anyway — it costs nothing.

Not sure which cert you are kitting out for? Decide first on the A+ vs Network+ vs Security+ comparison — one book per cert below, and you only need the one for your next exam.

Step 1 — Free first

1. FREE / VIDEO

   Professor Messer's free exam series on YouTube

   The free video backbone for all three certs — the N10-009 and SY0-701 series are the ones this site points Network+ and Security+ students to, and the study path here starts with them before any book is opened.

   Cost: $0 · Start here, tonight
2. FREE / HANDS-ON LABS

   TryHackMe free rooms — one room a day

   Guided rooms that teach the concept first, then test you on it, so you are never staring at a blank terminal. Start on the free tier, finish the free beginner material, and only pay if you hit the wall the free tier puts in front of you.

   Cost: $0 to start · See the TryHackMe vs Hack The Box guide for the starter routine
3. FREE / HOME LAB

   A $0 home lab on the computer you already own

   VirtualBox (free) with Kali Linux, Ubuntu Server, and a Windows evaluation VM on an isolated virtual network. A $0 lab you use every day beats a $500 lab you never turn on.

   Cost: $0 · Build it with the beginner home lab guide

Step 2 — One book per cert (buy only yours)

1. BOOK / COMPTIA A+

   Mike Meyers' CompTIA A+ study guide

   The book to work through alongside the A+ exam objectives if A+ is your cert — plain coverage of the hardware, operating systems, and troubleshooting the two Core exams test.

   Book prices change — check the current price on Amazon
   Check price on Amazon
2. BOOK / COMPTIA NETWORK+

   CompTIA Network+ study guide

   The networking reference for N10-009 study — keep it next to the daily ports, cables, and subnetting drills, because those topics are reps, not reading.

   Book prices change — check the current price on Amazon
   Check price on Amazon
3. BOOK / COMPTIA SECURITY+

   Darril Gibson — Get Certified Get Ahead (Security+ SY0-701)

   Plain language and organized around the objectives, which suits an hour-a-day schedule between shifts. This is the Security+ book this site has recommended from the start.

   Book prices change — check the current price on Amazon
   Check price on Amazon

Step 3 — Gear, only when you will use it

1. GEAR / HOME LAB

   Raspberry Pi starter kit

   A small, cheap second machine for a hands-on home lab — useful once the free virtual lab is a habit and you want a physical box to run services, capture traffic, and break safely.

   Prices change — check the current price on Amazon
   Check price on Amazon
2. BOOK / LATER, OPTIONAL

   The Web Application Hacker's Handbook

   Deeper web application security reading for after the fundamentals — not a first purchase. It belongs in the hands-on proof stage, once the cert book is underway and you are documenting real lab work.

   Prices change — check the current price on Amazon
   Check price on Amazon
3. GEAR / PRIVACY BASICS

   NordVPN

   For lab work and everyday browsing on networks you do not own: look for a no-logs policy, a kill switch, and modern WireGuard speeds — the rest is marketing. This is the VPN this site recommends in privacy contexts.

   Subscription — check the current plan price on NordVPN's site
   Check NordVPN plans

Step 4 — The voucher, last

1. EXAM VOUCHER / BUY LAST

   Your CompTIA exam voucher

   Buy this only when your practice scores say you are ready — a cheap voucher is expensive if it pressures you into an exam before you are. Verify the exact exam version first (Network+ is N10-009 and Security+ is SY0-701 as of this writing), compare only legitimate sellers and bundles, and read the expiration and retake terms before checkout. A+ means two vouchers, bought and taken one core at a time.

   List prices as of this writing: Network+ $369 · Security+ $404 — verify on CompTIA's site before you budget
   Read the voucher rules first

The whole kit, in one breath

Free video, free labs, and a $0 home lab first. One book — the one for your cert. A Pi only once the lab habit is real. The voucher only when you are ready to sit the exam. That order is the entire point: spending follows proof, never the other way around, and it is the same order the 90-day roadmap runs on.

Keep reading: A+ vs Network+ vs Security+ — pick your cert, build the $0 home lab, TryHackMe vs Hack The Box for beginners, decisions before purchases, the full guide library, and A+ vs Network+ vs Security+ — which cert should you take first?.

Affiliate disclosure: This page contains paid affiliate links to Amazon and NordVPN (marked above). If you buy through them, I may earn a commission at no extra cost to you. As an Amazon Associate I earn from qualifying purchases. Prices change — every button above checks the current price instead of quoting one here, and exam voucher prices should be verified on CompTIA's site before you budget.