From IT Help Desk to Cloud Security

Why help desk is a better start than you think

Most people leaving the help desk apologize for it. "I'm just in support." Stop doing that. The help desk is where you learned the unteachable parts of the job - the parts bootcamp graduates and fresh CS grads conspicuously lack. The cloud knowledge is the part you can study. The instincts are the part you already have.

Here's what you actually bring, framed the way a hiring manager hears it:

None of this means you're ready today. It means you're starting from base camp, not from the parking lot. The work ahead is to bolt cloud depth and a security mindset onto instincts you already own.

The honest timeline (and why there's no overnight jump)

If a course or influencer promises you a six-figure cloud security job in 90 days from the help desk, close the tab. That's not how the hiring market works, and chasing it is how people waste a year and a few thousand dollars.

Here's the realistic shape, assuming roughly 6-10 focused hours a week of study plus deliberate repositioning at work:

• Months 0-6: Foundations. One cloud's core services, Linux, networking basics, and the start of an IAM mental model. First fundamentals cert. First home-lab account stood up.
• Months 6-12: Depth and proof. Associate-level cloud cert, Terraform and a scripting language, your first one or two portfolio projects published. You start sounding like someone who works in cloud, not someone studying it.
• Months 9-18: The first move. You land a stepping-stone role - junior cloud, DevOps-with-security, SOC analyst, or CSPM analyst - either internally or externally. This is the hardest single step, and the most important.
• Months 18-36: The pivot. From the stepping-stone role you add security-specific depth and pivot into a clearly titled cloud security role. The second move is far easier than the first.

The single biggest variable isn't intelligence or money. It's whether you can get your hands on real cloud in your current job, or have to manufacture that exposure through a lab and portfolio. People with supportive managers who let them touch the cloud or security team move fastest. Everyone else manufactures the evidence - which is entirely doable, just slower.

Pick the target role first

"Cloud security" isn't one job - it's at least seven, with very different day-to-day work and hiring bars. The most common mistake out of help desk is studying everything at once and aiming at a fuzzy "cloud security engineer" target. Pick a destination first; it tells you what to study and which stepping-stone to take.

Read the full role taxonomy on the careers page, but here's the quick map of which targets pair naturally with a help-desk background:

• CSPM / CNAPP analyst - triaging cloud misconfiguration findings in a tool like Wiz, Orca, or Defender for Cloud. Underrated, dashboards-and-tickets shaped, and the most help-desk-adjacent way in. Strong first target.
• Cloud security engineer (generalist) - the default destination. Breadth over depth, exactly your strength, but usually a second move rather than a first.
• Detection engineer or cloud-focused SOC - if you like the "what would I look for" puzzle and reading logs. Pairs with a SOC analyst stepping-stone.
• IAM / identity - if your help desk life was heavy on Active Directory, Entra, group policy, and access requests. The most strategically valuable specialty right now, and a natural extension of identity work you already do.
• GRC / compliance - if you're organized, document well, and like the policy side more than the packet side. Less code-heavy; a real on-ramp for people who don't love the command line.

You don't have to marry the first target - you'll learn more about what you actually like once you're in a stepping-stone role. But aiming at one specific destination for the next 6-12 months beats spraying study time across all of them.

The stepping-stone path

The fastest route is almost never a straight line from help desk to a security title. It's one role-step from where you are now, then a pivot. Trying to leap the whole gap in a single hire is the most common reason capable people stall for years applying to roles they can't yet land.

Which stepping-stone is fastest for you?

• If your shop already uses AWS/Azure/GCP and you can volunteer for cloud tasks: aim for junior cloud / sysadmin. The internal move is often the single fastest path - you keep your tenure and relationships and just change what you touch.
• If you like logs, alerts, and the hunt: aim for SOC analyst, ideally somewhere with cloud log sources. SOC is a famously good security on-ramp and frequently hires straight from help desk.
• If you're organized and tool-oriented but not yet deep on code: aim for CSPM/CNAPP analyst. Companies that bought a cloud security platform need humans to make it useful, and the work is close to the triage you already do.
• If you already script or automate to make your own job easier: aim for DevOps / cloud support, then shift left into security. Security teams are desperate for people who can actually ship code.

The skills gap to close

Between help desk and a cloud security role sits a specific, finite set of skills. It's finite - that's the encouraging part. You're not learning "everything"; you're closing a known list. Roughly in priority order:

1. One cloud, at depth

Pick AWS by default (biggest job market), Azure if your shop is Microsoft-heavy, GCP if you have a specific reason. Learn its core compute, storage, networking, and logging services well. Resist the urge to "learn all three" - "I know AWS well" beats "I know AWS, Azure, and GCP" most of the time.

2. Linux and the command line

Cloud security is API-first and terminal-first. You don't need to be a kernel hacker, but you need to be comfortable in a shell, in ssh, in reading logs from the command line, and in basic scripting. If the console is where you live, you'll struggle; the console is for screenshots, not work.

3. Networking fundamentals, cloud-flavored

You already know more networking than you think from help desk. Map it onto the cloud equivalents: VPCs and subnets, security groups vs. firewall rules, routing, DNS, load balancers, private vs. public endpoints. The mental model transfers; the names change.

4. Identity and access management - the big one

If you learn one thing deeply, make it IAM. Identity-based vs. resource-based policies, roles and trust policies, assume-role, least privilege, federation and SSO. In interviews, the ability to explain IAM precisely is the single fastest way to separate yourself from the pile. Your help-desk identity work (AD groups, MFA, access requests) is the perfect foundation - the careers page has a full IAM/identity track.

5. Infrastructure as code and a scripting language

Learn Terraform well enough to stand up and tear down real infrastructure, and pick up Python or PowerShell to the point where you can write a script that calls a cloud API. This is the difference between "studied cloud" and "works in cloud" on a resume.

6. The security mindset and cloud-native tooling

Last, layer on the security-specific knowledge: CSPM/CNAPP posture management, the cloud's native logging (CloudTrail, Activity Log, Audit Logs) and threat detection (GuardDuty, Defender, SCC), the SIEM, common misconfigurations, and the shared responsibility model. The learning path sequences all of this in detail.

A 12-month study plan, month by month

This is one concrete sequence, tuned for someone working full-time on a help desk with ~6-10 hours a week to spend. Treat it as a default to adapt, not a law. The through-line: learn a thing, then immediately build something small with it and write it down publicly. Consumption without production is the trap that keeps people studying for three years and landing nothing.

Months 1-3 - Cloud literacy

• Open a free-tier account in your chosen cloud on day one. Touching it beats reading about it.
• Work through a structured fundamentals course (your cloud's official fundamentals path is free or cheap).
• Sit a fundamentals cert: AWS Cloud Practitioner, AZ-900, or Cloud Digital Leader. It's not impressive on its own, but it forces breadth and gives you an early, concrete win.
• Get comfortable in the Linux terminal in parallel - 20 minutes of practice most days.

Months 4-6 - Depth and IAM

• Start the associate-level track (AWS Solutions Architect Associate or your cloud's equivalent). Don't necessarily sit the exam yet; use it as a curriculum.
• Go deep on IAM. Build, read, and break policies in your lab account until trust policies and least-privilege feel obvious.
• Learn the basics of Terraform: stand up a VPC, a server, and an IAM role from code, then destroy it.
• Stand up your first deliberate home lab and start keeping notes you could publish.

Months 7-9 - Security and your first build

• Layer on security: run a free posture scanner (Prowler, ScoutSuite, or your CNAPP's free tier) against your own account and read every finding.
• Do your first cloud CTF - walk a CloudGoat scenario end to end.
• Publish your first portfolio project: the CloudGoat write-up, with your kill chain, screenshots, and remediation. A blog plus a public GitHub is enough; see the portfolio playbook.
• Sit the associate cert if you're ready - now it's backed by real hands-on work.

Months 10-12 - Proof and the search

• Build a second project - ideally one that looks like real work: a multi-account org with SCPs in Terraform, or a small detection lab. Write it up.
• Start a security-specific cert if your target calls for it (CCSK, your cloud's security specialty, or Security+ for a SOC lean).
• Turn the job search on: target the stepping-stone roles, not just "cloud security engineer." Show up where hiring happens - CSOH Friday Zoom, local meetups, online communities.
• Get your resume and LinkedIn repositioned around what you can now demonstrably do.

Certifications, in the right order

Recruiters use certs to pass the resume screen; hiring managers use portfolios to decide. So certs are necessary but not sufficient - and the order matters more than any single one. A practical sequence out of help desk:

1. Cloud fundamentals (month ~3): AWS Cloud Practitioner, AZ-900, or Cloud Digital Leader. Proves baseline literacy. Cheap, fast, a confidence win.
2. Associate cloud (month ~9): AWS Solutions Architect Associate, Azure Administrator (AZ-104), or GCP Associate Cloud Engineer. Proves real depth in your chosen cloud. This is the one that actually moves your resume.
3. Security-specific (month ~12+): CCSK (vendor-neutral cloud security, widely respected and a great signal of intent), AWS Security Specialty / AZ-500 (cloud-specific security depth), or CompTIA Security+ if your target leans SOC/defensive or you're eyeing roles that list it as a baseline.

Don't stack certs without a portfolio - three certs and zero public projects looks worse than one cert plus a CloudGoat repo. And don't chase the famous-but-advanced credentials (CISSP, CCSP) early; they're built for people with years of experience and won't help you out of help desk. The full breakdown by career stage lives on the certifications guide.

The home lab and portfolio that get you hired

This is the part that converts. A help-desk resume with one associate cert and three real, public projects beats a resume with five certs and nothing to show. Your portfolio is your interview - it's the hands-on evidence hiring managers say they want above everything else.

You don't need to spend money. A free-tier account, a GitHub, and somewhere to write (a free blog, dev.to, even well-organized GitHub READMEs) is the whole toolchain. Build the lab first - see the home lab guide for a safe, free setup with billing guardrails so you never get a surprise bill - then turn lab work into public artifacts.

Three projects, picked from the portfolio playbook, are plenty for a first move:

• Walk a CloudGoat scenario and publish the kill chain and remediation. The canonical project - most interviewers have done it and will recognize that you did the work.
• Build a multi-account org with SCPs in Terraform and push the code. Production-shaped work that signals "this person can actually operate."
• Run Prowler against your own account and remediate everything, documenting before/after. Directly mirrors the day-to-day of a CSPM analyst - your likely first target.

What not to build: a "cloud security dashboard" toy web app. Hiring managers see hundreds. Build operational artifacts that look like the actual job.

Reposition the job you already have

Here's the move most people miss: you don't have to wait for a new job to start doing cloud and security work. The help desk sits next to both, and a little initiative converts "support tech" into "the support tech who handles our cloud and security stuff" - which is the bridge.

• Volunteer for the cloud-adjacent tickets. The SSO issue, the cloud app access request, the MFA rollout, the "can you check why this S3 link is public" - take them. Each one is a resume bullet and a relationship with the cloud or security team.
• Ask to shadow the security or cloud team. Most will say yes to a curious, reliable person. An hour a week watching them work teaches you what no course does: how the job actually feels.
• Automate part of your own job. A PowerShell or Python script that closes repetitive tickets is a portfolio piece and a demonstration of the exact instinct security teams hire for.
• Become the security-aware one. Flag the phishing patterns you see, suggest the MFA improvement, write the better offboarding checklist. Visible security initiative gets you invited to the table.
• Tell your manager your goal. Counterintuitively, good managers help. "I want to grow toward cloud security - can I take on more of our cloud and security tickets?" reframes you as ambitious, not as a flight risk, and often unlocks exactly the exposure you need.

Translating help desk experience on your resume

The content of your help-desk job is more relevant than its title suggests - but only if you translate it into the language of the role you want. Lead with results and the security/cloud-adjacent slice of what you do, not a generic "provided technical support" line.

Translate, don't fabricate:

• "Reset passwords and managed accounts" → "Administered identity and access for 600+ users: MFA enrollment, group-based access provisioning, and joiner-mover-leaver workflows in Active Directory / Entra."
• "Handled tickets" → "Triaged and resolved 30+ daily incidents against SLA, documenting root cause and remediation in ServiceNow."
• "Helped with security stuff" → "Identified and escalated phishing campaigns; drove an MFA-coverage improvement from 78% to 99% across the user base."
• "Learned AWS on my own" → "Built and secured a multi-account AWS lab in Terraform; published a CloudGoat attack-and-remediation write-up (link)."

Then the universal rules: results over responsibilities (numbers force specificity), one page early-career, mirror the job description's language so the applicant-tracking system matches you, and make your LinkedIn and GitHub do the talking - link your write-ups everywhere. Recruiters source heavily from LinkedIn; a headline that says what you're becoming, plus pinned project links, punches above its weight. The careers page covers the full application game.

Internal transfer vs. external jump

You have two routes off the help desk, and most successful transitions use the first one at least once.

The internal transfer

Move to a cloud, DevOps, SOC, or security-adjacent team at your current employer. Advantages: they already know you're reliable, your tenure and relationships carry over, the hiring bar for a known quantity is lower, and you often get to learn on the job with a safety net. Disadvantages: the role may not exist yet (you might have to help create it), and internal pay bumps are sometimes smaller than an external jump. Still, as a first move, the internal hop is usually the fastest and lowest-risk.

The external jump

Apply out to a stepping-stone role at a new company. Advantages: a clean title change, often a bigger comp step, and access to roles your current employer doesn't have. Disadvantages: you're an unknown competing against other applicants, so you lean entirely on your portfolio and certs to clear the bar. The external jump tends to work better as a second move - once you have a cloud or security title from the internal hop, the external market opens up.

A common, effective pattern: internal hop to a cloud/SOC/DevOps role to get the title and the hands-on reps, then jump externally 12-18 months later into a clearly titled cloud security role at a meaningful comp step.

A week in the life, mid-transition

The plan above is a schedule; here's the texture. This is a composite, illustrative week of someone nine months into the transition - still on the help desk full-time, study habit established, first project published. The specifics are fictionalized; the rhythm is drawn from how people who actually make this work spend their time.

Monday. Day job. But a ticket comes in about a contractor who still has access two weeks after their end date. Instead of just revoking it, you spend ten extra minutes documenting the gap in the offboarding process and send your manager a short note proposing a fix. That note is a resume bullet being born. Evening: 45 minutes on the Terraform module you're building for project two.

Tuesday. Day job. Slow afternoon, so you shadow the SOC for an hour - you asked last month and they said yes. You watch an analyst triage a GuardDuty finding and finally see how the log story comes together. Evening: off. Rest is part of the plan.

Wednesday. Day job. Evening: an hour in your lab. You deliberately misconfigure an S3 bucket, run Prowler, and watch it flag exactly what you broke. You screenshot it for the write-up. Small loop, real understanding.

Thursday. Day job. Lunch: 20 minutes reading the reading list on your phone. Evening: you draft the README for project two and push a rough version to GitHub. It's not polished. You publish it anyway.

Friday. Day job. Noon: you drop into the CSOH Friday Zoom for 30 minutes on your break and ask a real question about your IAM project. Someone who hires for these roles answers it. Evening: off.

Weekend. One focused 2-3 hour block - the associate-cert track and a few practice questions. The other day is yours. You went from base camp to clearly-moving in nine months not by heroics but by this: a steady weekly loop, building in public, and steering the day job toward the destination. That's the whole secret.

Common mistakes

• Trying to leap straight to "Cloud Security Engineer." The titles you can land first are "SOC Analyst," "Cloud Support Engineer," "CSPM Analyst," or "Cloud Engineer (Security focus)." Same trajectory, vastly bigger funnel.
• Collecting certs with no portfolio. Certs pass the resume screen; projects pass the interview. You need both, and the projects are the rarer signal.
• Learning all three clouds at once. One cloud at depth beats three at the surface, every time. Pick one and go deep.
• Studying in private for two years. If your work isn't public, it doesn't count in a job search. Build in public from month three, imperfectly.
• Quitting the help desk to "study full-time." Almost always a mistake. You learn faster in a job adjacent to your target than alone, and the paycheck removes the desperation that makes people take bad first roles.
• Ignoring the job you already have. The cloud and security tickets in your current queue are free experience and free relationships. Repositioning in place is the most underused lever.
• Going dark on networking. Half of these jobs come through someone who knows someone. Showing up - online communities, meetups, the Friday Zoom - is not optional flavor; it's a primary channel.
• Waiting until you "feel ready" to apply. You will not feel ready. Apply when you can demonstrate the work, not when the impostor feeling goes away - it doesn't, for anyone.

How AI changes this path

AI cuts both ways for someone climbing out of the help desk, and it's worth being clear-eyed about both.

The tailwind: AI is the best study partner a career-changer has ever had. It explains an IAM policy line by line at exactly your level, generates practice scenarios, reviews your Terraform, drafts the first version of a project write-up, and answers the "dumb" questions you'd be embarrassed to ask a person - at 11pm, for free. Used well, it compresses the months-1-to-9 learning curve meaningfully. Lean into it as a tutor.

The headwind: the same AI is also raising the floor on what "entry-level" means and automating some of the rote first-tier support and triage work that historically gave help-desk techs their on-ramp reps. Tier-1 ticket deflection, password self-service, and AI-assisted triage are real. The bottom rung is getting thinner.

The synthesis: AI rewards the people who use it to climb faster and punishes the people who compete with it on rote tasks. So use it as a tutor to accelerate, but make sure the skills you're building are the ones AI doesn't replace - judgment, hands-on system work, the security mindset, and the human-translation skills you already have from the help desk. Demonstrate that you build with AI (it's a positive signal now, the way scripting was a decade ago) rather than that you can be replaced by it. The honest read for the next few years: this transition is still very much open, but the people who make it will be visibly AI-fluent.

Studying while working full-time without burning out

The plan only works if you can sustain it for a year-plus alongside a draining job. Most failed transitions don't fail on ability; they fail on burnout in month four. A few things that keep people in the game:

• Consistency beats intensity. Six focused hours a week for a year crushes a heroic month followed by three months of nothing. Protect a small, repeatable weekly rhythm.
• Bound the study time. Pick your blocks (e.g., three weeknights and one weekend morning) and then actually stop. Open-ended "I should be studying" guilt burns more energy than the studying does.
• Build, don't just consume. Passive course-watching is both less effective and more exhausting than building something small. Hands-on work is more tiring per minute but far less draining over months because you can see progress.
• Take the win days. Passed a cert, shipped a project, got a shadow session - mark it. The transition is long; unacknowledged progress feels like no progress, and that's what makes people quit.
• Find two or three people on the same road. A study buddy, a Discord, the Friday Zoom. Isolation is the quiet killer of long projects; company makes the grind survivable.
• Protect your day-job performance. Don't let the side quest tank the thing that pays you and is also your fastest internal-transfer ticket. A strong help-desk reputation is an asset in the transition, not an obstacle to it.

Resources

Everything you need for this path already lives on this site, sequenced and vendor-neutral. The route through it:

• The cloud security learning path - the skills foundation underneath this whole transition, beginner to working practitioner.
• Cloud security careers - the role taxonomy, salary bands, interview formats, and the full adjacent-role pivot map. Read the roles section to choose a target.
• Home lab guide - a safe, free playground with billing guardrails so you can practice without fear.
• Portfolio projects - step-by-step walkthroughs of the projects that get interviews.
• Certifications guide - which credential at which stage, without the cert-stacking trap.
• Cloud CTF directory - CloudGoat and friends; the hands-on hacking practice that becomes your write-ups.
• Reading list & people to follow - the practitioners and publications hiring managers also read.
• Mentorship - because a 30-minute conversation with someone a few steps ahead is the highest-leverage hour in any career change.
• Friday Zoom sessions - free, weekly, practitioners who hire and people who got hired. Bring your transition questions.