Troubleshooting Scenario Questions

Attach AdministratorAccess permanently to every developer role

Why wrong: Permanent broad access violates least privilege.

Create shared administrator access keys for the team

Why wrong: Shared long-term keys remove accountability and increase compromise risk.

Disable CloudTrail during troubleshooting

Why wrong: Disabling audit logging weakens accountability and investigation capability.

Subscribe each downstream directly with HTTPS endpoints and configure a single SNS dead-letter queue (DLQ) for the topic.

Why wrong: SNS topic-level DLQs are primarily for failed message delivery to the subscription endpoint (for example, publish/HTTP delivery failures). If the downstream receives the message successfully but later fails application processing, SNS may not detect it, so you cannot reliably isolate per-consumer processing failures and route them to a per-consumer DLQ.

Use one shared SQS queue for all three downstream systems and configure a single DLQ only when all three downstream systems fail.

Why wrong: A shared queue couples the workloads: if B cannot process messages, the queue backlog and retry behavior can affect how messages are consumed by A and C. Also, SQS DLQ redrive is based on per-message retry attempts, not on whether “all three downstream systems” succeeded or failed for that message.

Use EventBridge rules to invoke A, B, and C synchronously with retries enabled, and send failures to a common DLQ.

Why wrong: Synchronous invocation increases coupling and does not provide the same per-subscriber processing isolation pattern as SNS-to-per-subscriber SQS queues with SQS redrive policies. EventBridge retries and DLQs are not a direct substitute for per-consumer SQS DLQs driven by consumer processing failures.

Enable AWS Config delivery to a separate bucket and create a rule to detect noncompliant S3 policies; this will automatically generate GetObject logs.

Why wrong: AWS Config evaluates resource configuration and policy compliance, but it does not provide object-level access logs like GetObject and PutObject. The requirement is detective visibility into access and writes, not configuration drift detection. This approach would not fill the logging gap for exfiltration investigations.

Turn on VPC Flow Logs for the VPC hosting the S3 gateway endpoint, because network logs show S3 object read and write details.

Why wrong: VPC Flow Logs capture network traffic metadata (e.g., src/dst IPs and ports) but not S3 API actions at the object level. They cannot directly answer which objects were read from or written to within the bucket. The symptom is missing CloudTrail visibility into object-level operations, not network reachability.

Add an S3 bucket policy that denies all GetObject requests unless the caller uses TLS; the denial events will create investigation logs automatically.

Why wrong: A bucket policy denial will generate some logs, but it does not provide comprehensive object access visibility for legitimate reads and writes. Additionally, enforcement does not equal detective coverage; you may still miss successful access events. The question asks for configuration to provide missing object-level logs.

Disable CloudTrail during troubleshooting

Why wrong: Disabling audit logging weakens accountability and investigation capability.

Attach AdministratorAccess permanently to every developer role

Why wrong: Permanent broad access violates least privilege.

Create shared administrator access keys for the team

Why wrong: Shared long-term keys remove accountability and increase compromise risk.

Enable KMS automatic key rotation for the customer-managed key in account B.

Why wrong: Key rotation is unrelated to authorization failures. The problem is that the key policy in account B is not allowing the cross-account principal to use kms:Decrypt for the key.

Attach the key policy as an IAM permissions policy to the instance role in account A only; key policies are not evaluated cross-account.

Why wrong: KMS key policies are evaluated on the key itself. Without updating the key policy in account B, cross-account calls will still be denied even if IAM permissions exist in account A.

Disable encryption on the EBS volume until authorization is fixed, then re-enable encryption after mount.

Why wrong: Disabling encryption violates security requirements and does not address why KMS authorization fails. Encrypted volumes and snapshots require correct KMS policies to be usable.

Keep the bastion host but move it into a private subnet; engineers can connect by using a corporate VPN into the VPC.

Why wrong: A bastion host remains a high-value target and still requires controlled network access. Even if the bastion is private, inbound connectivity and SSH exposure remain. Session Manager provides a more direct elimination of the bastion as well as auditability.

Attach a public IP to each private instance so engineers can SSH directly and use security groups to restrict access.

Why wrong: Public IPs for instances in private subnets defeat the private-subnet isolation and increase attack surface. While security groups could limit access, it’s still direct internet exposure rather than brokered, permissioned management via AWS SSM.

Create a security group rule that allows engineers’ source IP addresses to reach instances over RDP on port 3389.

Why wrong: Allowing RDP with IP-based controls still requires a management network path and does not remove exposure. It also doesn’t align with using AWS SSO-based authentication for secure access auditing and operational workflows.