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.