This chapter covers AWS Config auto-remediation actions, a feature that automatically corrects noncompliant resources based on Config rules. For the SOA-C02 exam, understanding auto-remediation is critical because it appears in roughly 10-15% of security-related questions, often in scenario-based items where you must choose the correct remediation approach. You will learn the mechanism, configuration steps, integration with Systems Manager Automation, and common pitfalls that exam questions exploit.
Jump to a section
Think of AWS Config auto-remediation as a programmable thermostat system in a smart building. The thermostat (AWS Config) continuously monitors the temperature (resource compliance) against a set point (desired configuration). When the temperature drifts outside the acceptable range (noncompliant resource), the thermostat triggers a predefined action: it signals the HVAC system (remediation action) to turn on cooling or heating. The HVAC system doesn't think; it just executes the command. Similarly, AWS Config uses an AWS Systems Manager Automation document (or a custom AWS Lambda function) as the remediation action. The thermostat can be set to automatically correct the temperature without human intervention, just as Config can automatically remediate noncompliant resources. However, if the thermostat is misconfigured—say, it triggers the heat when the temperature is already too high—it can make the problem worse. In the same way, a poorly designed remediation action can cause cascading failures or security holes. The building manager (SysOps admin) must carefully design the rules and test them in a small zone before rolling out building-wide. This analogy captures the monitoring, triggering, automated correction, and risk of unintended consequences inherent in auto-remediation.
What is AWS Config Auto-Remediation?
AWS Config auto-remediation is a feature that allows you to define automated actions to correct noncompliant resources detected by AWS Config rules. When a resource is evaluated as noncompliant, Config can automatically invoke a remediation action—typically an AWS Systems Manager Automation document or an AWS Lambda function—to bring the resource back into compliance. This reduces manual intervention and enforces security and operational policies continuously.
Why Auto-Remediation Exists
Before auto-remediation, AWS Config could only detect and alert on noncompliant resources. SysOps teams had to manually investigate and remediate each violation, which was slow and error-prone. Auto-remediation closes the loop by enabling automatic correction, ensuring that configuration drift is fixed within minutes of detection. This is essential for maintaining compliance with standards like CIS Benchmarks, PCI DSS, and HIPAA.
How It Works Internally
The auto-remediation process involves several components working together:
1. AWS Config Rule: A rule that evaluates resources against a desired configuration. When a resource is noncompliant, Config generates a compliance change notification. 2. Remediation Action: An action associated with the rule. Config supports two types: - AWS Systems Manager Automation Documents: Predefined or custom runbooks that execute steps to remediate the resource. - AWS Lambda Functions: Custom code that performs the remediation. 3. Remediation Execution: When Config detects noncompliance, it checks if the rule has an associated remediation action. If yes, it invokes the action, passing details about the noncompliant resource (e.g., resource ID, type, account, region). 4. Retry and Error Handling: If the remediation fails, Config can retry up to 5 times with exponential backoff. You can also configure a maximum number of retries (default 5) and a retry interval (default 60 seconds). If all retries fail, the remediation is marked as failed. 5. Resource Policy: The remediation action must have the necessary IAM permissions to modify the resource. Config uses the IAM role attached to the action (for Automation documents) or the Lambda execution role.
Key Components, Values, Defaults, and Timers
- Remediation Action Types:
- SSM_DOCUMENT: Uses an Automation document.
- LAMBDA: Uses a Lambda function.
- Default Retry Count: 5 attempts.
- Default Retry Interval: 60 seconds.
- Automatic Remediation: Enabled by default when you associate a remediation action. You can disable it to only allow manual remediation.
- Resource Exclusion: You can exclude specific resources from auto-remediation by adding resource IDs to an exclusion list.
- Execution Timeout: For Automation documents, the default timeout is 3 hours. For Lambda functions, the timeout is set on the function itself (max 15 minutes).
- Concurrent Remediations: Config can execute multiple remediations in parallel, but you should consider API rate limits.
Configuration Steps
To configure auto-remediation:
Create a Config rule (e.g., s3-bucket-public-read-prohibited).
Associate a remediation action with the rule. You can use an existing Automation document or create a custom one. For example, to remediate a publicly readable S3 bucket, you might use the AWSConfigRemediation-EnableS3BucketPublicAccessBlock document.
Set the IAM role that the Automation document will assume. This role must have permissions to modify the target resource (e.g., s3:PutBucketPublicAccessBlock).
Optionally, configure retry settings and resource exclusions.
Test the remediation by triggering a manual evaluation or waiting for the next evaluation cycle.
Verification Commands and Logging
You can verify auto-remediation actions using:
- AWS CLI:
aws configservice describe-remediation-executions --config-rule-name <rule-name>CloudTrail: All remediation executions are logged in CloudTrail as StartAutomationExecution (for SSM) or Invoke (for Lambda) events.
Systems Manager Automation Console: View execution status and outputs.
AWS Config Console: Under the rule's details, you can see remediation execution history.
Interaction with Related Technologies
Auto-remediation integrates tightly with:
AWS Systems Manager Automation: The primary engine for remediation runbooks. Automation documents can include steps like aws:executeAwsApi, aws:executeScript, or aws:invokeLambdaFunction.
AWS Lambda: Allows custom remediation logic when Automation documents are insufficient.
AWS IAM: The IAM role attached to the remediation action must have least-privilege permissions. Common mistake: giving too broad permissions, which can be exploited.
AWS Config Rules: The rule must be of type MANAGED or CUSTOM (Lambda-backed). Auto-remediation is not supported for all rule types; for example, it works with managed rules that have a defined remediation document.
AWS CloudTrail: Provides audit trail of remediation actions.
Best Practices
Test Remediation in a Non-Production Environment: Use a staging account to validate that the remediation action does not break services.
Use Resource Exclusions: Exclude critical resources that should not be automatically modified (e.g., production databases).
Monitor Remediation Failures: Set up CloudWatch alarms on remediation failure metrics.
Log All Remediation Actions: Ensure CloudTrail is enabled to track who or what performed the remediation.
Implement Approval Workflows for High-Risk Actions: For destructive actions (e.g., terminating instances), consider using manual approval steps in Automation documents.
Common Exam Traps
Trap 1: Thinking auto-remediation works with all Config rules. Reality: Only rules that have a remediation action defined support auto-remediation. Custom Lambda rules can have remediation actions if you attach a Lambda function as the action.
Trap 2: Assuming retries are infinite. Reality: Maximum 5 retries with 60-second intervals.
Trap 3: Believing that auto-remediation can modify resources in another AWS account. Reality: Remediation actions operate within the same account unless you use cross-account IAM roles, which is not directly supported by Config auto-remediation.
Trap 4: Confusing auto-remediation with AWS Config conformance packs. Conformance packs deploy rules and remediation, but auto-remediation is a per-rule setting.
Create a Config Rule
First, define an AWS Config rule that evaluates a specific resource type for compliance. For example, create a managed rule `s3-bucket-public-read-prohibited` that checks if any S3 bucket allows public read access. The rule can be created via the AWS Config console, AWS CLI, or AWS CloudFormation. When the rule is enabled, Config begins evaluating resources at a frequency you specify (e.g., every 6 hours or on configuration changes).
Associate a Remediation Action
In the Config console, navigate to the rule and select 'Actions' > 'Manage remediation'. Choose the remediation action type: either an SSM Automation document or a Lambda function. For S3 public read, you might select the managed document `AWSConfigRemediation-EnableS3BucketPublicAccessBlock`. Provide the required parameters (e.g., `BucketName` is automatically passed from the noncompliant resource). Set the IAM role that the document will assume.
Configure Retry and Exclusion Settings
Optionally, adjust the retry count (default 5) and retry interval (default 60 seconds). You can also add resource IDs to an exclusion list to prevent automatic remediation on specific resources. For example, you might exclude a critical bucket that is intentionally public for a static website. Set automatic remediation to 'On' or 'Off' – if off, remediation must be triggered manually.
Test the Remediation Action
After configuration, you can test by re-evaluating the rule or manually invoking remediation. In the Config console, select the rule, go to 'Remediations' tab, and click 'Execute remediation' on a specific noncompliant resource. Verify that the remediation action runs successfully. Check Systems Manager Automation console for execution details or CloudTrail logs for Lambda invocations.
Monitor and Audit Remediation
Set up monitoring using Amazon CloudWatch metrics for Config (e.g., `NonCompliantResources`, `RemediationAttempts`). Create CloudWatch alarms for high failure rates. Audit all remediation actions via CloudTrail. For each execution, you can see the initiator (Config), the action taken, and the result. This is crucial for compliance reporting and troubleshooting.
Enterprise Scenario 1: Enforcing Encryption on S3 Buckets
A financial services company must ensure all S3 buckets have default encryption enabled. They use the managed Config rule s3-bucket-default-encryption-enabled. When a new bucket is created without encryption, Config detects noncompliance within minutes. The auto-remediation action invokes an SSM Automation document that calls s3:PutBucketEncryption to enable AES-256 encryption. The IAM role used by Automation has permissions only for s3:PutBucketEncryption on buckets tagged with Environment=Prod. This prevents accidental modification of buckets in other environments. In production, they handle thousands of buckets. Config's parallel remediation execution can handle the load, but they monitor for API rate limiting. Misconfiguration example: If the IAM role lacks s3:PutBucketEncryption, the remediation fails silently. They set up a CloudWatch alarm on the RemediationFailure metric to alert the team.
Enterprise Scenario 2: Restricting Security Group Ingress Rules
A SaaS company needs to ensure no security group allows inbound SSH (port 22) from 0.0.0.0/0. They use the managed rule restricted-ssh. Auto-remediation uses a custom Lambda function that removes the offending rule. The Lambda function is written in Python and uses boto3 to call ec2.revoke_security_group_ingress. The function's execution role has permissions to describe and revoke security group rules. They exclude security groups attached to their bastion hosts by adding the security group IDs to the exclusion list. A common pitfall: The Lambda function might fail if the security group is attached to an ENI that is in use, but the API still allows the revocation. They test thoroughly. They also set the retry count to 3 to avoid excessive API calls.
Enterprise Scenario 3: Auto-Remediation for IAM Policies
A government agency must ensure no IAM policy is overly permissive (e.g., * on *). They use a custom Config rule that evaluates IAM policies. When a noncompliant policy is found, auto-remediation triggers an Automation document that runs a script to attach a managed policy with restricted permissions and detaches the overly permissive policy. The document includes manual approval steps for policies attached to admin users. This is a high-risk action, so they set automatic remediation to 'Off' and use manual remediation only after review. This hybrid approach ensures safety while still providing automation for less critical resources.
What SOA-C02 Tests on This Topic
The SOA-C02 exam objective 4.2 includes 'Implement and manage automated remediation actions based on AWS Config rules'. Exam questions typically present a scenario where a company needs to automatically fix noncompliant resources. You must identify the correct combination of AWS Config rule, remediation action type, and IAM permissions. Specific objective codes: Domain 4 (Security) Objective 4.2.
Common Wrong Answers and Why Candidates Choose Them
Wrong Answer: 'Use AWS Lambda to invoke a Config rule.' Why wrong: Config rules evaluate resources, not the other way around. Lambda can be a remediation action, not a rule.
Wrong Answer: 'Auto-remediation can be used with any Config rule.' Why wrong: Only rules that have a remediation action defined support auto-remediation. Some rules (e.g., those that only check tags) may not have a suitable remediation action.
Wrong Answer: 'Set the retry count to 10 for critical failures.' Why wrong: Maximum retries is 5. Candidates assume they can increase it arbitrarily.
Wrong Answer: 'Use AWS Config to directly modify the resource.' Why wrong: Config itself does not modify resources; it triggers an SSM Automation or Lambda action.
Specific Numbers, Values, and Terms
Default retry count: 5
Default retry interval: 60 seconds
Remediation action types: SSM_DOCUMENT and LAMBDA
Maximum Lambda execution time: 15 minutes
Automation document timeout: 3 hours
Resource exclusion: via resource IDs
Automatic remediation: can be toggled on/off per rule
Edge Cases and Exceptions
Cross-account remediation: Not supported natively. You would need to use a Lambda function that assumes a role in another account, but Config passes only the resource ARN within the same account.
Remediation failure handling: If the remediation action fails after retries, Config does not retry further. The resource remains noncompliant.
Concurrent execution limits: Config can execute multiple remediations concurrently, but there are service limits (e.g., 50 concurrent executions per account per region for SSM Automation).
Resource types: Not all resource types support remediation actions. For example, AWS::IAM::User may not have a predefined remediation document.
How to Eliminate Wrong Answers
If the question mentions 'automatically fix noncompliant resources', look for answer choices that include AWS Config auto-remediation with SSM Automation or Lambda.
If the answer suggests modifying Config rules or using CloudWatch Events, it's likely wrong because auto-remediation is a built-in feature, not a custom event-driven solution.
Eliminate answers that propose using AWS Config alone to modify resources—Config only evaluates.
Check IAM permissions: The remediation action's role must have permissions to modify the resource. If the answer lacks a mention of IAM role, it's incomplete.
Auto-remediation uses SSM Automation documents or Lambda functions to fix noncompliant resources.
Default retry count is 5 with 60-second intervals; maximum retries is 5.
Remediation actions must have an IAM role with permissions to modify the target resource.
Resource exclusion lists allow you to prevent auto-remediation on specific resources.
Auto-remediation is configured per Config rule, not globally.
CloudTrail logs all remediation executions for auditing.
Not all resource types support auto-remediation; check AWS documentation for supported types.
These come up on the exam all the time. Here's how to tell them apart.
SSM Automation Document
Predefined runbooks available for common remediations.
Supports multi-step workflows with conditional logic.
Can include manual approval steps.
Execution timeout up to 3 hours.
Logs execution details in Systems Manager Automation console.
AWS Lambda Function
Custom code for complex or unique remediation logic.
Single function execution with max 15-minute timeout.
No built-in approval workflow (must be coded).
Requires managing Lambda code and dependencies.
More flexible but requires more development effort.
Mistake
Auto-remediation works with every AWS Config rule automatically.
Correct
Auto-remediation must be explicitly configured per rule. Only rules with an associated remediation action (SSM document or Lambda) can auto-remediate.
Mistake
Config auto-remediation can modify resources in any AWS account.
Correct
Config auto-remediation operates within the same account. Cross-account remediation would require a custom Lambda function that assumes a role in another account, which is not a built-in feature.
Mistake
You can set an unlimited number of retries for remediation.
Correct
The maximum number of retries is 5, with a default interval of 60 seconds. You cannot increase this limit.
Mistake
Auto-remediation is the same as AWS Config conformance packs.
Correct
Conformance packs can include remediation actions, but auto-remediation is a per-rule setting. Conformance packs are a way to deploy multiple rules and remediation at scale, but the underlying mechanism is the same.
Mistake
Remediation actions can be triggered by any AWS Config rule, including custom Lambda rules.
Correct
Remediation actions can be associated with custom Lambda rules, but the rule itself must be evaluated by Config. The remediation action is separate from the rule evaluation Lambda.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can associate a remediation action with custom Config rules (Lambda-backed rules). The remediation action is separate from the rule evaluation Lambda. For example, you might have a custom rule that checks for unencrypted RDS instances, and attach an SSM Automation document to enable encryption. The rule evaluation Lambda only reports compliance; the remediation action does the fixing.
Config will retry the remediation up to 5 times with a 60-second interval between attempts (configurable). If all retries fail, the remediation is marked as failed, and the resource remains noncompliant. You can monitor remediation failures via CloudWatch metrics and set up alarms. The failure could be due to insufficient IAM permissions, resource not found, or API throttling.
Yes, even if automatic remediation is disabled, you can manually invoke remediation on a specific noncompliant resource from the AWS Config console. This is useful for testing or for high-risk actions that require human approval. Manual remediation still uses the same SSM Automation document or Lambda function.
Auto-remediation is a regional feature. You must configure it in each region where you have resources. Config rules and remediation actions are regional. However, you can use tools like AWS CloudFormation StackSets to deploy the same configuration across multiple regions.
In the remediation configuration, you can add resource IDs to an exclusion list. For example, you might exclude a production database from automatic deletion policies. The exclusion list supports up to 100 resource IDs per rule. Resources in the exclusion list will still be evaluated as noncompliant, but no remediation action will be taken.
The IAM role attached to the remediation action must have permissions to perform the required API calls on the target resource. For example, to modify an S3 bucket's public access block, the role needs `s3:PutBucketPublicAccessBlock`. The role also needs permissions for Config to assume it (via `sts:AssumeRole`). The role should follow least-privilege principles.
Auto-remediation itself is per-account. However, you can use AWS Config aggregators and conformance packs to deploy rules and remediation across multiple accounts in an organization. The remediation actions still run within each individual account. For cross-account remediation, you would need a custom solution using Lambda and cross-account IAM roles.
You've just covered AWS Config Auto-Remediation Actions — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?