This chapter covers AWS Config Rules and Conformance Packs, two critical services for enforcing compliance and security best practices in AWS environments. For the SAA-C03 exam, questions on Config Rules appear in approximately 5-8% of exams, often as part of multi-service scenarios involving security, auditing, and automation. You will need to understand how managed and custom rules work, how to evaluate compliance states, how to trigger remediation, and how Conformance Packs simplify deploying rule sets for frameworks like PCI DSS or CIS benchmarks. Mastering these concepts will help you design secure, auditable architectures that meet regulatory requirements.
Jump to a section
Imagine a large office building with hundreds of rooms, each containing various equipment. The building has a set of strict safety codes: every fire extinguisher must be within 50 feet of any point, emergency exits must be unobstructed, and electrical panels must have 36 inches of clearance. Instead of hiring a human inspector to walk the building weekly, you install a network of sensors and cameras. Each sensor continuously monitors a specific rule: one camera checks exit paths, another measures distances to extinguishers. When a sensor detects a violation—say a desk moved in front of an exit—it sends an alert to the building management system. The system logs the violation, can trigger an automatic corrective action (like sending a janitor to clear the path), and provides a compliance dashboard showing the status of every rule across all floors. This is exactly how AWS Config Rules work: they are automated, continuous checks against your resource configurations, comparing actual state against desired policies, and they can trigger remediation actions or notify you via SNS. Conformance Packs are like pre-packaged sets of these sensors bundled by the building code authority—AWS provides ready-made packs for common compliance frameworks like PCI DSS or HIPAA, so you don't have to define every sensor from scratch.
What Are AWS Config Rules and Why Do They Exist?
AWS Config Rules are automated compliance checks that evaluate your AWS resource configurations against desired policies. They are a feature of AWS Config, a service that records resource configuration changes and maintains a configuration history. Rules allow you to continuously monitor and assess whether your resources comply with internal best practices, security standards, or regulatory requirements.
Without Config Rules, compliance checks are manual, point-in-time, and error-prone. You would need to periodically run scripts or use third-party tools to scan your environment. Config Rules automate this: they run evaluations whenever a configuration change occurs (triggered by AWS Config recording) or on a periodic schedule (e.g., every 6 hours). When a resource violates a rule, Config can trigger automatic remediation actions via Systems Manager Automation or send notifications through Amazon SNS.
How Config Rules Work Internally
Config Rules operate as AWS Lambda functions (for custom rules) or as predefined managed rules. The evaluation engine works as follows:
Trigger: A rule is triggered either by a configuration change (e.g., an EC2 instance is launched or modified) or on a periodic schedule (e.g., every 24 hours). The trigger type is defined when the rule is created.
Evaluation: The rule's Lambda function receives an event containing the resource configuration (for change-triggered rules) or a list of resources to evaluate (for periodic rules). The function compares the resource attributes against the rule's logic. For managed rules, AWS provides the Lambda function internally.
Compliance State: The function returns one of: COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE (if the rule doesn't apply to the resource type), or INSUFFICIENT_DATA (if data is missing, e.g., the resource was deleted). Config records the state in its configuration history.
Remediation: If the rule has an associated remediation action (via Systems Manager Automation), Config can automatically execute it when a resource is non-compliant. Remediation can be automatic (on every violation) or manual (on demand).
Aggregation: You can aggregate compliance data across multiple accounts and regions using an aggregator, giving a centralized view.
Key Components, Values, Defaults, and Timers
Managed Rules: AWS provides over 150 predefined rules for common compliance checks. Examples: ec2-encrypted-volumes (checks EBS volumes are encrypted), s3-bucket-public-read-prohibited, iam-user-mfa-enabled. You cannot modify the logic of managed rules, but you can configure parameters (e.g., the required encryption key ID).
Custom Rules: You write your own Lambda function in Python, Node.js, Java, or .NET to evaluate custom logic. The function must return a compliance state and can evaluate multiple resources per invocation.
- Trigger Types:
- Configuration changes: Evaluates only the resource that changed. Use for rules that apply to specific resource types.
- Periodic: Evaluates all resources of the types specified in the rule on a schedule (e.g., 24 hours). Use for rules that need to check all resources regularly, like ensuring all S3 buckets are encrypted.
Evaluation Frequency: For periodic rules, you can set the frequency to 1, 3, 6, 12, or 24 hours. The default is 24 hours.
Remediation: Uses AWS Systems Manager Automation documents. You can specify a document (e.g., AWS-DisablePublicAccessForS3Bucket) and parameters. You can choose automatic remediation (runs immediately when non-compliant) or manual (you run it from the console).
Conformance Packs: A collection of Config rules and remediation actions that can be deployed as a single entity. AWS provides sample packs for frameworks like PCI DSS, HIPAA, and CIS AWS Foundations Benchmark. You can also create custom packs. Conformance Packs use YAML templates.
Limits:
Maximum of 200 rules per region per account.
Maximum of 50 conformance packs per region per account.
Custom rule Lambda function timeout: 3 seconds for change-triggered, 10 seconds for periodic (but can be increased via Lambda configuration up to 15 minutes).
Configuration and Verification Commands
You can manage Config Rules via AWS CLI, SDK, or CloudFormation. Common CLI commands:
# List all rules in the current region
aws configservice describe-config-rules
# Get compliance details for a specific rule
aws configservice get-compliance-details-by-config-rule --config-rule-name my-rule
# List non-compliant resources for all rules
aws configservice get-compliance-summary-by-config-rule
# Describe a conformance pack
aws configservice describe-conformance-packs --conformance-pack-name my-pack
# Get compliance status of a conformance pack
aws configservice get-conformance-pack-compliance-details --conformance-pack-name my-packTo create a custom rule using CloudFormation:
Resources:
MyCustomRule:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: "check-ec2-instance-type"
Source:
Owner: CUSTOM_LAMBDA
SourceIdentifier: !GetAtt MyLambdaFunction.Arn
SourceDetails:
- EventSource: aws.config
MessageType: ConfigurationItemChangeNotification
Scope:
ComplianceResourceTypes:
- AWS::EC2::InstanceInteraction with Related Technologies
AWS Config: Config Rules depend on AWS Config recording. If recording is not enabled, rules cannot be triggered by configuration changes. Periodic rules still work because they do not rely on recording.
AWS Lambda: Custom rules require a Lambda function. The function must have an IAM role that allows it to call config:PutEvaluations to report compliance results.
Amazon SNS: You can set up SNS notifications for compliance state changes. For example, send an email when a resource becomes non-compliant.
AWS Systems Manager: Remediation actions use SSM Automation documents. You can create custom documents or use AWS-provided ones.
AWS CloudTrail: Config Rules do not directly use CloudTrail, but CloudTrail logs API calls to Config, which can be useful for auditing rule changes.
AWS Organizations: Conformance Packs can be deployed to all accounts in an organization using StackSets.
Conformance Packs Deep Dive
Conformance Packs allow you to deploy a group of Config rules and remediation actions together. They are defined in a YAML template that specifies:
ConformancePackInputParameters: Parameters you can pass to the pack (e.g., the required encryption key ID).
ConfigRule: Each rule in the pack, including managed rule names or custom rule definitions.
RemediationConfiguration: Optional remediation actions for each rule.
Example snippet of a conformance pack YAML:
Resources:
EncryptedVolumes:
Type: AWS::Config::ConfigRule
Properties:
Source:
Owner: AWS
SourceIdentifier: EC2_ENCRYPTED_VOLUMES
S3PublicRead:
Type: AWS::Config::ConfigRule
Properties:
Source:
Owner: AWS
SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED
RemediationConfiguration:
EncryptedVolumes:
TargetType: SSM_DOCUMENT
TargetId: AWS-EnableEBSEncryptionByDefault
Parameters:
AutomationAssumeRole: arn:aws:iam::123456789012:role/AutomationRoleConformance Packs provide a compliance dashboard showing overall pack compliance, individual rule compliance, and the ability to drill into non-compliant resources. They are ideal for multi-account environments where you need consistent governance.
Common Use Cases and Best Practices
Security Baseline: Enforce encryption, restrict public access, require MFA.
Cost Management: Use a custom rule to tag resources with cost centers.
Operational Compliance: Ensure EC2 instances are of approved types, or that EBS volumes are backed up.
Regulatory Compliance: Deploy conformance packs for PCI DSS, HIPAA, or CIS benchmarks.
Best practices include:
Use managed rules where possible to reduce maintenance.
Use periodic rules for global checks (e.g., all S3 buckets) and change-triggered rules for resource-specific checks.
Combine rules with remediation to auto-fix common issues (e.g., automatically enable encryption on unencrypted volumes).
Use conformance packs to enforce consistent policies across accounts.
Monitor compliance via dashboards and set up alerts for critical non-compliance.
Enable AWS Config Recording
Before Config Rules can work, AWS Config must be enabled and recording must be turned on for the resources you want to evaluate. Go to the AWS Config console and choose 'Get started'. Select the resource types to record (e.g., all resources or specific ones). You must also create an S3 bucket to store configuration history and snapshot files. Optionally, set up an SNS topic for notifications. Recording generates configuration items (CIs) whenever a resource is created, modified, or deleted. These CIs trigger change-triggered rules. Without recording, only periodic rules will work. Ensure the IAM role for Config has permissions to write to S3 and publish to SNS.
Create a Managed Config Rule
In the AWS Config console, navigate to 'Rules' and click 'Add rule'. Choose 'Add managed rule' and search for a rule like 's3-bucket-public-read-prohibited'. Configure parameters if needed (e.g., you can specify an exception list). Set the trigger type: 'Configuration changes' for immediate evaluation when a bucket is modified, or 'Periodic' to check all buckets every 24 hours. The rule will start evaluating resources immediately. After creation, you can view its compliance status in the dashboard. Managed rules are maintained by AWS and cannot be modified.
Create a Custom Config Rule
If a managed rule does not meet your needs, create a custom rule. First, write a Lambda function that receives an event and returns compliance results. The function must call the `PutEvaluations` API to report results. For example, a function that checks if EC2 instances have the `Environment` tag. Create the Lambda function with a role that has `config:PutEvaluations` permission. Then, in Config, choose 'Add custom rule' and provide the Lambda ARN. Specify the trigger type and scope (resource types to evaluate). The Lambda timeout should be at least 3 seconds for change-triggered rules. Test the rule by triggering a configuration change.
Configure Remediation Actions
To automatically fix non-compliant resources, attach a remediation action to a rule. In the rule's settings, choose 'Remediation' and select an SSM Automation document. For example, for the rule 'ec2-encrypted-volumes', you can use 'AWS-EnableEBSEncryptionByDefault' to automatically enable encryption on new volumes. Configure parameters like the AutomationAssumeRole. You can set remediation to run automatically on every violation or manually. Automatic remediation can cause cascading changes, so test in a non-production environment first. Remediation actions are logged in CloudTrail.
Deploy a Conformance Pack
Conformance Packs bundle multiple rules and remediations. In the Config console, go to 'Conformance packs' and click 'Deploy conformance pack'. Choose a sample pack (e.g., 'PCI-DSS') or upload your own YAML template. Specify input parameters (e.g., the S3 bucket to log violations). The pack will create all rules and remediation actions automatically. You can view the overall compliance of the pack in a single dashboard. Conformance Packs can be deployed across multiple accounts using AWS Organizations and StackSets. This ensures consistent compliance posture across your entire organization.
Enterprise Scenario 1: Financial Services PCI DSS Compliance
A large bank running a multi-account AWS environment needs to comply with PCI DSS. They deploy a Conformance Pack for PCI DSS that includes rules like ec2-encrypted-volumes, s3-bucket-public-read-prohibited, and vpc-default-security-group-closed. The pack is deployed using StackSets to 50 accounts. The security team monitors the centralized compliance dashboard. One day, a developer creates an S3 bucket with public read access for testing. The rule immediately flags it as non-compliant and triggers a remediation that removes the public access policy. The security team gets an SNS alert. The developer is notified and learns to use a pre-approved bucket with a lifecycle policy. The bank passes the PCI DSS audit because they can demonstrate continuous compliance monitoring.
Enterprise Scenario 2: Healthcare HIPAA Compliance
A healthcare company stores patient data in DynamoDB tables. They need to ensure all tables have encryption at rest enabled. They create a custom Config Rule that checks the SSESpecification attribute of DynamoDB tables. The rule is triggered on configuration changes. If a table is created without encryption, the rule marks it non-compliant and triggers a remediation that enables encryption (if the table is empty) or sends a notification to the admin. The rule also runs periodically every 6 hours to catch any tables that might have been modified. The company also uses a managed rule to ensure CloudTrail is enabled in all regions. The compliance team generates weekly reports from Config's configuration history.
Common Pitfalls in Production
Remediation Loops: If a remediation action itself triggers a configuration change (e.g., enabling encryption on a volume), it can cause the rule to re-evaluate and potentially trigger another remediation. To avoid loops, ensure remediation actions do not cause the same rule to become non-compliant again, or use manual remediation.
Lambda Timeout: Custom rules with complex logic may hit the default 3-second timeout. Increase the Lambda timeout appropriately, but be aware of cost implications.
Cross-Account Aggregation: Aggregators require careful IAM permissions and may have latency in data freshness (up to 15 minutes). Do not rely on aggregators for real-time compliance.
Conformance Pack Limits: Exceeding 50 packs per region will cause deployment failures. Plan pack structure carefully.
SAA-C03 Exam Focus on AWS Config Rules and Conformance Packs
The SAA-C03 exam tests your understanding of Config Rules primarily within the context of Secure Architectures (Domain 1) and Design for Security (Objective 1.4 – Implement security controls). You should expect scenario-based questions where you must choose the right combination of services to enforce compliance.
What the exam tests specifically: - Difference between managed and custom rules. - When to use change-triggered vs. periodic rules. - How to automate remediation using AWS Systems Manager. - How Conformance Packs simplify deploying multiple rules. - Integration with AWS Organizations for multi-account governance.
Common Wrong Answers and Why Candidates Choose Them: 1. Using AWS CloudTrail instead of Config Rules for compliance checks. Candidates think CloudTrail logs API calls, so it can detect non-compliance. However, CloudTrail is for auditing API activity, not for evaluating resource configurations against rules. Config Rules are purpose-built for this. 2. Choosing AWS Lambda alone without Config Rules for custom checks. While you could write a Lambda function to scan resources, Config Rules provide the trigger mechanism, compliance history, and dashboard. The exam expects you to use Config Rules for automated compliance. 3. Selecting 'AWS Config' but not enabling recording. If recording is not enabled, change-triggered rules won't work. The exam often presents a scenario where Config is enabled but recording is off, and candidates overlook this. 4. Confusing Conformance Packs with CloudFormation StackSets. Conformance Packs can be deployed via StackSets, but they are not the same. Conformance Packs specifically bundle Config rules and remediations, while StackSets deploy any CloudFormation resource.
Numbers and Terms to Memorize: - Maximum rules per region: 200. - Maximum conformance packs per region: 50. - Periodic rule frequencies: 1, 3, 6, 12, 24 hours (default 24). - Custom rule Lambda timeout: default 3 seconds for change-triggered, 10 seconds for periodic (can be increased). - Remediation uses SSM Automation documents.
Edge Cases the Exam Loves:
- If a resource is deleted, its compliance state becomes NOT_APPLICABLE (not NON_COMPLIANT).
- If a rule cannot get data (e.g., permissions error), the state is INSUFFICIENT_DATA.
- Managed rules cannot be modified; you must create a custom rule for custom logic.
- Conformance Packs do not support all resource types; check scope.
Eliminating Wrong Answers: - If the question asks for 'continuous compliance monitoring', the answer is Config Rules, not CloudTrail or IAM Access Analyzer. - If automation of remediation is needed, look for Systems Manager Automation or SSM documents. - If the scenario involves multiple accounts, think of Conformance Packs with StackSets. - If the question mentions 'pre-built compliance frameworks', it's Conformance Packs.
AWS Config Rules evaluate resource configurations against policies and report compliance states: COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, or INSUFFICIENT_DATA.
Managed rules are predefined by AWS and cannot be modified; custom rules use Lambda functions with the PutEvaluations API.
Change-triggered rules evaluate only when a resource changes; periodic rules evaluate all resources on a schedule (default 24 hours).
Remediation actions use SSM Automation documents and can be automatic or manual.
Conformance Packs bundle multiple rules and remediations into a single deployable template, supporting frameworks like PCI DSS and CIS.
Maximum 200 rules per region per account; maximum 50 conformance packs per region per account.
Config Rules require AWS Config recording to be enabled for change-triggered evaluations.
Conformance Packs can be deployed across multiple accounts using AWS Organizations and StackSets.
These come up on the exam all the time. Here's how to tell them apart.
Change-Triggered Rules
Evaluated only when a recorded resource changes (create, modify, delete).
Low latency: evaluation occurs within minutes of change.
Ideal for rules that check specific resource types (e.g., EC2 instance encryption).
Does not evaluate resources that are not modified, so some non-compliance may be missed if no change occurs.
Requires AWS Config recording to be enabled for the resource type.
Periodic Rules
Evaluated on a fixed schedule (1, 3, 6, 12, or 24 hours).
Evaluates all resources of the specified types, regardless of when they were last changed.
Ideal for rules that need to check all resources periodically (e.g., all S3 buckets for public access).
Can detect non-compliance even if no configuration change occurs.
Does not require recording for the resource type; uses API calls to get current state.
Mistake
Config Rules can evaluate resources that are not recorded by AWS Config.
Correct
Change-triggered rules only evaluate resources that are being recorded. If a resource type is not selected for recording, change-triggered rules will not evaluate it. Periodic rules, however, can evaluate any resource type regardless of recording status because they directly query the resource's current state via API calls.
Mistake
Custom Config Rules require you to write the evaluation logic from scratch without any AWS-provided code.
Correct
AWS provides sample Lambda functions for custom rules in the documentation. You can use these as a starting point. The core requirement is that your function calls the `PutEvaluations` API to report compliance results.
Mistake
Remediation actions can be triggered for any non-compliant resource without any additional configuration.
Correct
Remediation actions require you to explicitly associate an SSM Automation document with the rule. You must also configure IAM roles and parameters. Without this, the rule will only report non-compliance, not fix it.
Mistake
Conformance Packs are the same as AWS Config aggregators.
Correct
Conformance Packs group rules and remediations for deployment, while aggregators collect compliance data from multiple accounts/regions for a centralized view. They are complementary but distinct. You can aggregate compliance data from conformance packs deployed across accounts.
Mistake
You can modify the logic of a managed Config Rule by changing its parameters.
Correct
Managed rules have predefined logic that cannot be altered. You can only configure certain parameters (e.g., the encryption key ID for the `ec2-encrypted-volumes` rule), but you cannot change the core evaluation criteria. For custom logic, you must create a custom rule.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AWS Config is the service that records configuration changes and maintains a history of your AWS resources. Config Rules are a feature of AWS Config that evaluates those configurations against desired policies. Config without rules only records; adding rules enables compliance checking. Think of Config as the recording device and rules as the automated inspector.
Yes. You can use a managed rule like `required-tags` or create a custom rule that checks for specific tags. For example, a managed rule can require that resources have the 'CostCenter' tag. If a resource is created without it, the rule marks it non-compliant. You can also trigger a remediation to automatically add the tag.
In the Config rule settings, under 'Remediation', choose an SSM Automation document. For example, use `AWS-EnableS3BucketEncryption` for an S3 bucket that lacks encryption. You must specify an IAM role that the automation can assume. Then choose 'Automatic' remediation. When the rule detects non-compliance, the automation runs immediately. Test in a non-production environment first.
If a resource is deleted, AWS Config records a configuration item for the deletion. The rule will evaluate that event and typically return `NOT_APPLICABLE` because the rule no longer applies. The resource will not appear in the compliance status. Periodic rules will also see that the resource is gone and not include it in evaluations.
Yes. You can use an aggregator to view compliance across accounts. Conformance Packs can be deployed to multiple accounts using AWS CloudFormation StackSets. You can also use AWS Organizations to centrally manage rules. Each account must have AWS Config enabled and recording the relevant resources.
A Config rule is a single compliance check. A Conformance Pack is a collection of Config rules (and optional remediation actions) that are deployed together as a single unit. Conformance Packs are designed to implement entire compliance frameworks (e.g., PCI DSS) and provide a consolidated compliance dashboard. You can create a pack from scratch or use AWS-provided sample packs.
Periodic rules run on a schedule you specify: every 1, 3, 6, 12, or 24 hours. The default is 24 hours. Choose a frequency based on how quickly you need to detect non-compliance. For critical security rules, use a shorter interval, but be aware of cost implications (Lambda invocations and API calls).
You've just covered AWS Config Rules and Conformance Packs — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?