Using AWS Control Tower management account and CloudFormation StackSets, a DevOps engineer must enable Amazon GuardDuty for accounts that have not already enabled it. To avoid StackSets deployment failures, how should the CloudFormation template be designed?

The correct approach is to use a CloudFormation custom resource with a Lambda function. This allows for dynamic logic during deployment. The Lambda function can programmatically check if GuardDuty is already enabled in a given account using the AWS SDK. If GuardDuty is not enabled, the Lambda can then enable it. This prevents StackSet deployment failures that would occur if the template tried to enable GuardDuty in an account where it's already active, as GuardDuty's CreateDetector API call is idempotent only if the detector already exists and its status is ENABLED. Incorrect options: CloudFormation's Conditions section evaluates static parameters or pseudo parameters at the start of deployment and cannot dynamically query the state of a service in an account. Fn::GetAtt retrieves attributes of resources created by the CloudFormation stack and cannot be used to query the state of existing services outside the stack's direct management. Manually assembling a list is not scalable or automated, defeating the purpose of StackSets for managing multiple accounts. Fn::ImportValue is for importing values exported by other stacks, not for dynamic account filtering.