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

💡 Related theory: This is called the "shifting line of responsibility." Even for the same "patching," OS patching on EC2 is the customer's responsibility, while OS patching on Fargate is AWS's responsibility. Questions on the exam that ask "whose responsibility is it" can almost always be solved by first determining whether the service is IaaS, PaaS, or SaaS. An answer choice like "patch the OS of the Lambda function" is a trap — the Lambda runtime OS is patched by AWS.

⚠️ Pitfall: In an S3 data breach incident, the answer choice "AWS is responsible" is always wrong. S3's durability and availability are AWS's responsibility, but the configuration that left the bucket open to the public (access control) is 100% the customer's responsibility. In the Capital One incident (2019), S3 itself was not breached — it was a customer-side IAM/WAF misconfiguration.

The 3 Types of Controls: Preventive, Detective, Responsive

A security engineer should build the habit of classifying every control into three categories. The domain structure of SCS-C03 itself follows this classification.

🔍 Going deeper: A mature security architecture stacks the three types in layers (defense in depth). If prevention is breached, detection catches it; if detection is slow, response limits the damage. When the exam asks for "the best way to stop this threat," the answer choice that combines "prevention + detection + automated response" is often correct rather than one that picks a single control. However, when the question asks what to do "first/immediately," the answer is usually a preventive control (SCP, key policy).

The 6 Domains SCS-C03 Measures

The 2024 revision of SCS-C03 has 65 questions, 170 minutes, and a passing score of 750/1000. The exam guide specifies six domains and their weightings.

Looking at the weightings, 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 the other domains. KMS key policies operate on top of IAM evaluation logic, and cross-account logging operates on top of AssumeRole. That is why Week 1 is dedicated entirely to IAM.

💡 Related theory: The domains are not six subjects to memorize separately but a single train of thought. A threat comes in (D1 detection) → for it to be visible you need logs (D2) → the entry path is the network (D3) → inside, permissions are IAM (D4) → what you protect is data (D5) → and all of this is enforced at the organizational level (D6). Scenario questions usually bundle two or three domains together.

Data Classification and Least Privilege: The Two Root Causes of Security Incidents

When you trace the root causes of security incidents in practice, they almost always come down to two things. One is failing to classify data, so no one knew what needed to be protected and how much; the other is excessive permissions.

Data classification is the starting point of protective controls. Where are the PII, payment data, and health data? This is why Amazon Macie automatically classifies sensitive data in S3 using ML. Without classification, you cannot answer the question "does this bucket need KMS encryption?"

Least privilege is the heart of Domain 4, but it permeates every domain. Least privilege in KMS key policies, least privilege in S3 bucket policies, least privilege in SCPs. "Grant explicitly; revoke by default" is the philosophy of the IAM evaluation logic (we cover this in depth on Day 2).

📚 Case study: In 2017, numerous companies stored PII in S3 buckets left open with public-read, leading to a string of major breaches (Verizon, Accenture, and others). To stop this pattern, AWS introduced S3 Block Public Access in 2018, and since 2023 it has been enabled by default on new buckets. This is a textbook example of governance (Domain 6): "enforcing a preventive control as a platform default."

Multi-Account and Governance: Security's Blast Radius

The reason a security engineer must move beyond single-account thinking is the blast radius. To keep a compromise in one account from spreading to other environments, you use accounts as boundaries.

The standard multi-account security structure looks like this.

[ AWS Organizations security baseline structure ]

  Management account (billing + SCP administration, no workloads)
        |
   +----+----+----------------+--------------+
   |         |                |              |
 Security OU  Infrastructure  Workloads OU   Sandbox OU
   |              OU            (Prod/NonProd)
   +-- Log Archive account (immutable storage of CloudTrail/Config logs)
   +-- Audit/Security Tooling account (delegated administrator for GuardDuty/SecurityHub)

• Log Archive account: Centralizes CloudTrail and Config logs from all accounts, with S3 Object Lock for tamper protection. Humans almost never log in.
• Security Tooling account: The delegated administrator for GuardDuty, Security Hub, and Detective. All the organization's security signals are viewed in one place.
• SCPs: They do not grant permissions but draw an upper bound (guardrail) with deny. They apply even to root (with the exception of the management account root).

🔍 Going deeper: GuardDuty, Security Hub, Macie, and Config all support the "delegated administrator" pattern. The best practice is not to operate them directly from the management account but to delegate to the Security Tooling account. The reason is least privilege — the management account should handle only billing and organization management; if you also pile security operations permissions into it, the entire organization collapses when that account is compromised.

Practice: Mapping Controls to Domains and Types

Let's classify the major services along the two axes we learned today (control type × responsibility boundary). With this table in your head, you can quickly filter the answer choices in scenario questions.

🎯 Scenario: "We found out after the fact that PII was stored unencrypted in an S3 bucket. What combination of controls prevents recurrence?" There is no single answer. Detection (discover sensitive data with Macie + Config rule s3-bucket-server-side-encryption-enabled) + prevention (block unencrypted PutObject with an SCP, S3 Block Public Access) + response (EventBridge → Lambda for automatic encryption/quarantine). Thinking of all three types at once is the SCS-C03 way of thinking.

Wrapping Up — The Map Ahead

Engrave the three pictures we drew today. First, in the Shared Responsibility Model, the line of responsibility moves with the service type (IaaS/PaaS/SaaS), and data and access control are the customer's responsibility in every case. Second, every control is classified into the three types — preventive, detective, responsive — and a mature architecture stacks all three in layers. Third, the six domains are not subjects to memorize separately but a single chain of thought flowing from threat → visibility → network → identity → data → governance.

Starting tomorrow, we go into IAM, the spine of that chain. Once you dig into what users, groups, roles, and policies are, and exactly how the evaluation logic that decides whether AWS allows or denies a request works, you will start to see that every other domain is built on top of that structure.