How to notify the QA team on new AWS CloudFormation deployments in a specific environment?

A company wants to test its web application more frequently. The company deploys the application by using a separate AWS CloudFormation stack for each environment. The company deploys the same CloudFormation template to each stack as the application progresses through the development lifecycle. A developer needs to build in notifications for the quality assurance (QA) team. The developer wants the notifications to occur for new deployments in the final preproduction environment. Which solution will meet these requirements?

Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the QA team to the Amazon SNS topic. Update the CloudFormation stack options to point to the SNS topic in the pre-production environment. Source Reference Answer
Create an AWS Lambda function that notifies the QA team. Create an Amazon EventBridge rule to invoke the Lambda function on the default event bus. Filter the events on the CloudFormation service and on the CloudFormation stack Amazon Resource Name (ARN).
Create an Amazon CloudWatch alarm that monitors the metrics from CloudFormation. Filter the metrics on the stack name and the stack status. Configure the CloudWatch alarm to notify the QA team.
Create an AWS Lambda function that notifies the QA team. Configure the event source mapping to receive events from CloudFormation. Specify the filtering values to limit invocations to the desired CloudFormation stack.

Community Votes

67%

33%

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

Community Insight

The question really tests whether candidates know that CloudFormation has a built-in SNS notification configuration per stack, and that this is the simplest, purpose-built mechanism for stack-event alerts.

This question tests the most direct way to receive notifications when an AWS CloudFormation stack changes status in a specific environment. Community consensus favors configuring CloudFormation stack-level SNS notifications for the target pre-production stack.

Many candidates choose the EventBridge + Lambda option because it sounds more 'modern' and flexible, but it is over-engineered for a simple stack-event notification requirement and requires extra configuration beyond what the question asks.

Community Discussion (6 comments)

albert_kuo 👍 1 Selected: B

B is the correct answer. Here's why: It uses EventBridge to capture CloudFormation stack events. It allows filtering based on the CloudFormation service and the specific stack ARN, which can be used to identify the pre-production environment. The Lambda function can be customized to send notifications to the QA team in any desired format (email, Slack, etc.). This setup will automatically trigger for new deployments in the specified environment.

65703c1 👍 2 Selected: A

A is the correct answer.

ethanluvsbooks 👍 3

Answer: A So I was also confused about this. But you can add an SNS topic to cloud formation: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-sns-topic.html (The AWS::SNS::Topic resource creates a topic to which notifications can be published.) https://stackoverflow.com/questions/34792724/adding-cloudformation-stack-events-to-sns

SerialiDr 👍 4 Selected: A

A. This option involves creating an SNS topic to which the QA team subscribes. CloudFormation can indeed integrate with SNS to send notifications about stack events, making this a viable way to notify the QA team of deployment updates specifically in the pre-production environment if the CloudFormation stack in that environment is configured to publish events to this SNS topic. Based on these considerations, options A and B are the most directly relevant and practical solutions for the given requirements, with option A (SNS topic for direct CloudFormation notifications) being the most straightforward to implement for notifying the QA team of new deployments in the pre-production environment, and option B (Lambda and EventBridge) offering a more customizable solution that can filter and handle notifications based on specific criteria related to CloudFormation events.

KarBiswa 👍 3 Selected: B

https://aws.amazon.com/about-aws/whats-new/2022/07/aws-cloudformation-event-notifications-amazon-eventbridge-event-driven-applications/

CrescentShared 👍 2 Selected: A

A is correct.

Comments & Corrections

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

Expert Analysis

Why Option A is Correct

Option A leverages a native, purpose-built feature of AWS CloudFormation: the ability to configure an Amazon SNS topic for stack notifications directly in the stack options. When you create or update a stack, you can specify an SNS topic ARN, and CloudFormation will publish messages for stack lifecycle events (CREATE, UPDATE, DELETE, and their statuses) to that topic.

Because the company already uses a separate CloudFormation stack per environment, the developer simply needs to:

1. Create an SNS topic and subscribe the QA team (e.g., via email or SMS). 2. In the pre-production stack's configuration, specify that SNS topic under Stack options → Notifications.

This directly satisfies the requirement: notifications are sent only for events in the final preproduction environment, because only that stack is configured with the SNS topic.

Why the Other Options Are Wrong

Option B (EventBridge + Lambda): While CloudFormation does emit events to EventBridge (since July 2022), this approach requires creating a Lambda function, an EventBridge rule, and filtering logic. It is a valid architectural pattern but is over-engineered for the stated requirement of simple notifications. The question asks for the solution that meets the requirements, and the simpler native SNS integration does so with less effort.

Option C (CloudWatch alarm): CloudFormation does not expose stack status as a standard CloudWatch metric that can be alarmed on in this way. CloudWatch alarms are designed for metric thresholds, not for discrete stack lifecycle events. This option is technically incorrect.

Option D (Lambda with event source mapping): Event source mappings are used for streaming services like Amazon Kinesis, DynamoDB Streams, or SQS — not for CloudFormation events. CloudFormation does not support this integration pattern, making this option invalid.

Community Consensus

The community is split (67% A, 33% B), but the majority correctly identifies that the native SNS notification feature of CloudFormation is the most direct and appropriate solution. Commenters point out that CloudFormation's stack options include a dedicated field for an SNS topic ARN, which is exactly what the scenario describes.

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