Amazon SCS-C02: Governance, Config & Automation — Study Guide
Part of the AWS Security Specialty SCS-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Service Control Policies and Organization-Level Guardrails
Service Control Policies form the outermost boundary of what any principal in an AWS Organization can do. An SCP is not an IAM policy — it grants nothing, it only defines the maximum permissions available to accounts under an OU or the entire organization. An Allow in an IAM policy, resource policy, or permissions boundary is completely inert if an SCP denies the action. This asymmetry is exactly why SCPs are the correct tool for organization-wide guardrails: Region restrictions, banned services, protection of centrally-managed IAM roles, and encryption enforcement at resource creation.
A canonical SCP denying creation of unencrypted DynamoDB tables and S3 buckets looks like this:
Version: "2012-10-17"
Statement:
- Sid: DenyUnencryptedS3
Effect: Deny
Action: s3:CreateBucket
Resource: "*"
Condition:
StringNotEquals:
s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
- Sid: DenyUnencryptedDdb
Effect: Deny
Action: dynamodb:CreateTable
Resource: "*"
Condition:
"Null":
dynamodb:SSESpecificationEnabled: "true"
A common trap is trying to enforce “no one in the org can use us-east-2” or “no one can disable CloudTrail” through IAM policies attached in each account. Even with a permissions boundary and identity policy alignment, a local administrator can grant themselves an escape hatch. Only an SCP applied at the root or OU can be relied upon, because it constrains even the root user of member accounts (with the narrow exception of a handful of un-restrictable actions).
SCPs should also protect break-glass and delegated administration roles: add an explicit Deny on any action targeting a role such as OrganizationAccountAccessRole or SecurityAudit unless the caller’s aws:PrincipalArn matches an approved list.
AWS Config, Conformance Packs, and Multi-Account Enforcement
AWS Config provides the continuous evaluation layer that complements SCPs (which prevent) with detection (which observes and reports drift). A conformance pack is a bundle of Config rules — both managed rules like s3-bucket-server-side-encryption-enabled and custom rules backed by Lambda or Guard — packaged as a single deployable YAML artifact with optional remediation actions.
To roll a standard baseline out organization-wide, two mechanisms combine:
CloudFormation StackSets from the management account with service-managed permissions and
AutoDeployment: Enabledso that any new account joining the organization automatically receives a stack that turns on the Config recorder and delivery channel. This solves the bootstrap problem: a conformance pack cannot evaluate an account where Config is not enabled.Conformance packs deployed from the delegated administrator account (for example
security-01) usingPutOrganizationConformancePack. This propagates a consistent rule set to every current and future account without needing to touch each account manually.
The delegated-administrator + aggregator pattern is important: it lets the security team see compliance for all accounts in one place while still allowing application teams to add their own rules locally. Deploying the same rules directly from the management account would work but violates least privilege and blocks separation-of-duties audits.
CloudFormation Guard, StackSets, and Service Catalog
Prevention should shift left. CloudFormation Guard (cfn-guard) is a policy-as-code engine that parses CloudFormation templates (or any JSON/YAML) and evaluates them against declarative rules before deployment. A Guard rule looks like:
rule s3_encrypted {
Resources.*[ Type == "AWS::S3::Bucket" ] {
Properties.BucketEncryption exists
Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
}
}
}
Wiring this into a CI/CD stage — typically as a Docker container step that runs cfn-guard validate -r rules.guard -d template.yaml — fails the pipeline before any noncompliant resource is created. On violation the pipeline publishes to an SNS topic that the security team subscribes to, giving them visibility without becoming a manual approval bottleneck. Relying on StackSets or CloudFormation change-set review alone to notify the security team is a trap: neither service emits per-resource compliance findings, and by the time a stack has been created the resource already exists in the account.
Service Catalog complements Guard for the last mile. Instead of letting developers write arbitrary CloudFormation, the platform team publishes vetted products (VPC baselines, RDS patterns, EKS clusters) as Service Catalog portfolios shared across accounts via AWS RAM. Developers launch them with constrained parameters, and a launch constraint IAM role provisions resources with elevated permissions the developer does not personally hold. This gives an auditable, self-service deployment model where the underlying template has already passed Guard checks.
StackSets themselves need correct plumbing: use SERVICE_MANAGED permission model when deploying from the org management account, enable trusted access for CloudFormation in Organizations, and configure execution roles carefully. The AdministrationRoleARN/ExecutionRoleName pair (in self-managed mode) or the service-linked roles (in service-managed mode) must have iam:PassRole permitted to the CloudFormation service role that actually creates resources. Forgetting to attach a CloudFormation service role and instead relying on the deploying user’s credentials leads to intermittent AccessDenied errors on iam:PassRole — a common cause of failed StackSet operations. The correct pattern is one dedicated service role per stack with only the permissions needed to create the declared resource types.
Automated Remediation Pipelines
When Config detects noncompliance, remediation must be automatic for anything that can be safely self-healed. The event flow is:
Config publishes a
Compliance Changeevent to the default event bus.An EventBridge rule filters for
NON_COMPLIANTfindings on specific rules and targets either a Systems Manager Automation document (for simple, idempotent fixes like enabling S3 encryption), a Lambda function (for API-level fixes), or a Step Functions state machine (for multi-step workflows requiring approvals, retries, or cross-service orchestration).
For example, if s3-bucket-public-read-prohibited fires, an SSM Automation runbook AWS-DisableS3BucketPublicReadWrite remediates it. For more complex flows — say, a KMS key policy that drifts and must be reconciled while notifying the owning team — Step Functions coordinates: read the current policy, diff against the golden version, call kms:PutKeyPolicy, then post to SNS. Storing the remediation logic in Step Functions rather than a single Lambda gives observability into each step and clean retry semantics.
IAM Access Analyzer and Policy Validation
IAM Access Analyzer answers two distinct questions. First, external access analyzers identify resources (S3, KMS, IAM roles, Lambda, SQS, Secrets Manager) whose policies grant access to principals outside a defined zone of trust — either the account or the organization. Enable the analyzer at the organization level from the delegated administrator account so findings aggregate centrally.
Second, Access Analyzer policy validation and policy generation run during authoring. aws accessanalyzer validate-policy returns security warnings, errors, and suggestions (for example, flagging overly broad Resource: "*" combined with sensitive actions). Integrate this into the same CI/CD stage as cfn-guard so IAM policies embedded in CloudFormation are checked before deployment. Access Analyzer can also generate a least-privilege policy from CloudTrail history, replacing a wildcard policy with the exact actions a role has actually used — the mechanical answer to “enforce least privilege for data access” alongside a scoped KMS key policy that only permits kms:Decrypt when the calling service is S3, DynamoDB, Lambda, or EKS via kms:ViaService conditions.
Practical Problem: Use-Case Scenario
Scenario: Meridian Financial runs a multi-account AWS Organization that includes production, staging, sandbox, and a centralized security account. They deploy workloads with a mix of CloudFormation templates and developer-driven templates in the sandbox; ownership is federated across teams, and they must meet internal governance for data encryption and least-privilege access.
Challenge: Developers in the sandbox have accidentally created public S3 buckets and overly permissive IAM policies that propagated to other accounts, and the security team lacks consistent, automated enforcement and template validation across the Organization.
Recommended Approach:
- Create Organization-level Service Control Policies (SCPs) to deny public S3, enforce bucket encryption, and restrict privileged IAM actions at the Organization root to provide preventive guardrails.
- From the central security account, deploy an AWS Config aggregator and Conformance Packs using CloudFormation StackSets to every account and region to continuously evaluate S3 public access, IAM policy attachment patterns, and encryption compliance.
- Integrate CloudFormation Guard (cfn-guard) rules into the CI/CD pipeline (CodePipeline/CodeBuild) and require Service Catalog products for approved infrastructure so templates are validated and only compliant stacks can be provisioned.
- Enable AWS Config automated remediation with SSM Automation documents or Lambda runbooks for high-priority findings (auto-block public S3, remediate overly broad IAM policies) and trigger additional workflows via EventBridge.
- Run IAM Access Analyzer and policy validation centrally, ingest findings into Security Hub, and automate ticket creation or remediation playbooks for discovered cross-account or overly permissive policies.
Rationale: This combines preventive org-wide guardrails (SCPs), continuous detection (Config/Conformance Packs), shift-left template validation (cfn-guard/Service Catalog), and automated remediation with IAM Access Analyzer to enforce least privilege and achieve consistent multi-account governance per AWS best practices.
AWS Config: Organization Rules, Aggregators, and Delegated Administration
AWS Config is the foundation of detective compliance on AWS. It continuously records resource configurations and evaluates them against rules — either AWS-managed (for example, restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) or custom (backed by Lambda or Guard). At enterprise scale, three architectural decisions matter more than the rules themselves: how rules are deployed, how findings are aggregated, and who owns the tooling.
For multi-account, multi-Region deployments under AWS Organizations, the correct pattern is to designate a delegated administrator account (typically the security or audit account, not the management account) via aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com. From that account, use PutOrganizationConfigRule or PutOrganizationConformancePack to fan rules out to every member account and Region. Skipping delegated administration forces you to enable Config manually in each account or run everything from the management account — the latter violates separation of duties and the former does not scale beyond a handful of accounts.
Organization rules push a single rule definition; aggregators collect the resulting evaluations. Create an aggregator in the delegated admin account with an OrganizationAggregationSource covering all accounts and Regions. The aggregator dashboard then answers questions like “which VPCs across 200 accounts lack Flow Logs?” without cross-account role juggling. Note that aggregators are read-only: they surface compliance state but do not themselves remediate.
Conformance Packs for Baseline Enforcement
A conformance pack bundles Config rules and their remediation actions into a single YAML template. AWS ships packs mapped to frameworks like PCI DSS, HIPAA, NIST 800-53, and CIS. Deploying an organization conformance pack from the delegated admin targets specific OUs — for example, applying a stricter pack to the Prod OU than to Sandbox. This is the most efficient way to enforce a consistent baseline across hundreds of accounts because a single API call propagates the ruleset and its remediation wiring everywhere at once.
Resources:
EncryptedVolumesRule:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: encrypted-volumes
Source:
Owner: AWS
SourceIdentifier: ENCRYPTED_VOLUMES
EncryptedVolumesRemediation:
Type: AWS::Config::RemediationConfiguration
Properties:
ConfigRuleName: encrypted-volumes
TargetType: SSM_DOCUMENT
TargetId: AWSConfigRemediation-EncryptS3BucketVolume
Automatic: true
MaximumAutomaticAttempts: 3
RetryAttemptSeconds: 60
Automatic Remediation Patterns
There are two canonical remediation paths, and choosing between them depends on latency and complexity requirements.
The Config-native remediation path uses AWS::Config::RemediationConfiguration to invoke an SSM Automation runbook whenever a rule reports NON_COMPLIANT. AWS provides prebuilt runbooks such as AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules, and AWSConfigRemediation-EncryptSNSTopic. This path is declarative, integrates cleanly with conformance packs, and is ideal when a several-minute delay is acceptable.
The EventBridge-driven path is required when latency matters or when custom orchestration is needed. Config emits a Config Rules Compliance Change event on every state transition. An EventBridge rule filters on detail.newEvaluationResult.complianceType = NON_COMPLIANT and targets a Lambda function (or Step Function, or SSM runbook directly). Because EventBridge fires within seconds of the evaluation, sub-minute remediation windows become feasible.
{
"source": ["aws.config"],
"detail-type": ["Config Rules Compliance Change"],
"detail": {
"configRuleName": ["restricted-ssh"],
"newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
}
}
The Lambda handler then calls RevokeSecurityGroupIngress on the offending SG. Whichever path you choose, the automation must assume an IAM role with the minimum permissions to modify the target resource. A frequent failure mode is a Config rule that shows compliance status flipping between NON_COMPLIANT and COMPLIANT indefinitely because the remediation runbook errors on AccessDenied — Config records the invocation but silently proceeds. Always inspect the SSM Automation execution history and grant the runbook role the specific mutating permissions it needs (for example, ec2:CreateFlowLogs, iam:PassRole for the flow-log delivery role, and logs:CreateLogGroup).
Systems Manager Automation and Patch Manager
SSM Automation runbooks are the workhorse for imperative remediation. They are versioned YAML/JSON documents describing steps — API calls, approvals, branching — executed by an IAM role you specify. Beyond Config-triggered remediation, they run scheduled hygiene tasks: rotating access keys, tagging unattached EBS volumes, or terminating stopped instances after 30 days.
Patch Manager is a subsystem of SSM that keeps operating systems compliant with a patch baseline (a set of approved patches, classifications, and severity filters). Instances are grouped into patch groups via the Patch Group tag; a maintenance window schedules the AWS-RunPatchBaseline document against them. Compliance status flows back into Config and Security Hub, closing the loop between OS-level state and organizational reporting.
Service Catalog, CloudFormation StackSets, and Preventive Guardrails
Detection and remediation are reactive. To prevent noncompliance, use preventive controls:
Service Catalog publishes curated, parameterized CloudFormation templates as products. Developers launch approved patterns (a hardened VPC, an encrypted RDS cluster) without needing IAM permissions to the underlying services, which enforces separation of duties between the platform team and consumers.
CloudFormation StackSets deploy identical stacks across accounts and Regions. With service-managed permissions and OU targeting, a single operation lands Config recorders, IAM roles, or GuardDuty detectors into every account in the organization, including newly created ones via automatic deployment.
Service Control Policies (SCPs) are the only mechanism that can outright deny an API call at the organization boundary. Config and SSM cannot prevent a
RunInstancescall that lacks encryption — they can only detect and remediate afterward. Attempting to enforce hard prohibitions (“no public S3 buckets, ever”) purely with Config rules leaves a window between resource creation and remediation. Pair a Config detective rule with an SCP such ass3:PutBucketPublicAccessBlockdenial to close the gap.
Disaster Recovery: Backup, Templates, and Source Control
Meeting RPO/RTO targets requires that both data and infrastructure definitions are recoverable. AWS Backup centralizes backup policies across EBS, RDS, DynamoDB, EFS, and FSx; organization backup policies enforce plans across member accounts, and cross-Region, cross-account copies protect against Region loss and account compromise. The RPO is set by backup frequency; the RTO depends on restore mechanics (a DynamoDB PITR restore is minutes; an RDS snapshot restore across Regions can be an hour).
Infrastructure recovery relies on CloudFormation templates stored in CodeCommit (or another Git provider) as the single source of truth. Redeploying a StackSet from version-controlled templates rebuilds VPCs, IAM, and application stacks in a recovery Region in minutes. Keeping templates only in the console — with no repo — makes RTO unpredictable because there is no reproducible artifact.
Trap Analysis
Three misconceptions consistently produce wrong answers. First, treating Config as a preventive control: it evaluates after CloudTrail records the change, so genuine prohibitions require SCPs. Second, wiring up remediation without an adequately scoped IAM role — the SSM document exists and the Config rule fires, but the runbook fails silently on permission errors. Third, running organization-wide services from the management account instead of registering a delegated administrator, which forces per-account manual enablement and blocks organization-wide aggregators from working correctly.
Practical Problem: Use-Case Scenario
Scenario: Meridian Financial runs a multi-account AWS environment with separate production, development, and security accounts under AWS Organizations. The security team must prove continuous compliance with internal controls and regulators while managing hundreds of EC2 instances, S3 buckets, and Lambda functions across regions.
Challenge: A recent audit found unpatched EC2 instances, public S3 buckets and inconsistent baseline enforcement across accounts; remediation is manual and slow, and preventive controls are not uniformly applied.
Recommended Approach:
- Designate the Security account as the AWS Config delegated administrator and deploy an AWS Config Aggregator via CloudFormation StackSets to collect configuration and compliance data from all accounts and regions.
- Deploy organization-level AWS Config Conformance Packs from the security account (using StackSets) to codify baseline controls (S3 public access, encryption, tagging) so the same rules apply consistently.
- Attach AWS Config automatic remediation actions to high-risk rules that invoke AWS Systems Manager Automation documents (registered as remediation runbooks) so violations trigger SSM Automation or Run Command remediation automatically.
- Use AWS Systems Manager Patch Manager with SSM Patch Baselines and State Manager to define patch groups and automate OS patching across accounts; feed patch compliance results into the Config Aggregator.
- Publish approved CloudFormation templates into AWS Service Catalog and use CloudFormation StackSets to deploy or update compliant stacks; enforce preventive guardrails with AWS Organizations Service Control Policies to block disallowed resource creation (for example, disabling public S3 bucket creation).
- Configure Amazon EventBridge (CloudWatch Events) and SNS to notify the security team on noncompliance and to trigger additional SSM Automation workflows for complex incidents.
Rationale: Centralizing detection with Config Aggregator and conformance packs, automating remediation through SSM, and enforcing preventive guardrails via Service Catalog/StackSets and SCPs provides consistent, auditable controls and rapid remediation in line with AWS best practices for security, compliance, and least privilege.
← Edge · All domains · Vulnerability →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →