Career path
Cloud Security
What people in this area work on
Many organizations run their applications on cloud platforms instead of their own hardware. The provider secures its data centers, but customers remain responsible for how they configure their accounts, storage, networks, and permissions.
Misconfigurations, such as storage anyone on the internet can read or permissions far broader than needed, are a common cause of cloud incidents. Cloud security teams review configurations, add guardrails that block risky settings, and make sure activity is logged.
Much cloud infrastructure is defined in code, so the work often involves reading configuration templates and automating checks.
Terms used on this page
- Shared responsibility model
- The split between what the cloud provider secures and what the customer must configure and protect.
- Infrastructure as code
- Describing servers, storage, and networks in configuration files instead of setting them up by hand.
- Template
- An infrastructure-as-code file, such as a Terraform file, that defines cloud resources.
- Least privilege
- Giving people and services only the permissions they actually need.
- Configuration check
- An automated scan that compares settings in a template against security rules, without deploying anything.
How the work flows
One piece of work, start to finish. Every step below is something you can practise in the starter project.
- TemplateRead the infrastructure as code
- ScanCheck it against security rules
- HardenClose exposure and trim permissions
- VerifyRe-run the checks and compare
- GuardrailBlock the same mistake next time
Examples of everyday tasks
- Review infrastructure templates before they are deployed.
- Find publicly exposed storage and overly broad permissions.
- Turn on audit logging and review what it records.
- Write policies that block risky configurations automatically.
- Investigate alerts about unusual activity in cloud accounts.
Related job titles
- Cloud security analyst
- Cloud security engineer
These are career areas to explore, not a checklist. Some of these job titles usually require experience, and completing a starter project does not by itself make someone ready for them.
Starter project
Review and Harden a Cloud Configuration
Review a small infrastructure template for exposed storage, excessive permissions, and missing logging. Correct the issues and rerun configuration checks.
The starter version runs entirely on your own computer against template files. It does not require a cloud account or any paid deployment.
Passing configuration checks shows the template follows the rules the tool checks for. It is not the same as testing a deployed environment.
What you’ll use
- A small infrastructure-as-code template, such as a Terraform file that defines a storage bucket and an access policy
- A free, open-source configuration scanner such as Checkov, run on your own computer
- A text editor
Resources to start with
- Checkov (opens in a new tab)
A free, open-source tool that scans infrastructure-as-code templates for security misconfigurations.
- Terraform tutorials (HashiCorp) (opens in a new tab)
Official tutorials for writing the kind of template this project reviews.
- AWS Shared Responsibility Model (opens in a new tab)
Amazon Web Services’ explanation of what the provider secures and what customers must secure.
More projects for this path
Each one comes with the framework to follow, five name ideas and a walkthrough for publishing it on GitHub.
- Cloud Template Hardening
Scan an infrastructure template, fix what it exposes and automate the check.
- Cloud Logging Baseline
Define what a small cloud account must log, and prove the template delivers it.
- Least-Privilege Policy Lab
Take a wildcard cloud policy and cut it down to only what the app needs.
Project walkthrough
- Write or find a small template that defines a storage bucket, an access policy, and logging settings.
- Read it yourself first and note anything that looks publicly exposed or overly permissive.
- Run a configuration scanner against the template and save the results.
- Group the findings into exposed storage, excessive permissions, and missing logging.
- Correct each issue in a copy of the template and explain why each change helps.
- Rerun the scanner and compare the results with the first run. If you leave a finding unfixed, explain why.
What to publish
- The original and corrected templates
- Configuration check results from before and after your changes
- An explanation of each change
- A note that these are checks of template files, not tests of a deployed environment
Optional extension
Add automated checks that flag the same configuration mistakes.
Example résumé bullet
Numbers are what make a bullet worth reading, so count them while you work: how much data you searched, how many findings you fixed, how many tests you added. Every figure should be one a reader can find in your report. Write the line after the work is done, and leave out impact or experience you cannot show.
Numbers to record while you work
| Count | Where it comes from |
|---|---|
| Resources in the template | the template you reviewed |
| Findings before and after | scanner output from both runs |
| Permissions narrowed | diff of the policy |
| Checks automated | the CI configuration |
Project name | tools, datasets and frameworks | link
BedrockTerraform, Checkov, AWS S3 and IAM, CIS Benchmarks, GitHub ActionsGitHub
Reviewed a 120-line Terraform template with an open-source configuration scanner; fixed 14 of 17 findings covering public storage, broad permissions and missing logging, documented the 3 accepted risks, and added the checks to CI.
Give the project a name of its own: “Bedrock” is an example, not a label to copy. List the tools, datasets and frameworks you actually used, since several relevant ones show more than a single tool does. Hyperlink the last part to your published repository or report.
A day on the job
Try the work before you try the project
A short walkthrough of a realistic situation. Nothing is scored: each choice explains what would happen, so you can talk through the reasoning later.
Storage bucket set to public in the deploy request
A change request would make a storage bucket readable by anyone on the internet. It is due to deploy this afternoon.
First response?
It holds member photos and the author says the site could not load them. What do you propose?
Choose above to continue.
The change is corrected. What stops the next one?
Choose above to continue.
Turn your project into a portfolio piece
A project becomes easier to evaluate when someone can understand what you did, inspect the evidence, and follow your reasoning.
Create a short report, GitHub README, or portfolio page. A clear two-to-four-page report is a useful starting point, not a strict requirement.
Include:
- Goal: What question or problem did you investigate?
- Environment: What tools, practice data, or systems did you use?
- Your work: What did you personally do, and why?
- Evidence: Include useful screenshots, queries, code, or test results.
- Findings: What did you discover? What remains uncertain?
- Fix or recommendation: What should change, and did you test it?
- Sources and limitations: Credit datasets and guides. Clearly identify simulated work.
Use sample or redacted information in the public version.
Publish the report somewhere accessible without requesting permission, and check the link before putting it on a résumé.
Put numbers in it
Count as you work, and put the figures in the report: records searched, findings confirmed, tests added, checks failing before and after. A reviewer can check every one of them against your evidence, which is exactly why they are worth including. Leave out business impact you cannot show.
Name it, then show your tools
A résumé line works best in three parts: your project’s own name, the tools and frameworks you used, and a link to the work. “Role-Based Access Lab” reads like a class exercise. A name plus a tool list tells a reviewer what you can actually work with, and every tool, dataset or framework you list honestly is another thing an interviewer can ask you about.
Project name | tools, datasets and frameworks | link
- Role-Based Access LabTurnstile | Keycloak, RBAC design, NIST SP 800-63, Docker | GitHub
- Login HuntBeacon | Python, pandas, Sigma, MITRE ATT&CK | GitHub
- Cloud ProjectBedrock | Terraform, Checkov, AWS IAM, CIS Benchmarks | GitHub
Why link a report?
Your résumé gives a short description of the project. The linked report lets a reviewer inspect your work and gives you concrete evidence and decisions to discuss during an interview.
Not every recruiter will open it, but it makes your work available for review.
BeaconPython, pandas, Sigma, MITRE ATT&CK, LANL authentication datasetGitHub
Investigated a public authentication-log dataset for repeated failed logins followed by successful access; documented search queries, supporting evidence, and limitations in a reproducible hunt report.
Hyperlink the last part to the published work, so “GitHub” or “Project Report” opens your repository or report. Check the link before you send the résumé.
Preview the write-up template
# Project title > Practice project. Describe the simulated scenario, practice data, or lab used. ## Goal What question or problem did you investigate? ## Environment What tools, practice data, or systems did you use? Link datasets and guides. ## My work What did you personally do, and why? ## Evidence Screenshots, queries, code, or test results. Use sample or redacted information only. ## Findings What did you discover? The numbers behind it (records searched, findings confirmed, tests added). What remains uncertain? ## Fix or recommendation What should change, and did you test it? ## Sources and limitations - Datasets and guides used: - What was simulated: - Limitations: