This chapter covers CloudFormation drift detection and stack policies, two critical mechanisms for maintaining the integrity of your infrastructure as code. Drift detection allows you to identify when resources in a stack have been manually modified outside of CloudFormation, while stack policies prevent accidental updates or deletions of critical resources. For the DVA-C02 exam, these topics appear in approximately 10-15% of questions related to deployment and infrastructure management. Understanding how to detect and prevent drift is essential for ensuring that your CloudFormation stacks remain in sync with your templates and that production environments are not inadvertently disrupted.
Jump to a section
Imagine a safety deposit box in a bank. The box contains valuable items (your stack resources). You have a key (the stack policy) that allows you to open the box and modify its contents. However, the bank has a strict rule: you can only change items that are not listed as 'protected' on a special list inside the box. This list is the stack policy. When you try to replace a protected item, the bank's security system (CloudFormation) checks the list first. If the item is protected, it denies the change and logs the attempt. If the item is not protected, the change proceeds. The list itself can only be modified before you close the box (during stack updates) by providing a new list. Once closed, the list is enforced until the next time you open the box. This ensures that critical items (like database passwords or production configurations) are never accidentally changed or deleted during routine updates. The bank's audit log records every attempt, successful or not, just as CloudFormation logs all drift detection results.
What is Drift Detection and Why Does It Exist?
Drift detection is a feature of AWS CloudFormation that allows you to determine whether a stack's actual resource configuration has deviated from the expected configuration defined in the stack's CloudFormation template. Drift occurs when resources are modified outside of CloudFormation—for example, via the AWS Management Console, AWS CLI, or SDKs—without updating the corresponding stack. This can lead to configuration inconsistencies, making it difficult to manage infrastructure reliably and predictably.
The primary purpose of drift detection is to help you identify and remediate these discrepancies, ensuring that your infrastructure remains in a known and controlled state. Without drift detection, you might assume that your stack is up-to-date when, in reality, manual changes have been made that could cause unexpected behavior during subsequent updates or operations.
How Drift Detection Works Internally
When you initiate drift detection on a stack, CloudFormation performs a detailed comparison between the current state of each resource in the stack and the expected state defined in the stack template. The process involves the following steps:
Detection Request: You call the DetectStackDrift API (via AWS CLI, SDK, or Console) specifying the stack name. CloudFormation then begins the drift detection process.
Resource Evaluation: For each resource in the stack, CloudFormation retrieves the current configuration using the resource's underlying AWS service APIs (e.g., EC2 DescribeInstances, S3 GetBucketPolicy). It then compares this configuration against the expected configuration from the template, taking into account any resource properties that are not supported for drift detection (these are marked as NOT_CHECKED).
3. Drift Status Assignment: Each resource is assigned a drift status: - IN_SYNC: The resource's current configuration matches the expected configuration. - MODIFIED: The resource's current configuration differs from the expected configuration. - DELETED: The resource has been deleted outside of CloudFormation. - NOT_CHECKED: CloudFormation does not support drift detection for this resource type or property.
4. Stack Drift Status: After evaluating all resources, CloudFormation assigns an overall drift status to the stack: - DRIFTED: At least one resource has a drift status of MODIFIED or DELETED. - IN_SYNC: All resources are IN_SYNC. - NOT_CHECKED: All resources are NOT_CHECKED (or the stack has no resources). - UNKNOWN: The drift detection operation failed for some reason.
Detailed Results: You can retrieve detailed drift information for specific resources using DescribeStackResourceDrifts API, which provides the actual and expected property values for each drifted property.
Key Components, Values, and Defaults
Drift Detection API: DetectStackDrift (stack-level), DetectStackResourceDrift (resource-level), DescribeStackResourceDrifts (list drifts).
Drift Status Values: IN_SYNC, MODIFIED, DELETED, NOT_CHECKED.
Stack Drift Status Values: DRIFTED, IN_SYNC, NOT_CHECKED, UNKNOWN.
Supported Resource Types: Drift detection is supported for most AWS resource types, but some properties are not checked. For example, AWS::Lambda::Function properties like Code (the actual code zip) are not checked, while Handler, Runtime, and MemorySize are checked.
Limits: You can have up to 20 drift detection operations running simultaneously per account per region. The maximum number of resource drift results that can be returned per API call is 100.
Configuration and Verification Commands
To detect drift on a stack using the AWS CLI:
aws cloudformation detect-stack-drift --stack-name my-stackThis returns a StackDriftDetectionId that you can use to track the progress of the detection operation. To check the status:
aws cloudformation describe-stack-drift-detection-status --stack-drift-detection-id <id>To get detailed drift information for all drifted resources:
aws cloudformation describe-stack-resource-drifts --stack-name my-stack --stack-resource-drift-status-filters MODIFIED DELETEDWhat is a Stack Policy and Why Does It Exist?
A stack policy is a JSON document that defines the update actions that can be performed on designated resources during a stack update. It acts as a safeguard to prevent accidental updates or deletions of critical resources. For example, you might create a stack policy that denies updates to a production database's deletion policy, ensuring that the database cannot be accidentally deleted during an update.
Stack policies are only enforced during stack updates—they do not affect stack creation or deletion. They are evaluated before any changes are made to resources. If a policy denies a particular action, the entire update fails, and no resources are modified.
How Stack Policies Work Internally
When you initiate a stack update, CloudFormation evaluates the stack policy for each resource that is being updated, replaced, or deleted. The policy consists of a set of statements, each with an effect (Allow or Deny), an action (Update:Modify, Update:Replace, Update:Delete), and a principal (always "*") and a resource (the logical resource IDs or a wildcard "*").
The evaluation logic follows standard IAM policy evaluation rules:
Deny statements override Allow statements.
By default, all update actions are allowed unless explicitly denied.
If a resource is not covered by any statement, the action is allowed.
If a resource is covered by both an Allow and a Deny, the Deny takes precedence.
Key Components and Defaults
- Policy Document Structure:
- Statement: An array of policy statements.
- Effect: Allow or Deny.
- Action: One or more of Update:Modify, Update:Replace, Update:Delete.
- Principal: Always "*" (cannot be changed).
- Resource: The logical resource ID(s) or "*" for all resources.
Default Policy: If you do not specify a stack policy, all update actions are allowed on all resources. This is equivalent to an allow-all policy.
Policy Size: The maximum size of a stack policy document is 4,096 bytes.
Configuration and Verification Commands
To set a stack policy during stack creation:
aws cloudformation create-stack --stack-name my-stack --template-body file://template.json --stack-policy-body file://policy.jsonTo update a stack policy on an existing stack:
aws cloudformation set-stack-policy --stack-name my-stack --stack-policy-body file://policy.jsonTo retrieve the current stack policy:
aws cloudformation get-stack-policy --stack-name my-stackInteraction Between Drift Detection and Stack Policies
Drift detection and stack policies address different aspects of stack management. Drift detection identifies changes made outside of CloudFormation, while stack policies control changes made through CloudFormation updates. They are complementary: stack policies help prevent accidental changes during updates, while drift detection helps you identify changes that occur outside of updates. You can use both together to maintain a tightly controlled infrastructure environment.
Common Pitfalls
Drift detection does not automatically remediate drift; it only reports it. You must manually update the stack or revert the manual changes.
Stack policies do not prevent manual changes via the Console or CLI; they only affect CloudFormation update operations.
If a resource is deleted outside of CloudFormation, drift detection will report it as DELETED, but the stack will still consider it as part of its template. To remove the resource from the stack, you must update the template and delete the resource from the stack.
Stack policies can be overridden during an update if you explicitly pass a temporary policy that allows the denied action. This is done using the --stack-policy-during-update-body parameter in the update-stack command.
Initiate Drift Detection on Stack
Use the AWS CLI, Console, or SDK to call `DetectStackDrift` with the stack name. CloudFormation receives the request and generates a unique detection ID. The operation is asynchronous; CloudFormation begins evaluating each resource in the stack. You can monitor the progress using `DescribeStackDriftDetectionStatus`. The detection process may take several minutes depending on the number of resources.
CloudFormation Compares Resource States
For each resource, CloudFormation calls the underlying AWS service API to retrieve the current configuration. For example, for an EC2 instance, it calls `DescribeInstances` to get the current instance type, security groups, etc. It then compares these values to the expected values from the stack template. Properties that are not supported for drift detection are marked as NOT_CHECKED. The comparison is done property by property.
Drift Status Assigned to Each Resource
Based on the comparison, each resource is assigned a drift status: IN_SYNC if all checked properties match; MODIFIED if any checked property differs; DELETED if the resource no longer exists; NOT_CHECKED if none of the properties are checked. This status is stored and can be retrieved via `DescribeStackResourceDrifts`.
Overall Stack Drift Status Determined
After all resources are evaluated, CloudFormation aggregates the individual statuses to determine the stack drift status. If any resource is MODIFIED or DELETED, the stack is DRIFTED. If all are IN_SYNC, the stack is IN_SYNC. If all are NOT_CHECKED, the stack is NOT_CHECKED. If the detection failed, the status is UNKNOWN.
Review Drift Details and Remediate
Use `DescribeStackResourceDrifts` to view the actual and expected values for each drifted property. To remediate, you can either update the stack to match the current state (by importing the resource or updating the template) or revert the manual changes to match the template. After remediation, you can run drift detection again to confirm the stack is IN_SYNC.
Scenario 1: Enterprise Production Database Protection
A large e-commerce company runs a production MySQL database on RDS managed by CloudFormation. The database is critical and must never be accidentally deleted or replaced during stack updates. The operations team implements a stack policy that explicitly denies Update:Delete on the database resource. They also set up drift detection to run nightly via a scheduled Lambda function. One day, a developer manually changes the database backup retention period from 7 to 30 days via the RDS console. Drift detection catches this change, alerting the team. They then update the CloudFormation template to reflect the new retention period and run a stack update to bring the stack back in sync. The stack policy prevents any accidental deletion of the database during this update.
Scenario 2: Multi-Region Infrastructure with Compliance Requirements
A financial services company manages infrastructure across three AWS regions using CloudFormation StackSets. Compliance requires that security group rules for a critical application are never modified outside of CloudFormation. They use drift detection on all stack instances to ensure no manual changes are made. When drift is detected (e.g., an engineer adds an SSH rule via the console for debugging), the incident triggers an automated rollback using AWS Config and Lambda. The team also uses stack policies to prevent any update that would replace the security group itself, ensuring that the security group's logical ID remains constant across updates.
Scenario 3: Shared Infrastructure with Multiple Teams
A SaaS company uses a shared VPC stack managed by a central platform team. Individual product teams have access to deploy their own resources within the VPC but should not modify the VPC itself. The platform team attaches a stack policy that denies Update:Modify, Update:Replace, and Update:Delete on the VPC and its core components (subnets, route tables, internet gateway). The product teams can still update their own resources in separate stacks. Drift detection is run periodically to ensure that no one has manually altered the VPC configuration. When a developer accidentally deletes a subnet via the console, drift detection flags the deletion, and the platform team restores the subnet from a CloudFormation backup template.
What DVA-C02 Tests on This Topic
The DVA-C02 exam covers drift detection and stack policies under Domain 3.0 (Deployment), Objective 3.2: "Manage infrastructure using AWS CloudFormation." Specific subtopics include:
Understanding the purpose of drift detection and how to initiate it.
Interpreting drift status values (IN_SYNC, MODIFIED, DELETED, NOT_CHECKED).
Knowing which resources and properties support drift detection.
Understanding stack policy syntax and effect on update actions (Update:Modify, Update:Replace, Update:Delete).
Recognizing that stack policies do not prevent manual changes outside CloudFormation.
Knowing that stack policies only apply during stack updates, not creation or deletion.
Understanding that a temporary policy can override the existing stack policy during an update.
Most Common Wrong Answers and Why Candidates Choose Them
"Drift detection automatically reverts changes." Many candidates assume that detecting drift will automatically fix the drift. In reality, drift detection only reports the drift; you must manually remediate.
"Stack policies prevent manual changes via the console." Since stack policies only apply to CloudFormation updates, manual changes via the console or CLI are not blocked. Candidates often confuse stack policies with IAM policies or SCPs.
"A stack policy with Deny on Update:Delete prevents stack deletion." Stack policies only affect resource updates, not stack deletion. To prevent stack deletion, you need a stack deletion protection policy (e.g., a termination protection stack attribute).
"Drift detection works on all CloudFormation resources." Not all resources or properties are supported. For example, the Code property of a Lambda function is not checked.
Specific Numbers, Values, and Terms That Appear on the Exam
Drift status values: IN_SYNC, MODIFIED, DELETED, NOT_CHECKED.
Stack drift status: DRIFTED, IN_SYNC, NOT_CHECKED, UNKNOWN.
Maximum simultaneous drift detection operations: 20 per account per region.
Stack policy maximum size: 4,096 bytes.
Stack policy actions: Update:Modify, Update:Replace, Update:Delete.
API calls: DetectStackDrift, DescribeStackResourceDrifts, SetStackPolicy, GetStackPolicy.
Edge Cases and Exceptions
If a resource is deleted outside CloudFormation and you run drift detection, the resource will show as DELETED. However, the stack still expects the resource to exist. To fix this, you must update the template to remove the resource or import a new resource.
Stack policies can be overridden during an update by specifying a stack-policy-during-update-body parameter. This is useful for emergency updates but should be used with caution.
Drift detection does not check properties that are not supported. Always check the AWS documentation for the list of supported resource types and properties.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If a question mentions preventing accidental changes during a CloudFormation update, think stack policy.
If a question mentions detecting changes made outside CloudFormation, think drift detection.
If a question mentions automatically fixing drift, the answer is likely wrong because drift detection is passive.
If a question mentions blocking console changes, the answer is likely wrong because stack policies only block CloudFormation updates.
Drift detection identifies resource changes made outside CloudFormation; it does not remediate them.
Stack policies only apply during stack updates, not during creation or deletion.
Drift status values: IN_SYNC, MODIFIED, DELETED, NOT_CHECKED.
Stack policy actions: Update:Modify, Update:Replace, Update:Delete.
Maximum drift detection operations: 20 simultaneous per account per region.
Stack policy maximum size: 4,096 bytes.
Stack policies do not prevent manual changes via the console or CLI.
A temporary stack policy can override the existing policy during a stack update.
These come up on the exam all the time. Here's how to tell them apart.
Drift Detection
Detects changes made outside of CloudFormation.
Reports drift status at resource and stack level.
Does not prevent changes, only reports them.
Supported for most but not all resource properties.
Initiated via API or Console; no automatic remediation.
Stack Policies
Controls allowed update actions during CloudFormation updates.
Uses JSON policy statements with Allow/Deny effects.
Prevents specified update actions (Modify, Replace, Delete).
Applies to all resources or specific logical IDs.
Can be overridden with a temporary policy during an update.
Mistake
Drift detection automatically fixes any differences it finds.
Correct
Drift detection only reports differences; it does not automatically remediate them. You must manually update the stack or revert the manual changes to bring the stack back into sync.
Mistake
Stack policies prevent all changes to resources, including manual changes via the console.
Correct
Stack policies only apply during CloudFormation stack updates. They do not block changes made directly via the AWS Console, CLI, or SDKs outside of a CloudFormation update.
Mistake
If a stack policy denies Update:Delete, the stack cannot be deleted.
Correct
Stack policies only affect resource updates within a stack. Stack deletion is controlled by the `DeletionPolicy` attribute or termination protection on the stack itself, not by stack policies.
Mistake
Drift detection checks all properties of all resources.
Correct
Not all resource types or properties are supported for drift detection. For example, the `Code` property of a Lambda function is not checked. Always verify the supported list in the AWS documentation.
Mistake
You can only set a stack policy during stack creation.
Correct
You can set or update a stack policy on an existing stack at any time using the `SetStackPolicy` API or the `update-stack` command with the `--stack-policy-body` parameter.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can detect drift using the AWS Management Console (select the stack, then 'Detect drift'), AWS CLI (`aws cloudformation detect-stack-drift --stack-name my-stack`), or AWS SDK. The operation returns a detection ID that you can use to track progress. After completion, use `describe-stack-resource-drifts` to view detailed results.
No, stack policies only control updates to resources within a stack, not the stack itself. To prevent stack deletion, enable termination protection on the stack (via the console or `EnableTerminationProtection` API). Deletion of a stack is governed by the `DeletionPolicy` attribute on resources and the stack's termination protection setting.
The entire stack update will fail. CloudFormation evaluates the stack policy before making any changes. If any resource update is denied, the operation is rolled back, and no resources are modified. The error message will indicate which resource was denied and the reason.
Yes, drift detection can be performed on a nested stack as a whole. When you detect drift on a parent stack, CloudFormation also detects drift on the nested stacks. However, drift detection does not automatically recurse into the nested stack's resources; you must detect drift on the nested stack separately to get its detailed drift status.
Yes, you can create a policy that explicitly allows certain actions on certain resources while denying all others. For example, you can allow `Update:Modify` on a database but deny `Update:Replace` and `Update:Delete`. The default effect is Allow, so you must explicitly Deny actions you want to block.
You can specify a temporary stack policy during the update using the `--stack-policy-during-update-body` parameter. This temporary policy overrides the existing policy for that update only. After the update, the original policy remains in effect for future updates.
Most AWS resource types support drift detection, but some properties are not checked. For example, `AWS::Lambda::Function` checks `Handler`, `Runtime`, `MemorySize`, but not `Code`. Always refer to the AWS documentation for the complete list of supported resource types and properties.
You've just covered CloudFormation Drift Detection and Stack Policies — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?