Build reusable infrastructure components with the AWS Cloud Development Kit, CloudFormation modules and the AWS Serverless Application Model.

A team defines a serverless API using plain CloudFormation. Each endpoint requires an AWS::Lambda::Function, an AWS::IAM::Role, an AWS::Logs::LogGroup, and several AWS::ApiGateway resources, so the template has grown long and error-prone, and engineers frequently misconfigure the IAM role and log retention. They want a template authoring model where a single resource declares the function and wires its API event, permissions and logging, while still producing standard CloudFormation under the hood. Which change BEST reduces this boilerplate?

• AKeep the raw CloudFormation resources but move the IAM role and log group into a nested stack so the main template is shorter, referencing them from each function through cross-stack outputs.
• BReplace the inline resources with a CloudFormation macro the team writes to generate the function and its dependencies, registering the macro so each template calls it for every endpoint.
• CAdopt the AWS Serverless Application Model transform and declare each endpoint as an AWS::Serverless::Function with an Api event, letting the transform expand it into the underlying function, role, permissions and API resources.check_circle Correct
• DContinue using the existing resources but add a CloudFormation parameter for log retention and a managed policy reference for the role, so the misconfigured values are supplied consistently across endpoints.

Why A is wrong: A nested stack hides some lines behind a separate template but each endpoint still declares the full function, role, log group and API resources by hand, so the misconfiguration and boilerplate the team wants to remove remain.

Why B is wrong: A self-written macro could expand the resources but it puts the burden of authoring and maintaining a Lambda-backed transform on the team, whereas the managed serverless transform already provides this expansion.

Why C is correct: The AWS Serverless Application Model transform lets one AWS::Serverless::Function resource declare the function plus its API event and generate the role, permissions and API plumbing as standard CloudFormation, removing the hand-written boilerplate the team struggles with.

Why D is wrong: Parameters and a shared policy standardise specific values but every endpoint still declares all four resource types explicitly, so the lengthy error-prone template the team wants to simplify is unchanged.