How to Pass a CloudFormation Log Group Name to an AWS Lambda Function?

A developer is creating a serverless application that uses an AWS Lambda function. The developer will use AWS CloudFormation to deploy the application. The application will write logs to Amazon CloudWatch Logs. The developer has created a log group in a CloudFormation template for the application to use. The developer needs to modify the CloudFormation template to make the name of the log group available to the application at runtime. Which solution will meet this requirement?

Use the AWS::Include transform in CloudFormation to provide the log group's name to the application.
Pass the log group's name to the application in the user data section of the CloudFormation template.
Use the CloudFormation template's Mappings section to specify the log group's name for the application.
Pass the log group's Amazon Resource Name (ARN) as an environment variable to the Lambda function. Source Reference Answer

Community Votes

100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests your ability to wire CloudFormation resource attributes to Lambda runtime configuration; the trap is choosing template-level features like Mappings or AWS::Include that do not directly expose runtime values.

Learn the correct way to pass a CloudFormation-created log group resource to an AWS Lambda function at runtime. The community agrees that an environment variable referencing the log group's ARN is the best solution.

Choosing option C (Mappings) or option A (AWS::Include) because they seem like CloudFormation-based ways to share values; however, they do not provide a direct, automated reference to a resource's dynamically generated ARN.

Community Discussion (6 comments)

albert_kuo 👍 1 Selected: D

Resources: MyLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${AWS::StackName}-log-group" MyLambdaFunction: Type: AWS::Lambda::Function Properties: FunctionName: MyFunction Handler: index.handler Runtime: nodejs14.x Role: arn:aws:iam::123456789012:role/service-role/MyLambdaRole Environment: Variables: LOG_GROUP_ARN: !GetAtt MyLogGroup.Arn

65703c1 👍 2 Selected: D

D is the correct answer.

Abdullah22 👍 4 Selected: D

Explanation of why other options are less suitable: A. AWS::Include transform: While the AWS::Include transform allows importing values from other templates, it's generally used for larger configurations and not ideal for this specific purpose of passing a single value to the application. B. User data: The user data section in CloudFormation is typically used for one-time configuration scripts and not intended for passing sensitive information like log group names or ARNs, raising security concerns. C. CloudFormation Mappings: While mappings can store key-value pairs within the template, they are not directly accessible as environment variables within the application code.

SerialiDr 👍 2 Selected: D

By specifying the log group's ARN as an environment variable in the CloudFormation template for the Lambda function, the developer can easily access this information within the application code at runtime. This method provides a straightforward way to pass dynamic configuration or resource references to AWS Lambda functions without hardcoding values, thereby maintaining flexibility and ensuring that the application can utilize the correct resources after deployment.

KarBiswa 👍 1 Selected: D

Very nice question totally confusing. D is correct

CrescentShared 👍 4 Selected: D

User data is typically used to pass startup scripts to EC2 instances, not Lambda functions. This would not be the appropriate mechanism for a serverless application using Lambda. The Mappings section in a CloudFormation template is used to define sets of key-value pairs that can be used to specify conditional parameter values based on region or other criteria. It doesn't provide a direct way to make the log group's name available to the Lambda function at runtime.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Option D is correct because Lambda functions can read environment variables at runtime, and CloudFormation can dynamically generate the log group's ARN using the !GetAtt intrinsic function. This approach is simple, maintainable, and follows AWS best practices for passing resource references into application code. The environment variable is resolved at stack deployment time, so the Lambda function has the correct ARN without hardcoding.

Why the Other Options Are Wrong

Option A (AWS::Include transform) is used for template modularization and does not pass runtime values to an application. Option B (user data) is intended for EC2 instance bootstrap scripts, not Lambda functions. Option C (Mappings) is for static key-value pairs and cannot reference a resource that is created in the same template, nor does it automatically update if the resource is replaced.

Community Comment Notes

Comment [3] correctly explains that specifying the ARN as an environment variable provides a flexible way to pass dynamic resource references without hardcoding. Comment [4] provides a concrete example using !GetAtt MyLogGroup.Arn, which is exactly how this is implemented in practice. Comment [1] and [2] detail why the other options are unsuitable for serverless Lambda-based applications.

Official Reference

Exam Strategy

Look for the option that uses an environment variable to pass a resource ARN, especially when the question mentions "at runtime" and involves Lambda. Remember that CloudFormation intrinsic functions like !GetAtt are the standard way to expose resource attributes, not Mappings or transforms.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide