How to Build a Cloud Security Portfolio Project
A cloud security portfolio project does not mean building a penetration testing tool or demonstrating attack techniques. It means building infrastructure that demonstrates you understand how to design, harden, and assess cloud environments with security as a first concern. This is highly valuable for cloud security engineer roles — and increasingly expected at senior cloud engineering and architect levels too.
What a security project signals to hiring managers
Most cloud engineers build things that work. Fewer build things that are secured by design. A security-focused portfolio project signals:
- You treat IAM, network controls, and secrets management as first-class concerns — not afterthoughts
- You understand the difference between something that is deployed and something that is defensible
- You can think adversarially — about what an attacker would try and how the architecture resists it
This is useful for any cloud engineering role, not just cloud security specialist positions. A cloud engineer who asks “how would someone abuse this?” is more valuable than one who only asks “does this work?”
Option 1: Security hardening and baseline implementation
What to build
Start with a deliberately misconfigured cloud environment (or use one of your existing projects in its default state) and systematically harden it. Document the before state and each hardening step. This is a realistic simulation of the security work done when a company first adopts cloud or inherits a poorly configured environment.
What to harden
IAM:
- Replace all wildcard IAM permissions with specific actions on specific resources
- Enable MFA enforcement for all IAM users (if using IAM users — ideally migrate to SSO)
- Remove unused IAM roles and policies
- Use IAM Access Analyzer (AWS) or Policy Analyzer (GCP) to identify resource policies with external access
Network:
- Remove any 0.0.0.0/0 inbound rules that are not required for web traffic (port 80/443)
- Ensure databases are in private subnets with no public IP
- Enable VPC Flow Logs for traffic analysis
- Restrict outbound traffic to known destinations where possible
Storage:
- Enable S3 Block Public Access at the account level
- Enable versioning and object lock on buckets containing important data
- Audit bucket policies for unexpected external access
- Enable encryption at rest for all storage resources
Logging and detection:
- Enable CloudTrail or GCP Audit Logs across all regions and services
- Set up a log sink or CloudWatch Logs group with retention defined
- Create at least two detection rules for high-risk events (console login from new location, root account usage, security group modification)
What to document
For each hardening step, document: what the risk was before, what you changed, and what the risk is after (including any residual risk). This “risk register” approach shows security thinking, not just configuration changes.
Option 2: Secrets management implementation
What to build
Take an existing application project and fully refactor it to use proper secrets management. The before state: credentials in environment variables, connection strings in config files, API keys in code. The after state: all secrets in a managed store, applications authenticate via IAM identity rather than static credentials, rotation is configured for database passwords.
The specific changes
For AWS:
- Store all secrets in AWS Secrets Manager
- Lambda functions and EC2 instances retrieve secrets at runtime using their IAM role — no static credentials
- Enable automatic rotation for database credentials using Secrets Manager + Lambda rotator
- Use SSM Parameter Store for non-sensitive configuration (feature flags, endpoints) and Secrets Manager for sensitive values
For GCP:
- Store all secrets in GCP Secret Manager
- Cloud Functions and Compute Engine instances retrieve secrets using their attached service account
- Enable secret versioning and document the rotation process
What to document
Explain the difference between SSM Parameter Store and Secrets Manager (AWS) — cost, rotation support, and use cases. Explain the IAM chain: how does the application authenticate to the secret store without a credential? This question — “who authenticates the authenticator?” — is the core of IAM identity design and comes up in interviews.
Option 3: Cloud security posture assessment with automated remediation
What to build
Enable AWS Security Hub or GCP Security Command Center on a cloud account, document the initial findings, remediate the high and critical findings using Terraform, and implement automated remediation for one finding type (for example: automatically disable public access on S3 buckets when Security Hub detects it).
The automated remediation pattern
The remediation pattern for AWS:
- Security Hub generates a finding for a public S3 bucket
- Security Hub sends the finding to EventBridge
- An EventBridge rule matches the finding type and triggers a Lambda function
- The Lambda function calls the S3 API to enable block public access on the offending bucket
- The Lambda function sends a notification to an SNS topic (for audit purposes)
Automated remediation is a real-world pattern used in cloud security operations. Demonstrating it — even for one finding type — shows architectural thinking about detection and response, not just prevention.
What to document
Explain which findings you chose to auto-remediate and why. Explain the risk of auto-remediation: what if the Lambda incorrectly identifies a bucket that should be public? How would you detect that? Explaining the risk of your automated system is as important as explaining how it works.
What not to build
A cloud security portfolio project should not be:
- A vulnerability scanner or exploit tool — these require careful ethical and legal consideration and are not appropriate for a general portfolio
- A project that involves scanning or testing infrastructure you do not own
- A deliberately vulnerable environment with no explanation of how you would fix it — the fixes are the portfolio, not the vulnerabilities
Security projects should demonstrate defensive thinking and hardening, not offensive tooling. If you are interested in security research or penetration testing as a career, that is a separate path with its own certifications and portfolio norms.
Connecting to certifications
Security portfolio projects complement the AWS Certified Security — Specialty, GCP Professional Cloud Security Engineer, and CompTIA Security+ certifications well. Building a real hardening or posture project while studying for one of these exams reinforces the theory with practical experience and gives you a concrete project to discuss in the exam period.
For the security certification landscape, see the best cloud certifications guide.
Summary
- A cloud security project demonstrates defensive thinking — IAM hardening, secrets management, posture assessment — not offensive tooling
- The hardening project is the most approachable: start with a misconfigured environment and document every fix with the before and after risk
- The secrets management project is high-value because it touches a ubiquitous real-world problem: how to handle credentials properly
- Automated remediation (Security Hub finding → EventBridge → Lambda → fix) is an impressive pattern that few junior portfolios include
- Document the risk of your security controls as well as their benefits — explaining what your system cannot detect is a sign of mature thinking
- Never scan or test infrastructure you do not own