A CloudFormation stack is deployed through a dedicated deployment role and fails repeatedly during creation, rolling back each time. The stack events show two distinct blocking errors before rollback: the deployment principal is not authorised to perform iam:PassRole when attaching a new execution role to a Lambda function, and the Auto Scaling group cannot launch because the target /28 subnet defined in the template has insufficient free addresses for the desired fleet size. The team must let the same workload deploy successfully while changing as little as possible. Which two actions together resolve the stack creation failure? (Select TWO.)
- AAdd an iam:PassRole permission for the Lambda execution role's ARN to the deployment role's policy so it may hand that role to the Lambda service. Correct
- BWiden the subnet to a larger CIDR such as /24 in the template so the subnet has enough usable host addresses for the Auto Scaling group to launch. Correct
- CAttach the AdministratorAccess managed policy to each EC2 instance profile so the instances can create the remaining stack resources during boot.
- DSet the stack's OnFailure option to DO_NOTHING so the failed resources are preserved for inspection instead of rolling back.
- ERun drift detection on the stack and import the drifted resources so the template matches the live configuration before retrying.
Why A is correct: The PassRole denial blocks role attachment, and granting iam:PassRole scoped to the execution role on the deployment principal removes that specific authorisation failure.
Why B is correct: The /28 yields only eleven usable addresses after reservations, so enlarging the subnet CIDR removes the insufficient free addresses error and lets the fleet launch.
Why C is wrong: It is tempting because broad permissions seem to fix authorisation errors, but instance profiles do not perform stack provisioning and this addresses neither the PassRole nor the address-space failure.
Why D is wrong: Preserving failed resources only aids debugging and is tempting after repeated rollbacks, but it leaves both the permissions and subnet sizing faults unfixed so creation still fails.
Why E is wrong: Drift detection sounds relevant to CloudFormation troubleshooting, but it compares an existing stack to its template and cannot run on a stack that never finished creating, so it fixes neither error.