Day 1 - Shared Responsibility Model and SCS-C03's 6 Domains: The Big Picture for Security Engineers

Half of those starting AWS security certification for the first time think "AWS security = writing IAM policies well." If you go in with that mindset, you'll crumble facing SCS-C03's scenario questions. What this exam measures is not policy syntax, but "at which layer does this threat lie, who is responsible, and what control blocks it?" — a framework of thinking. The two pillars of that framework are the Shared Responsibility Model and the 6 exam domains.

Today we don't dig deep into any single tool. Instead, we draw a map to understand where every service you'll encounter over the next 12 weeks fits. GuardDuty, KMS, IAM, WAF, Macie, Config — once you grasp that each of these names represents "what kind of control at which responsibility boundary," the correct answers and trap answers in scenario questions will naturally diverge.

Shared Responsibility Model: "of the cloud" vs "in the cloud"

AWS's Shared Responsibility Model can be summed in one sentence: AWS is responsible for the security "of the cloud" (infrastructure), and customers are responsible for security "in the cloud" (their data and configurations). It sounds abstract, but the boundary line is surprisingly sharp.

The key insight is that this boundary moves depending on service type.

• IaaS (EC2): Customer responsibility is largest. Guest OS patching, middleware, firewalls — all customer's responsibility.
• PaaS (RDS, Lambda): AWS owns OS·runtime patching; customer owns data, access control, and encryption configuration.
• SaaS (S3, DynamoDB): AWS owns almost all infrastructure; customer owns only data classification and access control. Yet data responsibility never passes to AWS.

💡 Related Theory: This is called the "shifting line of responsibility." The same "patching" means EC2 OS patching is customer responsibility, but Fargate OS patching is AWS responsibility. In exam questions asking "whose responsibility," almost always the first step is to determine whether the service is IaaS/PaaS/SaaS. A trap answer like "patch the Lambda function's OS" — Lambda runtime OS is patched by AWS.

⚠️ Trap: In S3 data breach cases, "AWS is responsible" is always wrong. S3 durability and availability are AWS responsibility, but setting the bucket to public (access control) is 100% customer responsibility. The Capital One incident (2019) wasn't S3 itself being breached — it was customer-side IAM and WAF misconfiguration.

Three Types of Controls: Preventive, Detective, Responsive

Security engineers must develop the habit of classifying all controls into three categories. SCS-C03's domain structure itself follows this classification.

🔍 Deep Dive: Mature security architecture stacks these three types in layers (defense in depth). When prevention fails, detection catches it; when detection is slow, response mitigates damage. In exam scenarios asking "the best way to prevent this threat," answers combining "preventive + detective + auto-response" are often correct rather than single controls. However, when asking "first/immediate," preventive controls (SCP, key policies) are usually the answer.

SCS-C03's 6 Domains Being Measured

The updated SCS-C03 (2024) has 65 questions, 170 minutes, and 750/1000 passing score. The exam blueprint specifies 6 domains and weightings.

Looking at weights, Domain 3 (infrastructure 20%) + Domain 2 (logging 18%) + Domain 5 (data 18%) make up more than half the exam. But Domain 4 (IAM 16%) is the prerequisite for all other domains. KMS key policies operate on top of IAM evaluation logic, and cross-account logging works on top of AssumeRole. That's why Week 1 is entirely dedicated to IAM.

💡 Related Theory: The domains aren't 6 separate subjects to memorize — they're one flow of thinking. A threat arrives (D1 detect) → to see it, logs must exist (D2) → the entry point is the network (D3) → authorization inside is IAM (D4) → the protected asset is data (D5) → enforce all of this at organizational level (D6). Scenario questions usually bundle 2-3 domains together.

Data Classification and Least Privilege: Two Starting Points of Security Incidents

In real operations, when you trace root causes of security incidents, they almost always come down to two things. One is data that was never classified — not knowing what or how much needs protection. The other is excessive permissions.

Data classification is the starting point of protective controls. Where are PII, payment information, health data? That's why Amazon Macie automatically classifies sensitive S3 data using ML. Without classification, you can't answer "does this bucket need KMS encryption?"

Least privilege is the heart of Domain 4 but permeates all domains. Least privilege in KMS key policies, S3 bucket policies, SCP. "Grant permissions explicitly, revoke by default" is the philosophy of IAM evaluation logic (we'll explore this deeply on Day 2).

📚 Case Study: In 2017, multiple companies storing PII in public-read S3 buckets led to large breaches (Verizon, Accenture, etc.). AWS introduced S3 Block Public Access in 2018 to stop this pattern, and since 2023 it's enabled by default on new buckets. This exemplifies "enforcement of preventive controls as platform defaults" in governance (Domain 6).

Multi-Account and Governance: Blast Radius of Security

Why security engineers must move beyond single-account thinking is blast radius. If one account is compromised, you want it not to spread to other environments — accounts themselves become a boundary.

Standard multi-account security structure looks like this:

[ AWS Organizations Security Foundation ]

  Management Account (billing + SCP management, workload forbidden)
        |
   +----+----+----------------+--------------+
   |         |                |              |
 Security OU  Infrastructure  Workloads OU   Sandbox OU
   |              OU            (Prod/NonProd)
   +-- Log Archive Account (CloudTrail/Config logs immutable storage)
   +-- Audit/Security Tooling Account (GuardDuty·SecurityHub delegated administrator)

• Log Archive Account: Centralize CloudTrail·Config logs from all accounts; S3 Object Lock prevents tampering. Almost no one logs in here.
• Security Tooling Account: Delegated administrator for GuardDuty·Security Hub·Detective. See all organization security signals in one place.
• SCP: Doesn't grant permissions but draws upper guardrails with deny. Applies even to root (except management account root).

🔍 Deep Dive: GuardDuty, Security Hub, Macie, Config all support "delegated administrator" pattern. Don't operate directly from the management account — delegate to Security Tooling Account. This is best practice for least privilege — management account only does billing and org management; adding security operations authority there means when that account is compromised, the entire organization falls.

Mapping Controls to Domain and Type

Practice classifying key services by the two axes you learned today (control type × responsibility boundary). When you have this table in mind, you can quickly filter trap answers in scenario questions.

🎯 Scenario: "PII in S3 bucket found stored without encryption. What control combination prevents recurrence?" Not a single answer. Detective (Macie finds sensitive data + Config rule s3-bucket-server-side-encryption-enabled) + Preventive (SCP blocks unencrypted PutObject, S3 Block Public Access) + Responsive (EventBridge → Lambda auto-encrypt/quarantine). Thinking of all three types at once is how SCS-C03 thinks.

Summary — The Map Ahead

Remember three pictures we drew today. First, the Shared Responsibility Model has a moving boundary depending on service type (IaaS/PaaS/SaaS), but data and access control are always customer responsibility. Second, all controls fall into three types — preventive, detective, responsive — and mature architecture stacks them in layers. Third, the 6 domains aren't separate subjects to memorize but flow from threat → visibility → network → identity → data → governance — one chain of thinking.

Starting tomorrow, we enter IAM, the spine of that chain. Once you understand what users, groups, roles, and policies are, and exactly how AWS's evaluation logic decides whether to allow or deny a request, you'll start seeing how every other domain rests on top of that foundation.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

A company is using Amazon RDS for PostgreSQL. Under the shared responsibility model, which of the following is **AWS's responsibility**?

• AClassifying the PII stored in the database and deciding whether to enable encryption
• BConfiguring database user accounts and IAM authentication policies
• CApplying security patches to the database engine
• DRestricting access to the DB port with a security group

Question 2

Which of the following is **not** a preventive control?

• AUsing an SCP to deny EC2 launches outside a specific Region
• BUsing a KMS key policy to allow decryption only from specific accounts
• CUsing GuardDuty to detect anomalous API call patterns
• DUsing a security group to allow inbound traffic on 443 only

Question 3

Which combination correctly pairs the highest-weighted SCS-C03 domain with the topics it covers?

• AIdentity and Access Management — KMS key rotation policies
• BInfrastructure Security — network perimeter defense such as VPC, security groups, and WAF
• CData Protection — organizational governance with Organizations SCPs
• DThreat Detection and Incident Response — CloudTrail log retention policies

Question 4

When operating GuardDuty and Security Hub in a multi-account environment, which is the most appropriate AWS best practice?

• AOperate GuardDuty and Security Hub directly from the management account
• BHave each workload account enable and manage GuardDuty independently
• CDesignate a separate Security Tooling account as the delegated administrator and aggregate across the whole organization
• DOperate GuardDuty from the Log Archive account so that logs and detection live in one place

Question 5

PII in an S3 bucket was leaked externally. The investigation found that the bucket had been set to public-read. From the perspective of the shared responsibility model, which judgment is most accurate?

• AThe S3 infrastructure was breached, so this is AWS's responsibility
• BBucket access control settings are the customer's responsibility, so this is a customer misconfiguration
• CThis is a data durability problem, so AWS and the customer share responsibility equally
• DS3 is SaaS, so all data protection responsibility lies with AWS