Moving from system administration to cloud security

You run servers, a directory, backups and networks, and cloud security appeals to you. You start with more assets than you might think, along with a few habits to unlearn. This guide helps you sort out what transfers, what you are missing and how to prove it to an employer.

Why system administration is a good starting point

Cloud security is not a world apart. Behind the consoles and managed services sit concepts you already handle: identities, permissions, machines, network flows, logs and backups. A system administrator knows what breaks in production, what a poorly prepared update can cause and why an overly broad firewall rule always ends up causing trouble.

Many employers value this practical sense in people who come from operations: they understand that a security measure has to work day to day, not just on paper. It is a point we stress to employers in our guide to hiring a cloud security engineer.

The move is still a real change of job. It means working at a different scale, with different tools and a different mindset.

What transfers, and what changes

The table below maps what you already know to what it becomes in a cloud environment.

What you master	Its cloud equivalent	What really changes
Directory, accounts, groups, delegation	The provider's identity and access management, roles, service identities, federation	Permissions are finer grained and more numerous, and a single mistake can expose a whole organisation
Firewalls, VLANs, VPNs	Virtual networks, security groups, private endpoints, gateways	Exposure to the internet can happen in one click, without going through the network team
Server hardening	Golden images, policies enforced across the organisation	You harden a template and block deviations, rather than fixing each machine
Admin scripts	Infrastructure as code, deployment pipelines	Code becomes the source of truth; the console is no longer the main tool
Monitoring and system logs	Provider activity logs, centralisation, detection	The events to watch are mostly about identities and API calls
Backups and disaster recovery	Replication, immutability, separate backup accounts	An attacker with high privileges can delete the backups too

The change in mindset

An administrator often fixes problems personally, quickly and directly. In cloud security, your value lies more in what you make impossible or visible to everyone: a guardrail that stops anyone making storage public, a safe deployment template teams reuse, an alert that fires at the right moment. You move from "I fix it" to "I make sure the mistake cannot happen again".

The skills to build first

Do not try to learn everything at once. Focus on what comes up in almost every job ad.

The provider's identities and permissions. This is the core topic. Understand access policies, the difference between users, roles and service identities, inherited permissions and how to actually apply least privilege.
Organising environments. Separating accounts, subscriptions or projects, organisation-wide policies, isolating production from test.
The shared responsibility model. Being able to say, service by service, what the provider secures and what stays with you.
Infrastructure as code. Writing and reviewing infrastructure code, understanding a deployment plan, adding automated checks before anything reaches production.
Logging and detection. Knowing which logs to enable, where to centralise them and what to look for after an access key leaks.
Data protection. Encryption, key and secret management, spotting exposed storage.
Containers and Kubernetes, if the roles you target mention them: service account permissions, isolation, image security.

Pick a main provider

AWS, Azure and GCP share principles, but their models differ. Start with one, ideally the one that dominates in the companies you are targeting or the one your current employer already uses. If you come from a Microsoft environment with Active Directory, Azure and Entra ID often make for a more natural transition. Once you understand one provider well, learning a second goes much faster.

A realistic learning plan

The pace depends on your available time and your starting point. Here is a sequence that works for many people; adapt it to your situation.

The basics of your chosen provider. Create a personal account, turn on billing alerts and strong authentication on day one, then explore the main services.
Identities in depth. Build a small organisation with several accounts or subscriptions, distinct roles and federation if you can. Deliberately grant too many permissions, then cut them back.
Rebuild everything as code. Recreate your environment in infrastructure as code, version it in a repository and add a configuration scanning tool to the pipeline.
Log and detect. Centralise activity logs, create a few simple alerts (a new access key, storage made public, a privileged account signing in) and check that they fire.
Break and repair. Introduce classic misconfigurations into your lab, then detect and fix them as you would at work.

One precaution: only use your own accounts or environments designed for training. Testing resources that do not belong to you is still illegal, in the cloud as anywhere else.

What about certifications?

Provider certifications give your learning structure and help you through early screening. They belong in your plan, ideally after a first phase of hands-on practice. Keep in mind that some of these exams rely on multiple-choice questions: they complement practice, they do not replace it. Our article on what certifications really say about a candidate explains how employers read them.

Start the transition in your current job

The shortest path often runs through your current employer. If your company already uses the cloud, or plans to migrate, offer to take on work at the edge of your role:

reviewing access rights in an existing environment and proposing a clean-up;
setting up log centralisation and a few alerts;
joining an application migration to bring the security point of view;
moving part of the infrastructure that is still managed by hand into code;
documenting configuration gaps and following up their remediation with the teams.

This gives you real production experience you can describe precisely in interviews. It is often worth more than a lab project, because it shows you can get a change accepted.

Prove your skills to recruiters

An administrator presenting themselves as "moving into cloud security" has to make their skills visible. A few things make the difference:

A public code repository with your lab environment in infrastructure as code, a clear README and the checks you added.
A short write-up: your lab's initial state, the mistakes you introduced, how you detected them, what you fixed and why.
A CV that talks about results: environments managed, migrations led, automation put in place, incidents handled. Our guide to a cybersecurity CV that gets you called walks through the method.

Mistakes to avoid

Collecting certifications without practice. Recruiters quickly spot someone who knows the exam questions but has never deployed an access policy.
Erasing your sysadmin past. It is your main asset. Present it as a foundation, not as something to hide.
Aiming too high too soon. A cloud engineer role with a strong security component, or a platform engineer role, is often a more realistic step than a security architect position.
Neglecting technical English. Provider documentation and most resources are in English (a point worth remembering if you work mostly in French).

Prepare for interviews

Expect a practical exercise: analysing a deliberately misconfigured account, reviewing a piece of infrastructure as code or explaining how you would respond to an access key published by mistake. Recruiters look at your method and priorities more than your memory of service names. To prepare, read our advice on passing a technical cybersecurity interview. Our cloud security engineer job description template, written for employers, also shows what they concretely expect.

Pay varies widely with region, sector, level of responsibility and on-call duties. Compare offers on all of these, and on how much room the role really gives to security.

In short

Moving from system administration to cloud security is a natural progression, as long as you change scale and mindset. Build on what you already master, focus on identities, infrastructure as code and logging with one main provider, and practise in your own lab. Start in your current job if you can, then make your work visible.

Preparing your move into cloud security? Join the Cyber Recrut network for free: our shortlisted candidates prove their skills on hands-on labs, so your sysadmin experience counts for what it is really worth. You can also see how we work.