You publish to an Amazon SNS topic and the call succeeds, but the subscribed SQS queue in another AWS account never receives anything. Which permission and configuration layers do you check, and in what order?

## Why a successful publish proves so little SNS accepts a message the moment the caller is authorised on the topic. Delivery to subscribers happens afterwards, asynchronously, on SNS's own credentials as a service principal — a completely separate authorisation decision that the publisher never sees. So "publish returns a MessageId" and "the queue is empty" are entirely compatible, and every layer between them is a suspect. ## The layers, outward from the publisher **1. The publisher's identity policy.** Does the role have `sns:Publish` on that topic ARN? If not you would see `AuthorizationError` — so a successful publish already clears this one. **2. The topic access policy.** A resource policy on the topic controls who may publish and subscribe, and for cross-account work it is where the other account is granted `sns:Subscribe`. When an AWS service publishes to the topic — S3 event notifications, a CloudWatch alarm, EventBridge — the topic policy must allow that service principal, usually with a condition on `aws:SourceArn` (and `aws:SourceAccount`) to prevent the confused-deputy problem where another customer's bucket points at your topic. **3. The subscription itself.** Two states bite here. A subscription can sit in `PendingConfirmation` — always true for HTTPS until the endpoint echoes the token, and possible cross-account when the subscribe call was made by a principal that does not own the destination. And a **filter policy** silently drops non-matching messages: if the publisher stopped setting an attribute, or sends a number as a string, the subscriber receives nothing and nothing errors. Compare `NumberOfNotificationsFilteredOut` with `NumberOfMessagesPublished` to rule this in or out in seconds. **4. The destination resource policy.** This is the most common actual cause. The SQS queue must have a policy statement allowing the SNS service principal to `sqs:SendMessage` on that queue, conditioned on `aws:SourceArn` matching the topic: ```json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "sns.amazonaws.com"}, "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:eu-west-1:444455556666:orders-billing", "Condition": {"ArnEquals": {"aws:SourceArn": "arn:aws:sns:eu-west-1:111122223333:orders"}} }] } ``` Creating the subscription does **not** create this grant unless a console wizard or IaC module wrote it for you. Cross-account, the queue owner must add it, because a resource policy can only be written by the resource's own account. **5. Encryption.** If the queue uses server-side encryption with a customer managed KMS key, that key's policy must allow the SNS service principal `kms:GenerateDataKey*` and `kms:Decrypt`. And the trap worth knowing cold: a queue encrypted with the **AWS managed key for SQS cannot receive SNS deliveries**, because you cannot modify that key's policy to add SNS. The symptom is exactly this question's symptom — publishes succeed, the queue stays empty. The same applies in reverse for an encrypted topic whose publishers need key access. **6. Organisation-level controls.** In a multi-account estate, a service control policy or a VPC endpoint policy can deny an action that both the identity and resource policies allow. An explicit deny anywhere wins, and an SCP that does not allow the action is equivalent to a deny for principals in that account. ## Making the diagnosis fast Rather than reading five policies in order, read the metrics first and let them point at a layer: - `NumberOfMessagesPublished` high, `NumberOfNotificationsFilteredOut` equally high → filter policy. - `NumberOfNotificationsFailed` climbing → the destination is refusing; it is the queue policy or KMS. - `NumberOfNotificationsDelivered` healthy but the consumer sees nothing → not a delivery problem at all; look at the consumer, or at a second subscription pointing at a different queue. - Subscription ARN literally reads `PendingConfirmation` → nothing was ever delivered. Delivery-status logging on the topic gives per-delivery outcomes in CloudWatch Logs and is the fastest way to see the actual refusal, while CloudTrail shows the `Subscribe` and `SetQueueAttributes` history when someone changed something. ## The habit to demonstrate The reason this question separates candidates is that it rewards a model of AWS authorisation rather than a memorised fix: **identity policy, resource policy, and service-to-service access are three different decisions, and the middle one belongs to whoever owns the destination.** Say that, then walk the layers, and the answer writes itself.