Create container availability alert rules and grant the Prometheus service principal SNS publish on the topic

Answer Correct answer: B, C, D — create container availability alert rules, an alert manager configuration for SNS, and grant aps.amazonaws.com publish on the topic.

A company has deployed a complex container-based workload on AWS. The workload uses Amazon Managed Service for Prometheus for monitoring. The workload runs in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster in an AWS account. The company’s DevOps team wants to receive workload alerts by using the company’s Amazon Simple Notification Service (Amazon SNS) topic. The SNS topic is in the same AWS account as the EKS cluster. Which combination of steps will meet these requirements? (Choose three.)

  1. Use the Amazon Managed Service for Prometheus remote write URL to send alerts to the SNS topic
  2. Create an alerting rule that checks the availability of each of the workload’s containers. Correct Answer
  3. Create an alert manager configuration for the SNS topic. Correct Answer
  4. Modify the access policy of the SNS topic. Grant the aps.amazonaws.com service principal the sns:Publish permission and the sns:GetTopicAttributes permission for the SNS topic. Correct Answer
  5. Modify the IAM role that Amazon Managed Service for Prometheus uses. Grant the role the sns:Publish permission and the sns:GetTopicAttributes permission for the SNS topic.

Community Votes

BCD
80%
BCE
20%

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

Community Insight

Alerting requires both an alert rule that fires on container availability and an alert manager configuration pointing at the SNS receiver (B, C). Delivery then fails without resource-based authorization, which is why the SNS topic access policy must grant the aps.amazonaws.com service principal sns:Publish and sns:GetTopicAttributes (D). Option E misplaces the grant on the Prometheus service role's IAM policy, which does not authorize publishing to the topic. Option A is invalid because Managed Service for Prometheus has no remote-write mechanism aimed at SNS.

To route Amazon Managed Service for Prometheus alerts to the company's SNS topic, define an alerting rule for each workload container's availability, create an alert manager configuration that targets the SNS topic as the receiver, and amend the topic's access policy so the aps.amazonaws.com service principal is allowed sns:Publish and sns:GetTopicAttributes. The permissions belong on the SNS topic resource policy because Managed Service for Prometheus delivers alerts on the company's behalf using its service principal.

Using the Managed Service for Prometheus remote write URL to send alerts to the SNS topic (A)—remote write targets Prometheus-compatible endpoints, not SNS, so this does not deliver alerts. Granting sns:Publish on the Managed Service for Prometheus IAM role instead of the topic policy (E)—the service assumes that role for its own operations, not as a principal publishing to your SNS topic, so the authorization must be a resource-based policy on the topic granting the aps service principal.

Community Discussion (31 comments)

xdkonorek2 👍 5 Selected: BCD
https://docs.aws.amazon.com/prometheus/latest/userguide/Troubleshooting-alerting-no-policy.html
Gomer 👍 5 Selected: BCD
B:(YES) Steps towards "configuring rules and the alert manager in Amazon Managed Service for Prometheus via the AWS management console." "define an alerting rule that causes the Alert Manager to send a notification if a certain condition (defined in expr) holds true for a specified time period (for)." cat << EOF > rules.yaml groups: [...] rules: - alert: metric:alerting_rule expr: rate(adot_test_counter0[5m]) > 0.014 for: 5m EOF C:(YES) Add "SNS receiver to" "alert manager configuration" using ARN of "SNS topic"(Q208.5) D:(YES) "Give Amazon Managed Service for Prometheus permission to send messages to" SNS "Choose Access policy and add the following policy statement to the existing policy." [...] "Principal": { "Service": "aps.amazonaws.com" }, "Action": [ "sns:Publish", "sns:GetTopicAttributes"
teo2157 👍 2 Selected: BCD
https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-receiver.html
seetpt 👍 1
I think BCD is true
jamesf 👍 4 Selected: BCD
BCD For D as You must give Amazon Managed Service for Prometheus permission to send messages to your Amazon SNS topic. The following policy statement will give that permission. ... https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-receiver-AMPpermission.html
trungtd 👍 4 Selected: BCD
Agree with BCD
KaranNishad 👍 4 Selected: BCD
BCD is answer
that1guy 👍 5 Selected: BCD
B, C, D, you need to grant the AMP Workspace access to the SQS queue via the SQS resource policy.
seetpt 👍 1 Selected: BCE
BCE for me
c3518fc 👍 2 Selected: BCE
Amazon Managed Service for Prometheus uses an IAM role to assume permissions, not a service principal. https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-IAM-permissions.html
dkp 👍 5 Selected: BCD
ill go with bcd
WhyIronMan 👍 5 Selected: BCD
B,C,D. There is no way to exclude D, as it is really necessary as per all AWS documentations. You can be in doubt of all the others, but not D
CloudHandsOn 👍 4 Selected: BCE
I'll go with BC & E. Im convinced that the Prometheus service role will need permissions added to push messages to SNS topic
ogerber 👍 2 Selected: BCE
https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alert-manager.html
L1_ 👍 3 Selected: BCD
B: https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-APIReference-CreateAlertManagerAlerts.html C: https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-receiver-AMPpermission.html D: https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-receiver-AMPpermission.html
DanShone 👍 4 Selected: BCD
BCD Makes the most sense from the docs https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-receiver-AMPpermission.html
Shasha1 👍 1
BCD According to this reference D is for sure : https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-receiver-AMPpermission.html
fdoxxx 👍 1 Selected: ADE
Use the Amazon Managed Service for Prometheus remote write URL: You can configure Prometheus to send alerts to an external service, such as an SNS topic, by using the remote write URL. This URL can be obtained from Amazon Managed Service for Prometheus. Modify the access policy of the SNS topic: Grant the aps.amazonaws.com service principal the necessary permissions (sns:Publish and sns:GetTopicAttributes) to publish to the SNS topic and get its attributes. This allows Amazon Managed Service for Prometheus to interact with the SNS topic. Modify the IAM role that Amazon Managed Service for Prometheus uses: Grant the IAM role associated with Amazon Managed Service for Prometheus the necessary permissions (sns:Publish and sns:GetTopicAttributes) to interact with the SNS topic. Options B, C, and F are not directly related to integrating Amazon Managed Service for Prometheus with Amazon SNS
Jonalb 👍 1 Selected: BC
B. Create an alerting rule that checks the availability of each of the workload’s containers. C/F. Given the options and AWS services' functionalities, a direct integration approach as described is not straightforward. However, understanding the need for configuration and permission settings, a combination of creating alerting rules (B) and configuring permissions correctly either through IAM roles or service accounts (F) seems most relevant. Implementing a custom solution or using third-party tools that can act as an intermediary might be necessary. F. Create an OpenID Connect (OIDC) provider for the EKS cluster and configure permissions appropriately, which is a fundamental step in setting up Kubernetes services to interact with AWS services securely.
Jonalb 👍 1
Answer:BCF
Diego1414 👍 1 Selected: BCD
Answer: BCD – Create Alert manager, create alert rule, modify access policy https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alertmanager-receiver-AMPpermission.html
testhard 👍 2 Selected: BCE
Is related to Prometheus permission, not EKS, you need to give access to AMP send messages to SNS
kyuhuck 👍 1 Selected: BC
Amazon Managed Service for Prometheus primarily deals with metrics collection and querying. Alerting is managed by the Alertmanager, which does not use the Prometheus service’s IAM role for sending alerts to SNS. The configuration for notifications is managed within Alertmanager itself and may require custom integration for SNS. Therefore, the correct steps are B, C, and F to set up alerting from Amazon Managed Service for Prometheus to an Amazon SNS topic, with proper monitoring, alert management configuration, and permissions setup for integration.
kyuhuck 👍 1 Selected: BC
In summary, the best approach involves defining alerting rules within Prometheus (B), potentially customizing Alertmanager or using an intermediary service for integration with SNS (C, but with the note that direct SNS configuration requires custom setup), and securely configuring permissions for Kubernetes workloads to interact with AWS services (F), acknowledging that some of the steps might involve additional customization or tools beyond the default capabilities of the mentioned AWS services.
Ramdi1 👍 1 Selected: CDE
D & E: These steps are essential for enabling communication between Prometheus and SNS. Modifying the SNS topic policy allows the specific service principal and IAM role to publish and get attributes, respectively. C: An alert manager configuration is crucial for routing Prometheus alerts to the desired destination (SNS topic in this case). It defines how and where to send alerts based on specific criteria.
thanhnv142 👍 2 Selected: BCE
BCE are correct: A: There is nothing called Amazon Managed Service for Prometheus remote write URL B: ok C: ok. Both B and C mention creating alert D: irrelevant E: Granting permissions for Prometheus F: irrelevant
vortegon 👍 4 Selected: BCD
Options B (Create an alerting rule), C (Create an alert manager configuration for the SNS topic), and D (Modify the access policy of the SNS topic) are the correct choices. These steps ensure that alerting rules are in place, Alertmanager is configured to route alerts to SNS, and the necessary permissions are set for AMP to publish alerts to the SNS topic.
LeoSantos121212121212121 👍 1
I go with BDE.
Chelseajcole 👍 1
BDE? Why need OIDC?
Arnaud92 👍 1 Selected: ADE
Option A is necessary to configure Amazon Managed Service for Prometheus to send alerts to the specified destination, which in this case is the SNS topic. Option D is necessary to ensure that the SNS topic allows the Amazon Managed Service for Prometheus service principal to publish messages to the topic. Option E is necessary to grant the required permissions to the IAM role used by Amazon Managed Service for Prometheus to interact with the SNS topic. Options B, C, and F are not directly related to integrating Amazon Managed Service for Prometheus alerts with Amazon SNS for the given scenario.
Spavanko 👍 1 Selected: BD
I think different

Comments & Corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

An alerting rule must exist for each workload container so that the Managed Service for Prometheus Alertmanager evaluates availability and fires (B). An alert manager configuration then defines SNS as the receiver that delivers those fired alerts (C). Because the alerts are published to a topic the company owns, the topic's resource-based policy must authorize the publishing principal: granting the aps.amazonaws.com service principal sns:Publish and sns:GetTopicAttributes allows Managed Service for Prometheus to deliver alerts to the topic (D), which is exactly the configuration the AWS troubleshooting documentation describes.

Why the Other Options Are Wrong

A proposes sending alerts to the SNS topic through the Managed Service for Prometheus remote write URL. Remote write is for pushing samples to Prometheus-compatible backends and cannot target SNS, so alerts would never arrive. E proposes granting sns:Publish and sns:GetTopicAttributes on the IAM role used by Managed Service for Prometheus, but that role authorizes the service's own service-side operations rather than acting as a principal publishing to your SNS topic; the required grant is a resource policy on the topic naming the aps service principal. B, C, and D are the correct combination.

Community Comment Notes

Community voted B,C,D (73), with B,C,E an 18 percent minority. Commenters linked both the AWS troubleshooting page for missing alerting policies and the Alertmanager receiver documentation, and jamesf quoted the documented policy statement that gives Managed Service for Prometheus permission to send messages to the SNS topic.

Official Reference

Related Analysis

Practice All DOP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full DOP-C02 Practice Test →

← Back to DOP-C02 Study Guide