Cyber, Risk & Internal Audit
Cloud & Infrastructure Security Engineer
Where most real breaches now happen. An engineering role whose core skill is understanding permissions deeply enough to see the escalation path.
Cloud security is the archetype closest to the actual attack surface of a modern company. The breaches that matter are rarely exotic: an over-permissioned role, a publicly-reachable service that should not have been, a credential with a scope nobody audited.
| Time | What you are actually doing |
|---|---|
| 09:00 | Triage cloud posture findings. Most are noise; the one that matters is a role with a wildcard permission that can be assumed from a service reachable from the internet. |
| 10:30 | Threat-model a new workload with a platform team. Where does it get credentials, what can it reach, and what happens if it is compromised. |
| 13:00 | Write policy. A service control policy or an admission rule that makes a whole class of misconfiguration impossible rather than detected. |
| 14:30 | Investigate. Someone's access key appeared in a public repository nine minutes ago. Rotate, then work out what it could have reached and whether it was used. |
| 16:00 | Reduce blast radius. Working through a role with 200 permissions to find the 12 it actually uses, from access-analyser data rather than from asking. |
The decisive round
“An EC2 instance is compromised. What can the attacker reach?”
Interviewer: “Attacker has code execution on an instance in our production VPC. Walk me through what happens next.”
A weak answer. “They'd have access to whatever is on that instance, and could try to move laterally to other systems in the VPC. We'd want to isolate it and investigate.” Describes containment without describing the attack. It misses the mechanism that makes cloud compromise different from server compromise.
A strong answer. “The first thing they take is not on the instance. It is the instance metadata service — a request to a link-local address returns temporary credentials for whatever role is attached. That is the pivot that makes cloud different: code execution on a host converts directly into an identity in the control plane.
So my first question is what that role can do. If it is scoped to one bucket prefix, this is a contained incident. If it has a wildcard, or can assume other roles, or can call IAM, then the blast radius is the account and possibly the organisation.
From there the escalation paths I would check: can the role pass a more privileged role to a new resource, can it modify its own policy, can it create access keys for a user, can it read secrets, and can it invoke a Lambda that runs with a different role. Those are the usual chains and they are all ordinary API calls rather than exploits.
Containment: revoke the role's sessions rather than only stopping the instance, because credentials issued before termination remain valid until expiry — and that is the mistake most teams make.
The prevention I would be arguing for afterwards: enforce IMDSv2 so a server-side request forgery cannot reach metadata, scope roles from access-analyser data rather than by guessing, and use service control policies so an entire class of escalation is not expressible regardless of what a role's policy says. Capital One in 2019 was exactly this chain — SSRF to metadata to an over-permissioned role to an S3 bucket.”
Naming the metadata service unprompted is the fork in this question. So is knowing that stopping the instance does not revoke issued credentials, which is a detail only people who have run an incident tend to have.
- Build the escalation chain yourself in a free-tier account: SSRF to metadata to a role to a bucket. Doing it once makes it permanent knowledge.
- Learn to read IAM policies fluently — conditions, resource wildcards, trust policies and
iam:PassRole, which is the most under-appreciated escalation primitive in AWS. - Write a preventive control: an SCP or admission policy that blocks a class of problem, then demonstrate it refusing.
- Have a right-sizing story — a role reduced from a wildcard to what it actually used, based on data.
A misconfigured web application firewall allowed server-side request forgery to the instance metadata service; the credentials retrieved belonged to a role with excessive S3 permissions, and around 100 million records were taken.
Use it to say: “It is the canonical chain, and every link is a control I can name: IMDSv2, least-privilege role scoping, and egress restriction.”
A modified CI script exfiltrated environment variables — including cloud credentials — from thousands of build pipelines.
Use it to say: “This is why I treat CI runners as production identity. Whatever the runner can read, an attacker who reaches the runner can read.”
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $150k – $260k base | One of the strongest security markets |
| India | ₹20L – ₹55L total | Large GCC demand, especially BFSI and healthcare |
The book for this field
Security Engineering & Tooling
What each category of security tool structurally cannot see, what the evidence actually supports, how the market consolidated, and what the 5,197 postings say the job is.
Also read for this role
Networks, Automation, Connectivity & Data Centres
Twelve chapters from a single packet to a submarine cable. Subnetting worked by hand, BGP and why hijacks succeed, DNS and the two outages worth knowing by name, TLS and the expiry that still takes down companies, cloud networking with the arithmetic, transit and peering, colocation and what an AI rack did to the industry, and four debugging scenarios worked end to end.
All 18 chapters in Networks, Automation, Connectivity & Data Centres →
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 12 Security questions → · Back to Cyber, Risk & Internal Audit →