I wasn’t aiming for another “How I passed SCS‑C02” post. Those are fine—screenshots, study hours, the obligatory trick question—but they rarely explain why the exam starts to make sense. This one is about the mental models that made things click—and the detours I took so you don’t have to.
I took on the AWS Security Specialty (SCS‑C02) with limited hands‑on experience. Yes, certifications don’t prove mastery—I agree. As Gert puts it: a driver’s license doesn’t make you a great driver, and not having one doesn’t mean you can’t drive—but earning it gives you guardrails and a common baseline. Studying for the cert forced me to really learn the fundamentals, and it gave me a running start working with AWS at DPG.
First, a word about the exam
SCS‑C02 has 65 questions in 170 minutes—some multiple choice, some multiple response. A newer version (SCS‑C03) adds emphasis on generative AI and ML security, but the core doesn’t change: understand AWS’s security building blocks and how they interact. Don’t stress about the version; strong fundamentals travel well. Check the official exam guide for details.
My study approach
I used Stephane Maarek’s course on Udemy, plus his practice exams, and I paired those with Tutorials Dojo’s. The rhythm that worked for me was to watch a domain, immediately test myself with matching practice questions, and then go back to any videos where I felt shaky. As I progressed, I kept drifting into AWS documentation, which ended up being a gold mine—especially the pages on IAM policy evaluation, KMS key policies and grants and VPC security. Reading the docs forced me to stop memorizing and start understanding how the pieces fit together.
Here’s what I wish someone told me before I started:
Identity is Everything
Every scenario is secretly an IAM problem. Who can do what? From where? Using which service? If you have to guess, pick “least privilege.” It’s practically AWS’s religion.
Bonus points if you remember: IAM policy evaluation = explicit deny beats everything, SCPs set the ceiling, and resource policies can surprise you.Encryption Isn’t Just KMS
KMS gets the spotlight, but encryption is everywhere: S3 SSE, RDS at rest, EBS volumes and snapshots, CloudFront field-level encryption, TLS everywhere, even secrets in Secrets Manager and Parameter Store. Once you notice the pattern, it’s like the Matrix—keys, everywhere. Know who owns and manages the key, who can use it, and what happens if you rotate or revoke it.Network Security Is a Maze of Trust
PrivateLink, VPC endpoints, NACLs, SGs — it’s not about blocking, it’s about who’s invited to the party.
- VPC = the club.
- NACLs = the bouncers (stateless, grumpy, check both ways)
- Security Groups = the bodyguards (stateful, polite, remember you)
- PrivateLink/VPC endpoints = VIP tunnels so data doesn’t stumble across the public internet
Data doesn't leave unless you let it
S3 Block Public Access, bucket policies with aws:SourceVpce, endpoint policies, CloudFront OAC/OAI, “require TLS”—keep data indoors. If a question says “no public internet,” think PrivateLink, interface endpoints, or S3/DynamoDB gateway endpoints.Logging = Time Travel
CloudTrail, Config, GuardDuty—AWS’s CCTV. If you can describe what each one “sees,” you’ll solve half the exam’s detective work.
- CloudTrail: who did what, when, and from where (API calls)
- Config: what changed, when, and is it compliant
- GuardDuty: suspicious behavior at scale (threat intel + anomalies)
- CloudWatch Logs + Metrics: application heartbeat and alarms
- S3 Access Logs/CloudFront Logs/ALB Logs: who touched your stuff at the edge and at rest
How I Studied (Without Losing It)
I didn’t memorize. I drew. Whiteboards, flow arrows, “what ifs.” I broke scenarios apart until I could explain them like gossip: “So the EC2 tried to talk to the S3 bucket, but the bucket policy ghosted it because it didn’t have the right condition…”
I didn't do any hands-on labs but I would strongly suggest you do. If you’re not under time pressure, spend the extra hours breaking things in a sandbox—wire up IAM, KMS, and VPC endpoints, then pull them apart.
The moment I stopped treating AWS like a set of services and more like a network of trust boundaries, everything clicked.
Conclusion
Since studying for this, I see AWS like a crime scene: who touched what, when, and through which service. Once you start thinking that way, the patterns pop out and the “gotchas” feel less clever and more obvious. That, to me, is the AWS Security Specialty mindset—and it sticks.
Also, a shout‑out to Gert. He didn’t just answer our questions; he happily chased every rabbit hole we opened