How should the DevOps engineer configure the CloudFormation template to prevent failure during the StackSets deployment?
Create a CloudFormation custom resource that invokes an AWS Lambda function. Configure the Lambda function to conditionally enable GuardDuty if GuardDuty is not already enabled in the accounts.
Use the Conditions section of the CloudFormation template to enable GuardDuty in accounts where GuardDuty is not already enabled.
Use the CloudFormation Fn::GetAtt intrinsic function to check whether GuardDuty is already enabled. If GuardDuty is not already enabled, use the Resources section of the CloudFormation template to enable GuardDuty.
Manually discover the list of AWS account IDs where GuardDuty is not enabled. Use the CloudFormation Fn::ImportValue intrinsic function to import the list of account IDs into the CloudFormation template to skip deployment for the listed AWS accounts.
Explanations:
Using a CloudFormation custom resource with a Lambda function allows conditional logic to check if GuardDuty is enabled. The Lambda function can check GuardDuty’s status and enable it only if needed, avoiding deployment failures in accounts where it is already enabled.
CloudFormation’s Conditions section does not natively support checking external states like whether a service is enabled. It cannot conditionally enable GuardDuty based on its current status across multiple accounts.
The Fn::GetAtt intrinsic function is not capable of querying GuardDuty’s status because it can only retrieve attributes from resources created within the same template, not external statuses like GuardDuty’s state in each account.
Manually discovering and importing account IDs is impractical, especially at scale, and would require frequent updates to keep the list accurate. It also does not prevent deployment failures if GuardDuty is enabled in new accounts that are not on the list.