Hands-on Lab — SCS-C03 AWS Certified Security Specialty

Overview

Prerequisites

Steps

1. 1.Pick our Terraform version and AWS region

   Standard opener. SCS-C03 is provider- and region-agnostic in scope, but a secure baseline needs to be applied per region — GuardDuty and Access Analyzer are regional services. Most teams pick a primary region (e.g. us-east-1) for the baseline and replicate it via Terraform per region as the account expands.

   Copy

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.60"
       }
     }
   }
   
   provider "aws" {
     region = "us-east-1"
   
     default_tags {
       tags = {
         Project   = "certlabpro-scs-c03"
         ManagedBy = "terraform"
       }
     }
   }
   
   data "aws_caller_identity" "current" {}

2. 2.Create a customer-managed KMS key with rotation for app-data encryption

   Provisions:

   • AWS KMS

   SCS-C03 tests the difference between AWS-managed KMS keys (free, automatic rotation, no key policy you control) and customer-managed keys ($1/month, you own the policy, you control rotation, you get audit visibility into every Encrypt/Decrypt call via CloudTrail). Production should always reach for customer-managed.

   We enable annual rotation (enable_key_rotation = true) and write a key policy that gives the account root the ability to administer the key (the AWS default for any customer-managed key) and explicitly grants the IAM Access Analyzer service permission to evaluate the key's policy. The alias makes the key referable by a human-readable name in downstream code instead of by UUID — SCS-C03 tests this naming convention as a CloudTrail-audit prerequisite.

   Copy

   resource "aws_kms_key" "app_data" {
     description             = "Customer-managed key for application data encryption."
     enable_key_rotation     = true
     deletion_window_in_days = 30
   
     policy = jsonencode({
       Version = "2012-10-17"
       Statement = [
         {
           Sid       = "EnableRootAccountAdmin"
           Effect    = "Allow"
           Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" }
           Action    = "kms:*"
           Resource  = "*"
         },
         {
           Sid       = "AllowAccessAnalyzerToDescribe"
           Effect    = "Allow"
           Principal = { Service = "access-analyzer.amazonaws.com" }
           Action    = ["kms:DescribeKey", "kms:GetKeyPolicy"]
           Resource  = "*"
         },
       ]
     })
   }
   
   resource "aws_kms_alias" "app_data" {
     name          = "alias/certlabpro-scs-c03-app-data"
     target_key_id = aws_kms_key.app_data.id
   }

3. 3.Turn on IAM Access Analyzer to catch unintended public or cross-account access

   Provisions:

   • AWS IAM Access Analyzer

   Access Analyzer continuously evaluates resource-based policies (S3 bucket policies, KMS key policies, IAM role trust policies, Lambda permissions, SQS queue policies, Secrets Manager rotation policies, and more) and surfaces a finding anytime it detects a resource accessible from outside your account or trust boundary. SCS-C03's Threat Detection and Incident Response domain tests this exact pattern — Access Analyzer findings are the canonical signal for "oh, this bucket is now public".

   type = "ACCOUNT" scopes the analyzer to your account; type = "ORGANIZATION" requires AWS Organizations and scopes across the whole org (the SCS-C03 multi-account answer). Either way, it's always-free and zero-config once enabled.

   Copy

   resource "aws_accessanalyzer_analyzer" "main" {
     analyzer_name = "certlabpro-scs-c03"
     type          = "ACCOUNT"
   }

4. 4.Enable GuardDuty so we get told when something is actually attacking us

   Provisions:

   • Amazon GuardDuty

   GuardDuty is AWS's managed threat-detection service. It continuously analyzes CloudTrail, VPC Flow Logs, and DNS logs against AWS's threat-intel feeds — published lists of known-bad IPs, crypto-mining domains, command-and-control infrastructure, and suspicious account behavior patterns. Findings come out tagged with severity (Low / Medium / High) and a machine-parseable type like Recon:EC2/PortProbeUnprotectedPort.

   We turn on the detector with 15-minute publishing frequency (faster than the 6-hour default; SCS-C03 questions about MTTR almost always assume frequent publishing). The IAM-based protection plug-ins (MALWARE_PROTECTION_FOR_EC2, S3_DATA_EVENTS, etc.) cost extra and are out of scope for this baseline; turn them on per workload in production.

   Findings publish to EventBridge automatically — that's how downstream automation (Slack notifications, Security Hub correlation, auto-remediation Lambdas) hooks in. SCS-C03 tests this findings → EventBridge → response chain repeatedly. We don't wire the downstream here, but the moment Step 4 finishes, GuardDuty starts publishing.

   Copy

   resource "aws_guardduty_detector" "main" {
     enable                       = true
     finding_publishing_frequency = "FIFTEEN_MINUTES"
   }

5. 5.Land everything in a centralized audit-log bucket for retention and review

   Provisions:

   • Amazon S3

   Every SCS-C03 Security Logging and Monitoring question expects you to have a centralized, encrypted, write-once-style bucket that other security tools — CloudTrail, VPC Flow Logs, ELB access logs, GuardDuty exports, Config recorders — write into. The bucket is encrypted with the customer-managed KMS key from Step 2, public access is fully blocked, and a bucket policy enforces that any object written must come through the key from Step 2 (no plaintext writes accepted).

   We use the bucket-owner-enforced ownership setting (the ACLs-disabled mode, AWS-recommended since 2023) — this is one of the most-tested S3 hardening attributes on SCS-C03 because it eliminates an entire class of cross-account ACL misconfigurations.

   With the bucket in place, the baseline is complete: KMS for encryption keys, Access Analyzer for unintended exposure, GuardDuty for threat detection, and an audit bucket for everything that needs to be retained for compliance review. Every SCS-C03 multi-service scenario expects you to have these four; the more advanced questions add Security Hub, Config, Inspector, or Macie on top of this base.

   Copy

   resource "aws_s3_bucket" "audit_logs" {
     bucket_prefix = "certlabpro-scs-c03-audit-"
   }
   
   resource "aws_s3_bucket_public_access_block" "audit_logs" {
     bucket = aws_s3_bucket.audit_logs.id
   
     block_public_acls       = true
     block_public_policy     = true
     ignore_public_acls      = true
     restrict_public_buckets = true
   }
   
   resource "aws_s3_bucket_ownership_controls" "audit_logs" {
     bucket = aws_s3_bucket.audit_logs.id
   
     rule {
       object_ownership = "BucketOwnerEnforced"
     }
   }
   
   resource "aws_s3_bucket_server_side_encryption_configuration" "audit_logs" {
     bucket = aws_s3_bucket.audit_logs.id
   
     rule {
       apply_server_side_encryption_by_default {
         sse_algorithm     = "aws:kms"
         kms_master_key_id = aws_kms_key.app_data.arn
       }
       bucket_key_enabled = true # cuts KMS request costs ~99% on bulk writes
     }
   }
   
   resource "aws_s3_bucket_versioning" "audit_logs" {
     bucket = aws_s3_bucket.audit_logs.id
     versioning_configuration {
       status = "Enabled"
     }
   }
   
   resource "aws_s3_bucket_policy" "audit_logs_require_kms" {
     bucket = aws_s3_bucket.audit_logs.id
   
     policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Sid       = "DenyUnencryptedWrites"
         Effect    = "Deny"
         Principal = "*"
         Action    = "s3:PutObject"
         Resource  = "${aws_s3_bucket.audit_logs.arn}/*"
         Condition = {
           StringNotEquals = {
             "s3:x-amz-server-side-encryption" = "aws:kms"
           }
         }
       }]
     })
   }

Cleanup