Troubleshooting Scenario Questions

Disable CloudWatch Logs entirely and rely on application local files for 90 days.

Why it fails: Local files are not a durable or centralized substitute for CloudWatch Logs. This would increase operational risk, make retention harder to enforce, and reduce the team’s ability to search and audit logs across the fleet.

Increase the number of CloudWatch alarms so that metrics are collected less expensively.

Why it fails: Adding more CloudWatch alarms cannot lower metric collection costs because alarms are billed per alarm and simply evaluate the same underlying metric data. The recurring costs in the exhibit come from detailed monitoring (1-minute metrics) enabled on all 200 EC2 instances and from CloudWatch Logs retention set to indefinitely retain logs; neither of these charges is affected by the number of alarms. In fact, each standard alarm has its own monthly price, so increasing alarm count would increase the bill, not reduce it.

Export all logs to Amazon S3 immediately and keep detailed monitoring enabled on every instance.

Why it fails: Exporting logs to S3 can help with archival economics, but it does not reduce the detailed monitoring charge, which is one of the largest costs in the exhibit. Keeping detailed monitoring on every instance preserves the major recurring cost driver.

Keep the current long retention and detailed monitoring; reduce the log volume by sampling 10% of events

Why it fails: Sampling 10% of events would reduce log ingest and storage volume, but it discards 90% of log events. The compliance requirement explicitly states that the full log data must remain available in CloudWatch Logs for 90 days, so partial retention is not acceptable. Additionally, it leaves detailed EC2 monitoring enabled, so the per-instance metric costs from detailed monitoring remain unchanged. Thus this option fails both the compliance and the cost-reduction objectives.

Move all logs to S3 immediately and delete the CloudWatch log groups to reduce costs

Why it fails: Deleting the CloudWatch log groups would remove the logs from CloudWatch Logs before the required 90-day audit window. Even if data is exported to S3, this does not satisfy the stated compliance requirement that logs remain available in CloudWatch Logs for 90 days.

Increase CloudWatch alarm thresholds to reduce the number of metric datapoints

Why it fails: Increasing CloudWatch alarm thresholds only changes when an alarm enters an ALARM state; it does not alter how often CloudWatch collects or stores EC2 metrics. Metric collection frequency is determined by the monitoring mode: standard (5-minute) vs. detailed (1-minute), and both are billed per metric regardless of alarm settings. Since thresholds do not influence the number of datapoints ingested or the billing granularity, this change would have virtually no effect on the unexpected cost increase. It also risks masking real operational issues if alarms become too loose.

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

Why it fails: Automatic key rotation for a customer-managed KMS key only creates new backing keys for the same key material's version; it does not modify the key policy or alter how the key is authorized for cross-account use. The AccessDenied error stems from the key policy in account B lacking an explicit statement that permits the instance role from account A to call kms:Decrypt (and kms:CreateGrant). Since rotation adds no new principals or permissions, it cannot resolve the authorization failure, so the volume mount will still fail.

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 it fails: In cross-account KMS authorization, the key policy in the key-owning account is the resource-based policy that KMS evaluates, and it must explicitly include the external principal (e.g., the instance role's ARN or the root of account A). Simply attaching an IAM permissions policy to the instance role in account A does not update that key policy, so the request still fails because the default key policy in account B grants access only to the account root or internal principals. For a valid cross-account call, both the IAM policy in the using account and the key policy in the key-owning account must grant permission; one-sided authorization is insufficient.

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

Why it fails: EBS volume encryption cannot be disabled on an existing encrypted volume; you would have to create an unencrypted volume from a snapshot, which defeats the security requirement and still does not fix the KMS authorization denial. Even if you attempted to temporarily use an unencrypted volume, the root cause is that the key policy in account B does not allow the account A instance role to use the key. Bypassing encryption is a poor security practice and does not address the cross-account KMS policy misconfiguration; the correct fix is to update the key policy to grant kms:Decrypt and kms:CreateGrant to the instance role's principal.

Disable CloudTrail during troubleshooting

Why it fails: Disabling CloudTrail during troubleshooting removes the audit trail that records API calls, user identities, and resource changes, making root-cause analysis and security investigations impossible. CloudTrail is a detective control that should remain enabled precisely when issues arise, since its logs provide the timeline needed to correlate events and identify misconfigurations or unauthorized actions. Temporarily disabling it also leaves a gap in compliance evidence, undermining any later attempt to prove what occurred.

Attach AdministratorAccess permanently to every developer role

Why it fails: Permanently attaching AdministratorAccess to every developer role grants full, standing administrative privileges, which violates least privilege and drastically increases blast radius if a developer's credentials are compromised. Developers typically need only scoped permissions to specific services or resource tags, so broad access also masks misconfigurations and makes it harder to enforce separation of duties. This approach eliminates the need for temporary elevation but at the cost of persistent, unmonitored high-risk permissions across the entire team.

Create shared administrator access keys for the team

Why it fails: Creating shared administrator access keys for the team removes individual accountability because multiple developers can silently use the same credentials, making it impossible to determine who performed a destructive action. Long-term access keys are a primary target for exfiltration; if one is exposed, an attacker gains persistent administrative access, and rotating the key would disrupt every developer relying on it. This directly contradicts temporary access needs and auditing requirements, so it is both a security and an operational anti-pattern.

Disable CloudTrail during troubleshooting

Why it fails: Disabling CloudTrail during troubleshooting removes the audit log that records who made what API call and when, which cripples post-incident analysis and makes it impossible to prove a clean root cause. It also violates security best practices and many compliance frameworks (e.g., PCI-DSS, SOX) that mandate continuous logging, so even though it shortens noisy logs, it unacceptably degrades accountability and investigation capability.

Create shared administrator access keys for the team

Why it fails: Shared administrator access keys are long-term, static credentials that lack any identity attribution—everyone using them appears as the same principal, so you cannot determine which developer performed a destructive action or when a key leaked. Because the keys are never rotated and are shared, the blast radius is catastrophic if they are compromised, and there is no mechanism to enforce individual fine-grained permissions or revoke a single person's access, making this an unacceptable security practice.

Attach AdministratorAccess permanently to every developer role

Why it fails: Permanently attaching AdministratorAccess to every developer role grants complete, unchanging privileges regardless of task, which directly violates least privilege and creates standing high-risk permissions that expand the attack surface. Any developer or compromised session can immediately perform irreversible actions (e.g., deleting S3 buckets, modifying IAM policies) without additional controls, and because the access is permanent, there is no time bound or need-to-know check.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Enable AWS Config only for EC2 security groups and rely on it for API call auditing.

Why it fails: AWS Config for EC2 security groups records resource configuration changes and can evaluate rules, but it does not capture the API caller, source IP, or request ID. Even when a security group rule is modified, Config stores the updated configuration state, not the IAM principal or credential context that made the change. This makes it inadequate as a general API audit trail across IAM, KMS, or other services.

Turn on S3 server access logging for every bucket and assume it covers all AWS services.

Why it fails: S3 server access logging provides detailed records only for requests made to S3 buckets, such as the requester, bucket, key, and response status. It captures nothing about API activity in services like IAM, KMS, Secrets Manager, or EC2, so it cannot serve as an organization-wide audit trail. Additionally, S3 access logs are delivered on a best-effort basis and are often incomplete or delayed, which further undermines their reliability for investigations.

Use only Amazon CloudWatch alarms with no logging destination to reduce storage costs.

Why it fails: Amazon CloudWatch alarms monitor metric thresholds and trigger actions such as notifications or Auto Scaling, but they do not record the API request context needed to answer 'who did what and when.' Without a durable logging destination like CloudTrail or S3, the alarm's alert data is ephemeral and lacks the request parameters, user identity, and response details required for forensics. Relying only on alarms leaves you with no historical record of the actual API calls that caused the behavior.

An S3 lifecycle policy that deletes objects after 1 day to eliminate storage costs

Why it fails: Deleting after 1 day would remove data before it can be used for occasional troubleshooting. Storage cost optimization must still respect retention and troubleshooting requirements; lifecycle rules should transition to cheaper classes rather than delete immediately unless deletion is explicitly acceptable.

An S3 lifecycle policy that keeps all objects in S3 Standard and only applies compression at read time

Why it fails: Staying in S3 Standard does not address the cost driver (storage class pricing based on access frequency). “Compression at read time” is not an S3 lifecycle storage class optimization mechanism and would not directly lower S3 storage class charges as requested.

A policy that changes bucket encryption from SSE-S3 to SSE-KMS to reduce storage cost

Why it fails: Switching from SSE-S3 to SSE-KMS will not lower S3 storage costs; in fact, it typically increases them because AWS KMS incurs per-request charges for encrypt and decrypt operations and a monthly key fee. S3 storage class pricing is determined by the amount of data stored and the access/retrieval rates, not by the encryption mechanism. Since the logs are infrequently accessed, the correct approach is to transition objects into a cheaper storage class via lifecycle rules, not to change encryption to a costlier KMS option.