Inspiration

As cloud engineers, we know that misconfigurations are the leading cause of security breaches in AWS. The AWS JAM challenged us to think like security engineers under pressure — finding and fixing real-world vulnerabilities across encryption, access control, networking, patching, and more. What inspired us most was the breadth of the challenge: no two problems were alike, and every fix required a deep understanding of how AWS services actually work under the hood.

What it does

Our team tackled 14 AWS security and operations challenges across services including RDS, S3, KMS, CloudFront, IAM, EC2, Systems Manager, CodePipeline, SageMaker, Bedrock, and Lambda. Each challenge presented a misconfigured or broken AWS environment that we had to diagnose and fix — from encrypting unprotected databases and data lakes, to patching EC2 fleets at scale, fixing broken CloudFormation templates, protecting CloudFront origins, and using AI prompt engineering to extract financial insights.

How we built it

We divided challenges based on each team member's strengths and worked in parallel across our AWS lab accounts. We used the AWS Console, CloudShell, Systems Manager, CodeCommit, and SageMaker notebooks as our primary tools. For each challenge we followed a structured approach: read the task, assess the broken state, identify the root cause, apply the fix, and validate. Where AWS services had indirect workarounds — like encrypting RDS via snapshot copy, or re-encrypting S3 objects via Batch Operations — we researched and executed the correct multi-step solutions rather than looking for shortcuts.

Challenges we ran into

  • RDS Encryption: AWS does not allow in-place encryption of an existing RDS instance. We had to snapshot, copy with KMS enabled, and restore — a three-step workaround that's easy to get wrong.
  • S3 Batch Operations: Re-encrypting 200 objects required configuring a Batch Operations job correctly with a CSV manifest, the right IAM role, SSE-KMS settings, and Bucket Key — multiple settings that all had to be right simultaneously.
  • EC2 Metadata Route: Windows instances migrated between AWS accounts had stale gateway routes for 169.254.169.254, breaking the metadata service. Diagnosing this required connecting via RDP and inspecting the Windows route table directly.
  • S3 Access Logging: Configuring HIPAA-compliant S3 logging had silent failures — no clear error messages, just failed validations until we debugged ACL ownership settings.
  • CloudFormation Linting: Three separate bugs in a single template — a missing !, a deprecated runtime, and a misspelled function name — all had to be found and fixed before the pipeline passed.

Accomplishments that we're proud of

  • Completed all 14 challenges with zero clues used — maximum points retained on every task.
  • Solved challenges spanning 10+ AWS services without any hints or external help.
  • Used S3 Batch Operations to re-encrypt 200 objects with 0 failures — the scalable, production-grade method rather than the manual console approach.
  • Fixed a Windows EC2 metadata routing bug that required deep knowledge of both AWS networking and Windows route tables.
  • Used Amazon Bedrock and SageMaker to perform real prompt engineering against financial PDFs — extracting revenue figures, reconciling data, and calculating growth rates with high accuracy.

What we learned

  • Explicit Deny always wins in AWS — resource-based policies can override identity-based policies regardless of what the IAM role says. Always check both.
  • Encryption is never just a toggle — RDS, S3, and KMS each have unique encryption workflows with specific constraints and multi-step processes.
  • Scalable operations matter — S3 Batch Operations, SSM Patch Manager, and CloudFormation are designed for scale. Using them correctly is a skill in itself.
  • Prompt engineering is a real engineering discipline — the quality of your prompt directly determines the quality of the AI's output. Specificity beats vagueness every time.
  • CloudFront origin protection requires two layers — network-level (prefix list) and application-level (custom header) together provide defense in depth.

What's next for CLD 55

We want to take the security patterns we practiced here and apply them to a real production hardening project — building an automated compliance checker that scans AWS accounts for unencrypted databases, open security groups, missing access logging, and deprecated runtimes, then auto-remediates using Systems Manager and Lambda. The JAM showed us exactly which misconfigurations are most common — and we now know how to fix every single one of them.

Built With

Share this project:

Updates