SCS-C03 · D6 · 14%

Security Foundations and Governance

Apply repeatable account governance, secure deployment, compliance evidence, policy enforcement, delegated administration, and exception handling.

Provider facts checked 2026-08-03

Objective coverage

Objective 6.1 · high

Centrally deploy and manage AWS accounts

Use organization design, delegated administration, account vending, shared services, and centrally governed security capabilities.

Lesson
d6-lesson
Practice pool
d6-questions
Application
scs-l01, scs-l05
Objective 6.2 · high

Deploy resources consistently and securely

Turn security requirements into versioned infrastructure, preventive controls, drift detection, exception workflows, and automated remediation.

Lesson
d6-lesson
Practice pool
d6-questions
Application
scs-l08
Objective 6.3 · normal

Meet compliance requirements

Map requirements to controls and evidence, evaluate scope and inheritance, preserve auditability, and remediate gaps proportionately.

Lesson
d6-lesson
Practice pool
d6-questions
Application
scs-l01, scs-l08

Decision frame

Governance connects intent to repeatable operation. A policy without an enforceable control, owner, evidence, exception process, and review date is only a statement. A technical control without business scope and authority can block the wrong work or create unmanaged bypasses.

Use the chain requirement → accountable owner → preventive control → detective control → evidence → exception → remediation → retest. Apply it across accounts, identities, networks, data, deployments, and suppliers.

Objective map

ObjectiveRequired judgmentProof
6.1 Centrally deploy and manage AWS accountsDesign organizations, OUs, accounts, delegated services, shared security capabilities, and account lifecycleA new account receives the approved baseline and central visibility automatically
6.2 Deploy resources consistently and securelyConvert requirements into versioned templates, preventive gates, drift detection, remediation, and exceptionsApproved deployment succeeds; prohibited and drifted states are detected or blocked
6.3 Meet compliance requirementsMap obligations to scoped controls, evidence, ownership, inheritance, gaps, and retestAn assessor can trace a requirement to current evidence and an accountable decision

Multi-account governance

Use AWS Organizations to establish ownership and policy boundaries. Organize accounts by control needs and lifecycle, not only by the current org chart. Separate production from non-production and consider dedicated management, security tooling, log archive, network, shared services, and backup responsibilities. Keep workloads out of the management account. Apply service control policies as maximum-permission guardrails; SCPs do not grant access and should be tested for service and recovery dependencies before broad rollout.

AWS Control Tower can establish and govern a landing zone with account enrollment and controls. Account vending should assign ownership, contact data, budgets, identity access, logging, configuration, backup, network connectivity, and decommissioning from the start. Delegated administration lets security teams operate supported organization services without daily use of the management account. The delegated model still needs least privilege, change control, and monitoring.

Centralize organization trails, configuration visibility, findings, threat detection, and security data according to the organization's architecture. Central does not mean one team owns every response. Define what the platform team enforces, what workload teams remediate, escalation times, exception authority, and how service or Region coverage is proven.

Secure and consistent deployment

Infrastructure as code makes review, reproduction, and drift comparison possible, but insecure code can reproduce insecurity reliably. Govern source, review, CI identities, artifact integrity, secrets, plans, approvals, deployment roles, and rollback. Use CloudFormation StackSets for governed multi-account or multi-Region deployment where they fit. Service Catalog can constrain approved products. AWS Config rules and conformance packs evaluate state. CloudFormation Hooks and policy-as-code gates can evaluate proposed changes before or during provisioning. Choose preventive, proactive, detective, and responsive controls based on failure cost and operational maturity.

Avoid permanent administrator pipelines. Separate build, review, and deploy responsibilities. Scope deployment roles to the target environment and approved resource patterns. Protect iam:PassRole, policy creation, organization changes, logging controls, KMS administration, and network control planes. Record the commit, artifact, approver, plan, deployment result, and post-deploy validation.

Drift can be authorized, accidental, or malicious. Detection should produce a comparison to the approved source, resource owner, severity, and remediation path. Automatic remediation is appropriate when the desired state is unambiguous, the action is bounded and idempotent, and rollback is understood. High-impact drift may require containment or human approval.

Compliance and assurance

Start by scoping the obligation: legal entity, accounts, systems, data, Regions, people, suppliers, time period, and control owner. Map requirements to control objectives before mapping to services. The same AWS configuration may support several requirements, but evidence must show that the control operated for the relevant scope and period.

AWS Artifact provides access to supported AWS compliance reports and agreements. AWS Audit Manager can help collect and organize evidence for supported frameworks and custom assessments. AWS Config supplies configuration evidence. CloudTrail records many control-plane actions. Security Hub CSPM provides supported control and finding views. None decides that the customer is compliant. The customer must address shared responsibility, applicability, compensating controls, evidence quality, exceptions, and management acceptance.

Evidence should be attributable, time-bounded, protected, reproducible, and understandable. A screenshot is often weaker than a versioned configuration plus execution record and independent query. Record collection method and limitations. When a control fails, determine affected scope and duration, reduce risk, assign remediation, preserve the exception decision, and retest.

Decision patterns

NeedStrong patternWarning
Restrict prohibited services or actions across accountsTested SCP at the appropriate OUSCP does not grant required permissions
Establish repeatable account baselinesAccount vending plus Control Tower/IaC and ownership metadataEnrollment without lifecycle ownership creates orphaned accounts
Deploy a standard across accountsGoverned StackSet or approved pipelineBroad execution role can become an escalation path
Detect resource driftConfig or source-to-runtime comparison with ownerDetection without remediation and exception flow becomes noise
Collect audit evidenceRequirement-to-control mapping plus Artifact/Audit Manager/log/config evidenceTool output is not a compliance conclusion
Remediate a known unsafe stateBounded automation with idempotency, approval as needed, and rollbackOne generic auto-fix can disrupt critical workloads

Scenario drill

A company is adding 80 AWS accounts across regulated and unregulated products. Teams want autonomy, while security requires centralized logs, approved Regions, encryption, identity federation, and evidence for audits.

  1. Design OUs around control requirements and lifecycle; isolate regulated production where policies differ.
  2. Create account vending that assigns owner, budget, contacts, identity, network, logging, backup, and baseline controls.
  3. Delegate supported security services to appropriate security accounts and protect the log archive.
  4. Apply a small, tested SCP set for non-negotiable boundaries; use service-specific and deployment controls for detailed configuration.
  5. Deploy baselines through versioned automation and detect drift.
  6. Map regulated requirements to controls and evidence, including shared-responsibility and exception decisions.

Common traps

  • Using the management account for workloads or routine administration.
  • Organizing OUs only by reporting structure instead of control requirements.
  • Treating SCPs as permission grants or as a replacement for IAM least privilege.
  • Calling a landing zone complete without account ownership, budgets, backup, and decommissioning.
  • Equating a clean Security Hub or Audit Manager view with legal compliance.
  • Auto-remediating ambiguous or high-impact drift without rollback.
  • Collecting screenshots with no period, source, owner, or reproducible query.

Self-check

  1. Explain the difference between an SCP, IAM policy, Config rule, and deployment gate.
  2. List the controls a new account should receive before a workload is deployed.
  3. Design an exception with owner, expiry, compensating control, and retest.
  4. Trace one compliance requirement to preventive control, detective control, and evidence.
  5. Explain which security responsibilities remain with the customer for a managed AWS service.

Primary references