Security governance and compliance: the boring-sounding but absolutely vital rules that keep your cloud environment from turning into a free-for-all. Without them, you have no way to prove to auditors, customers, or regulators that your systems are secure — and in the AWS Certified Security Specialty exam, designing these controls is the entire point of Domain 5.1.
Jump to a section
A simple way to picture Security Governance, Compliance, and AWS Config
Have you ever wondered why restaurants have those letter grades in the window? That grade is the result of a health inspector checking the restaurant against a fixed set of rules — proper food storage temperatures, hand-washing sinks, pest control logs. The restaurant doesn't get to make up its own rules; it must follow the local health code or risk being shut down. In the cloud world, that health code is your compliance framework (like PCI DSS for credit card data or HIPAA for medical records), and the inspector is AWS Config.
AWS Config continuously records every change to your cloud kitchen — every new server you spin up (a virtual machine called an EC2 instance), every security group rule you open (like unlocking a back door), every storage bucket you make public. It then compares your current setup against a set of rules you define, called 'Config rules'. If Config spots a violation — for example, a storage bucket that should be private but is open to the whole internet — it flags it immediately, just like an inspector writing up a violation. You can even set it to auto-remediate (automatically fix the problem), like a restaurant manager rushing to close a door that was left ajar. The inspector doesn't run your kitchen; it just watches, records, and reports — and that's exactly what AWS Config does for governance and compliance.
In the simplest possible terms, security governance is the set of policies that dictate who can do what, when, and how in your AWS account. Compliance is the act of proving you are following those policies. AWS Config is the tool that does the proving for you, automatically.
Let's start with a fundamental concept: an AWS account is like a digital castle. Inside that castle, you have resources — virtual servers (EC2 instances), storage buckets (S3 buckets), databases, networking rules (security groups), and hundreds of other building blocks. Left unattended, anyone with access could create, modify, or delete these resources in ways that break your security policies. Security governance is the castle's rulebook: "No one may leave the front gate unlocked after sunset. All treasure chests must have a lock. Each guard must log their patrol."
AWS Config is the castle's automated watchman. It continuously records the state of every resource it is enabled on. This recording is called a configuration item (CI) — a snapshot of a resource at a point in time. Every time a resource changes — someone opens a port on a security group, attaches a new storage volume, changes a bucket's permissions — Config takes a new snapshot and stores it. This history allows you to see exactly what changed, when, and who made the change (via AWS CloudTrail, the audit log service).
Now, compliance. Compliance frameworks are external rulebooks that organisations choose to follow. Common ones include:
PCI DSS (Payment Card Industry Data Security Standard) — for handling credit card data.
HIPAA (Health Insurance Portability and Accountability Act) — for medical information.
SOC 2 (System and Organisation Controls) — for data privacy and security practices.
ISO 27001 — an international standard for information security management.
Each framework has hundreds of specific controls. For example, PCI DSS Requirement 7 states you must restrict access to cardholder data on a need-to-know basis. How do you prove you are doing that? AWS Config can run a managed rule called "iam-user-no-policies-check" that detects any IAM user who has permissions not assigned through a group or role — a clear violation of the principle of least privilege.
This is where Config rules come in. A Config rule is a piece of logic — either a predefined rule from AWS (a managed rule) or one you write yourself (a custom rule using AWS Lambda, a serverless compute service). The rule evaluates your resources and reports whether they are COMPLIANT or NON_COMPLIANT. For instance, a rule might check that every S3 bucket has versioning enabled (to prevent accidental deletion). If you create a bucket without versioning, Config flags it as NON_COMPLIANT within minutes.
Governance goes beyond checking. It also includes remediation — fixing non-compliant resources automatically. AWS Config can trigger an AWS Systems Manager Automation document — a pre-written script — to perform actions like closing an open security group port or enabling encryption on a storage volume. This is called auto-remediation.
Finally, aggregating Config data across multiple accounts and regions is handled by a feature called Config Aggregator. If your organisation has 50 AWS accounts, you don't want to log into each one to check compliance. Aggregator collects all that data in one central view.
In summary, AWS Config is the continuous compliance monitoring service that gives you visibility into what exists in your account, what rules it should follow, and whether it is actually following them. It replaces the old, error-prone method of manually checking resources or writing custom scripts that nobody maintains.
Enable AWS Config
Navigate to the AWS Config console and click 'Get started'. Choose which resource types to record (e.g., EC2, S3, IAM). You can record all resources or a subset. Also decide where to store the configuration history (an S3 bucket) and whether to stream updates to an SNS topic. This step makes Config start taking snapshots and tracking changes.
Define Config Rules
Add rules that represent your desired security posture. For governance, you might add a managed rule like 's3-bucket-public-read-prohibited' to ensure no storage bucket is open to the internet. Each rule evaluates resources and returns COMPLIANT or NON_COMPLIANT. This step enforces your policies automatically.
Set Up Auto-Remediation (Optional)
For critical rules, attach an SSM Automation document that runs when a resource is found NON_COMPLIANT. For example, if an EBS volume lacks encryption, Config triggers a document that creates an encrypted copy and attaches it. This step automates fixing violations, reducing manual effort and attack window.
Enable Aggregator for Multi-Account View
If you have multiple AWS accounts, create a Config Aggregator in a central account. Authorise each source account to share its Config data. This allows you to see compliance across the entire organisation from one place. This step gives you a governance dashboard for your whole cloud estate.
Review and Respond to Compliance Reports
Regularly check the Config dashboard or set up automated notifications (via Amazon SNS) when resources become NON_COMPLIANT. Generate compliance reports for auditors by exporting the configuration timeline. This step ensures continuous compliance and provides evidence for audits.
Meet Priya, a cloud security engineer at a healthcare startup called MediSecure. They handle patient records, so they must comply with HIPAA. Priya has just been told the company needs to pass a third-party audit next quarter. She has never used AWS Config before. Here is exactly what she does:
First, Priya enables AWS Config in the us-east-1 (North Virginia) region. She must do this per region if she wants coverage everywhere. She selects all resource types to record — EC2, S3, IAM, RDS (database), and more. Config starts recording immediately, creating a configuration history that goes back to the moment she turned it on.
Second, she sets up a Config rule for HIPAA compliance. AWS provides a bunch of managed rules under the "HIPAA Security" conformance pack. A conformance pack is a collection of rules and remediation actions bundled together for a specific standard. Priya selects the pack and deploys it. It automatically creates dozens of rules, such as: - ec2-ebs-encryption-by-default (every storage volume must be encrypted) - rest-api-logging-enabled (API calls must be logged) - iam-policy-no-statements-with-admin-access (no IAM policy should give full admin to everyone)
Almost immediately, Priya sees a red flag: three EC2 instances have unencrypted storage volumes. The rule shows them as NON_COMPLIANT. Config gives her a link to the specific resource ID.
Third, she sets up auto-remediation. For the unencrypted volume rule, she attaches an AWS Systems Manager Automation document called "AWSConfigRemediation-EnableEncryptVolume". This document snaps a picture of the volume, creates an encrypted copy, and swaps it in — all without downtime. Now, if someone creates a non-compliant volume, Config fixes it automatically within minutes.
Fourth, Priya needs to see compliance across all departments. The company has three AWS accounts — development, staging, and production. She sets up a Config Aggregator in a central "audit" account and authorises the other accounts to send their Config data there. Now she can generate a single dashboard showing compliance status across the entire organisation.
Finally, the auditor asks for evidence. Priya goes to the Config dashboard, selects a timeframe, and downloads a compliance report. She can also pull a configuration timeline for any specific resource to show every change made in the last 90 days. The auditor is satisfied because the evidence is automated, timestamped, and immutable — no one can retroactively modify Config logs.
Priya's daily work now includes checking compliance reports, tuning rules (e.g., adjusting thresholds for what counts as "unencrypted"), and responding to alerts when resources become non-compliant. AWS Config has given her a powerful tool to enforce governance without manually checking every server.
The SCS-C02 exam loves AWS Config. Domain 5.1 — Design and implement security governance and compliance controls — is heavily focused on how to use Config to prove compliance. Expect at least 5–7 questions on this topic across the exam. Here is what you absolutely must know:
First, managed rules vs. custom rules. The exam will test whether you know when to use a managed rule (AWS-provided, no coding needed) versus a custom rule (written in Python or Node.js using AWS Lambda). Managed rules cover common scenarios like encryption checks, logging checks, and IAM best practices. Custom rules are needed when your organisation has a proprietary policy — for example, "all EC2 instances must have a tag called 'CostCenter' with a value matching the finance department's list." A custom rule would need to call out to a database to verify the value.
Second, conformance packs. These are bundles of Config rules and remediation actions designed for specific compliance frameworks (CIS, NIST, HIPAA, PCI DSS). The exam will ask you which conformance pack to use for a given regulation. Memorise the major ones: CIS AWS Foundations, NIST 800-53, HIPAA Security, PCI DSS v3.2.1.
Third, remediation. The exam tests whether you know that auto-remediation uses AWS Systems Manager Automation documents (SSM documents). Config cannot fix issues by itself; it triggers an automation workflow. You may see a question where the correct answer involves creating an SSM document and attaching it to a Config rule.
Fourth, Config vs. other services. The exam loves to confuse you with similar-sounding services:
AWS CloudTrail: records API calls (who did what, when). It is about actions, not resource state.
AWS Security Hub: aggregates security findings from multiple services (Config, GuardDuty, Inspector) into a single dashboard. It shows high-level security posture.
AWS Config: records resource configurations and evaluates them against rules. It is about state, not actions.
Common traps:
The exam will ask: "Which service can monitor configuration changes to S3 buckets?" Some candidates pick CloudTrail. Wrong. CloudTrail records the API call to change the bucket policy, but Config records the actual configuration after the change and can check if it violates a rule.
They might say: "You need to ensure all EBS volumes are encrypted. Which service?" Answer: AWS Config with a managed rule (ec2-ebs-encryption-by-default). Not a Lambda function directly.
They might test: "You have 10 accounts and need a central compliance view. What feature?" Answer: Config Aggregator — not Security Hub (though Security Hub can also aggregate, but the question will specifically reference Config data).
Key definitions to memorise:
Configuration item (CI): a snapshot of a resource's configuration at a point in time.
Configuration history: a collection of CIs over time (up to 7 years, if you configure it to stream to S3).
Config rule: a rule that evaluates your resources against a desired configuration.
Evaluation: the periodic or triggered check of a resource against a rule (returns COMPLIANT or NON_COMPLIANT).
Remediation: the automatic or manual action to fix a non-compliant resource.
Conformance pack: a collection of rules and remediations for a specific compliance framework.
Finally, remember that Config is regional — you must enable it per region. To cover all regions, you typically use an AWS Organization and enable Config in every region. The exam will give a scenario where a company has resources in multiple regions but only enabled Config in one region, and ask what is wrong.
AWS Config is a continuous monitoring service that records resource configurations and evaluates them against rules you define.
Config rules can be either managed (pre-built by AWS) or custom (written as Lambda functions) to enforce your unique policies.
Auto-remediation in Config uses AWS Systems Manager Automation documents to fix non-compliant resources automatically.
Config is region-specific, so you must enable it separately for each region you want to monitor.
Config Aggregator allows you to view compliance data from multiple accounts and regions in a single dashboard.
Conformance packs bundle multiple Config rules and remediation actions together for specific compliance frameworks like HIPAA or PCI DSS.
Config does not log who made changes — use CloudTrail for identity auditing alongside Config for configuration tracking.
These come up on the exam all the time. Here's how to tell them apart.
AWS Config
Records resource configuration state
Evaluates resources against rules for compliance
Stores configuration items over time
AWS CloudTrail
Records API actions and user identity
Logs who made a change and from where
Does not evaluate resource state; just logs actions
Managed Config Rule
Pre-built by AWS for common compliance checks
No coding required
Limited to predefined parameter adjustments
Custom Config Rule
Written by you as a Lambda function
Allows any custom logic or external data lookup
Requires programming knowledge and Lambda setup
Config Conformance Pack
Collection of multiple rules and remediation actions
Targeted at a specific compliance framework (e.g., HIPAA)
One-click deployment for complete standard compliance
Individual Config Rules
Single rule for one specific check
Used for ad-hoc or unique policies
Requires manual grouping and management
Config (State Monitoring)
Monitors resource configurations and compliance
Runs on a schedule or when a resource changes
Produces compliance status (COMPLIANT/NON_COMPLIANT)
GuardDuty (Threat Detection)
Analyses network traffic and logs for threats
Uses machine learning and threat intelligence
Produces security findings (severity: HIGH/MEDIUM/LOW)
Mistake
AWS Config monitors user activity and logs who made changes.
Correct
Config records resource configuration changes. CloudTrail logs who made the API call. Config does not log identity; it tracks state.
Both services are often mentioned together, so beginners confuse their purposes.
Mistake
Once you enable Config, it automatically fixes all non-compliant resources.
Correct
Config only evaluates resources against rules. Auto-remediation is an optional feature you must explicitly configure using SSM Automation documents.
People assume 'monitoring' and 'fixing' come as a package. AWS separates the two to give you control.
Mistake
Config rules can be applied to resources across all AWS accounts from a single rule.
Correct
Config rules are per-account and per-region. To manage compliance across multiple accounts, you use Config Aggregator to view data centrally, but each account still has its own rules.
Centralised dashboards (like Security Hub) create the illusion of centralised rule enforcement.
Mistake
Config is only useful for large enterprises with compliance requirements.
Correct
Config is valuable for any organisation to track changes, detect misconfigurations early, and enforce security best practices. Even a single developer can use it to ensure they don't accidentally expose data.
Small teams often think compliance tools are overkill until they have a breach.
Mistake
CloudTrail and Config do the same thing — one records all changes, the other records some.
Correct
CloudTrail records API actions (who called what, when, from what IP). Config records the configuration state of resources (what settings were applied after the action). They complement each other but are not interchangeable.
Both produce logs and dashboards, so beginners assume redundancy.
Mistake
Custom Config rules cannot be written in any programming language — only AWS-specified ones.
Correct
You can write custom Config rules in any language that AWS Lambda supports (Python, Node.js, Java, etc.). The rule runs as a Lambda function that receives resource data and returns compliance status.
The name 'managed rules' suggests AWS controls all logic, but custom rules allow full flexibility.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CloudTrail records API actions (who did what, when, from where), while Config records the configuration state of resources (e.g., is this S3 bucket public or private?). Think of CloudTrail as the security camera that films who enters the room, and Config as the inventory list that shows what furniture is in the room and its condition.
Yes. AWS Config is a regional service, so you must enable it separately in each region where you have resources. You can use an AWS Organization-level policy or CloudFormation StackSets to enable it across all regions automatically.
Absolutely. AWS Config provides an immutable history of resource configurations, shows compliance status against rules, and lets you generate reports. Auditors accept these as evidence of continuous monitoring and enforcement.
You pay per configuration item recorded (each snapshot of a resource) and per Config rule evaluation. Costs can add up if you record all resource types in many regions, but AWS provides a free tier of 10,000 configuration items per month. Check the official pricing page for current rates.
Config will record the deletion as a configuration change. The last configuration item will show the user as deleted. The rule evaluation for that user will no longer apply, but the configuration history remains available for auditing purposes.
Yes. Create a Config rule called 's3-bucket-public-read-prohibited' (a managed rule). When someone changes the bucket policy to allow public access, Config will detect the new configuration and mark the bucket as NON_COMPLIANT within about 15 minutes.
AWS Config is designed for resources within AWS accounts only. To monitor on-premises resources, you would need to use AWS Systems Manager or other hybrid governance tools. However, you can use Config rules to evaluate resources that are managed via AWS CloudFormation StackSets across accounts.
You've finished Security Governance, Compliance, and AWS Config. Continue through the SCS-C02 study guide to build a complete picture of the exam.
Done with this chapter?