Public S3 bucket
The single most common AI-generated CDK mistake: a bucket left open to the world.
Press Run. The stack loaded here fails in a way worth seeing.
▸What the engine finds5 findings
Not examples — Public S3 bucket was run through the real engine when this page was built, and this is what it returned.
Still public. Set `blockPublicAccess: BlockPublicAccess.BLOCK_ALL` and remove `publicReadAccess: true`.INTENT
No encryption at rest. Set `encryption: BucketEncryption.S3_MANAGED` (SSE-S3, no key to manage).INTENT
▸ 3 informational findings — no server access, requests not forced, bucket allows public
No server access logsAwsSolutions-S1Uploads
Without server access logs there is no record of who read what. After an incident that is the difference between knowing what leaked and guessing.
Full rule text
The S3 Bucket has server access logs disabled. The bucket should have server access logging enabled to provide detailed records for the requests that are made to the bucket. AwsSolutions-S1 guide →
Requests not forced onto HTTPSAwsSolutions-S10UploadsPolicy
Requests can arrive over plain HTTP, so object contents and any credentials in the request travel unencrypted across the network.
Full rule text
The S3 Bucket or bucket policy does not require requests to use SSL. You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies. AwsSolutions-S10 guide →
Bucket allows public readsAwsSolutions-S2Uploads
Anyone on the internet can read every object in this bucket. If it holds user uploads, backups, or anything that was ever meant to be private, it is already public.
Full rule text
The S3 Bucket does not have public access restricted and blocked. The bucket should have public access restricted and blocked to prevent unauthorized access. AwsSolutions-S2 guide →
Go deeper
Everything this preset trips, mapped to where it’s actually taught.
This is one failure mode. The course teaches the pattern.
The S3 track walks it checkpoint by checkpoint, graded by the same engine that just ran your code.
Start the S3 track — first checkpoint free →Or start from a stack that fails interestingly
The single most common AI-generated CDK mistake: a bucket left open to the world.
SSH open to the entire internet — the classic copy-paste ingress rule.
Website hosting straight off a bucket — no CDN, no TLS, no access logging.
A database with storage encryption off and backups barely configured.
Action "*" on Resource "*" — the permission grant that ends incident reviews.
A REST API wired to Lambda, wide open, with no access logging.
Fast to write, impossible to restore — no PITR, no encryption choice.
A CDN that will happily serve your site unencrypted, with no logging.
A queue with no server-side encryption and no dead-letter queue.
Network traffic no one can reconstruct after the fact.
Six characters, no symbols, no MFA — defaults nobody revisited.
The one that passes. Encrypted, recoverable, with a dead-letter queue — what good looks like.