Security Logging and Monitoring practice questions

The user used the AWS Management Console, not the CLI

Why wrong: CloudTrail logs management events regardless of the client used to issue the API call; the AWS Management Console, CLI, SDKs, and other tools all generate the same underlying API requests that CloudTrail captures. Therefore, using the console rather than the CLI would still produce CloudTrail events, and the request source cannot change the 90-day retention limit of event history. The user's inability to find old events is a retention issue, not an ingestion or access-method issue.

The trail is configured for a single region only

Why wrong: A trail configured for a single region only records management events for that region, but CloudTrail's 'Event history' page is a separate account-level feature that displays events for all regions unless filtered. Even with a single-region trail, you can still view up to 90 days of event history, because the 90-day retention is fixed and independent of the trail's region scope. Thus, the regional configuration would affect what events are delivered to an S3 bucket, but it does not explain the absence of events older than 90 days.

The API calls were read-only and excluded by default

Why wrong: CloudTrail management event logging includes both read and write operations by default; the optional 'read-only' filter is used to classify events after capture, not to exclude read-only calls from logging. The CloudTrail event history page records read-only management events such as Describe* and List* calls as part of its default configuration, so these API calls are present in event history. Therefore, read-only calls cannot be the reason that events older than 90 days are missing.

Enable VPC Flow Logs and analyze for S3 API traffic

Why wrong: VPC Flow Logs capture IP traffic metadata—source and destination addresses, ports, and protocols—at the network interface level. They do not contain the S3 API operation name (such as PutBucketPolicy) or the request body, so you cannot identify which management action occurred. Even with a VPC endpoint, flow logs would only show TLS connections to S3, not the API calls themselves.

Configure an AWS Config rule to detect changes and invoke a Lambda function

Why wrong: AWS Config records and evaluates resource configuration changes, not individual IAM or API calls. A Config rule with Lambda remediation could react to a bucket policy becoming noncompliant, but it runs on a periodic or configuration-change basis and is not designed for immediate per-event alerting. The requirement is to alert on the PutBucketPolicy call itself, which only a CloudTrail/EventBridge pattern can match.

Enable S3 server access logs and parse them for PutBucketPolicy entries

Why wrong: S3 server access logs record object-level requests such as GET, PUT, and DELETE on bucket objects; they do not include management-plane API calls like PutBucketPolicy. These logs are delivered in batches to a destination bucket, making them suitable for access auditing rather than immediate alerting. The requested action affects the bucket's configuration, so it appears only in CloudTrail, not in server access logs.

Enable VPC Flow Logs and analyze for S3 traffic

Why wrong: VPC Flow Logs capture IP-level traffic metadata such as source/destination addresses, ports, and protocol, but they do not record S3 API actions like GetObject, nor the S3 bucket name, object key, or requester identity. For traffic through a gateway endpoint, flow logs only show traffic to the S3 service prefix and cannot differentiate between public and private or identify whether an object was actually read. Therefore, analyzing flow logs cannot detect specific unauthorized reads of sensitive S3 data.

Use AWS Config rules to check for public bucket policies and alert via SNS

Why wrong: AWS Config rules evaluate the configuration of S3 buckets, such as whether bucket policies or ACLs grant public access, but they do not monitor or log individual object access events. A rule can alert you to a misconfigured public policy, but it cannot tell you whether an actual GET request was made by an anonymous user or which object was accessed. Thus, this approach fails to detect ongoing public reads or provide an audit trail of data exposure.

Enable S3 event notifications for all object-level events and send to Amazon SNS

Why wrong: S3 event notifications support only specific object-level event types such as ObjectCreated, ObjectRemoved, and ObjectRestore, but they do not generate events for GET/read operations. Even if you enable all available event types, the notification payload does not include the requester's identity and cannot distinguish public from private access. Consequently, event notifications cannot detect or alert on anonymous reads of sensitive objects.

Configure each account to send logs to a central S3 bucket

Why wrong: While you can technically configure every member account to run its own CloudTrail trail and write to the same central S3 bucket, this requires manually distributing bucket policies, creating a trail in each account, and reconciling overlapping permissions. It is brittle because you must monitor each account separately for trail health, and it does not natively capture new accounts that join the organization unless you update them individually. AWS's designed approach for multi-account CloudTrail is an organization trail, not ad-hoc per-account delivery to a common bucket.

Enable Amazon GuardDuty in each account and aggregate findings

Why wrong: Amazon GuardDuty is a threat detection service that consumes CloudTrail management events, VPC Flow Logs, and DNS logs to generate security findings; it does not collect or archive raw CloudTrail log files. It can aggregate findings into a central account using GuardDuty administrator/member relationships, but that gives you findings, not the underlying API logs you need for full audit analysis. For central collection and analysis of CloudTrail logs, you need a delivery mechanism like S3 or CloudWatch Logs, not GuardDuty.

Use Amazon CloudWatch Logs to stream logs from each account to a central account

Why wrong: CloudTrail can stream events to CloudWatch Logs in each account, and those log groups can be cross-account subscribed to a central account, but this pipeline introduces added latency, log-group limits, and metric-filter overhead. CloudWatch Logs is suited for real-time alarms and operational monitoring, not for durable, reviewable long-term audit archives, and using it as the primary transport misses the single-trail simplicity of an organization trail. An organization trail can optionally deliver to CloudWatch Logs in the management account while also archiving raw JSON in S3.

Configure Amazon GuardDuty to monitor for trail modifications

Why wrong: Amazon GuardDuty consumes CloudTrail management and S3 data events to detect threats like credential exfiltration or malicious API activity, but it does not inspect or alert on the configuration state of the CloudTrail service itself. An attacker who disables a trail via StopLogging would not generate a GuardDuty finding, because GuardDuty treats CloudTrail's own control-plane calls as data rather than as a signal to act on. Consequently, this approach leaves the trail modification unnoticed.

Enable CloudTrail Insights to detect unusual activity

Why wrong: CloudTrail Insights uses machine learning to detect anomalous write API activity by establishing baseline patterns of your account's normal behavior, not to react to administrative configuration changes. A single StopLogging or UpdateTrail call is an expected, low-volume management event that would not be flagged as an anomaly, and Insights must be enabled on the trail itself, so if the trail is stopped, insight monitoring also stops. Thus, it fails to provide the immediate, deterministic alert required for trail integrity.

Enable S3 event notifications on the trail's S3 bucket

Why wrong: S3 event notifications on the trail's bucket are configured for s3:ObjectCreated and similar object-level events, so they only fire when new log files are delivered, not when a trail's configuration is altered. If an attacker calls StopLogging or UpdateTrail, no new object lands in the bucket, so no notification is sent; moreover, such calls are control-plane operations outside S3's data path. This approach also generates substantial noise from normal log delivery and can be bypassed simply by redirecting the trail to another bucket.

The security group rule allows SSH from 0.0.0.0/0

Why wrong: The security group rule permitting SSH from 0.0.0.0/0 is a legitimate network exposure that broadens the attack surface for unauthorized access, but it is an infrastructure misconfiguration separate from this CloudTrail event. While it should be remediated by restricting inbound SSH to trusted CIDRs, it does not directly explain why a CloudTrail log entry should be flagged as a security incident. The more immediate and severe concern in this log is the use of the AWS account root user, because AWS best practices mandate eliminating routine root user access entirely.

The API call failed as indicated by null response elements

Why wrong: Null responseElements in a CloudTrail event can simply indicate that the API call returned no output or that an error such as AccessDenied occurred; it is not a definitive sign of a failed call. Even when a call fails, CloudTrail still logs the event, so the mere presence of null responseElements does not identify a security risk. The root user identity in the event, however, is an explicit and actionable security finding, whereas responseElements alone would not tell you whether the account has been compromised or whether IAM governance has failed.

The request came from an external IP address

Why wrong: Seeing an external IP address as the source of an API request is normal because AWS APIs are typically accessed over the internet, unless a VPC endpoint or AWS PrivateLink is used for private connectivity. A single external IP does not indicate whether the caller is an authorized administrator or an attacker, so it is not a meaningful security finding without additional context such as geographic anomalies, historical behavior, or matching threat intelligence. This makes the external IP less critical than the fact that the request was made by the root user, which is an identity-based security violation that directly indicates risk.

The trail is not multi-region

Why wrong: The exhibit shows the trail is configured with `isMultiRegionTrail: true`, so this option is incorrect. A multi-region trail records API events from every AWS region into the same S3 bucket, while a single-region trail only captures events for the region where the trail was created. Because this trail is already multi-region, the lack of multi-region coverage is not a valid security finding.

Log file validation is not enabled

Why wrong: The claim that log file validation is not enabled is wrong because the trail configuration includes `enableLogFileValidation: true`. When log file validation is enabled, CloudTrail periodically creates digest files that contain hashes of the delivered log files and signs them with a private key, allowing you to detect if a log was altered or deleted after delivery. Since this trail already has validation enabled, it is not a security deficiency in this scenario.

CloudWatch Logs integration is missing

Why wrong: CloudWatch Logs integration is present because the exhibit shows `cloudWatchLogsLogGroupArn` configured, so this option is incorrect. The trail is streaming events to a CloudWatch Logs group, which enables real-time alarms, metric filters, and querying of API activity. If the ARN were absent or the IAM role were misconfigured, this would be a valid concern, but the configuration clearly indicates the integration exists.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor is incorrect because it is a best-practice assessment service that periodically checks your AWS environment against categories like cost optimization, security, fault tolerance, and service limits. It runs checks on a recurring schedule, not in real time, and it does not process or stream individual API calls such as DeleteBucket. Trusted Advisor surfaces recommendations in the console and can send weekly notifications, but it cannot be configured with an event filter to immediately alert you when a specific API call occurs. Therefore it lacks the real-time event-driven capability required here.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is incorrect because it is a threat detection service that continuously analyzes VPC Flow Logs, DNS logs, and CloudTrail management events using machine learning and threat intelligence to identify suspicious behavior. While GuardDuty can produce findings and send those findings to SNS for notification, it does not directly forward raw API call events like DeleteBucket in real time; its purpose is to detect anomalies and known threats, not to provide a generic real-time event stream of every API action. The finding generation process itself introduces delays and is tailored to security threats rather than operational events, so it does not meet the requirement for direct, immediate API call notifications.

AWS Config

Why wrong: AWS Config is incorrect because it is a configuration management and compliance service that records changes to resource configurations and evaluates them against rules you define. It tracks the state of resources over time and can deliver configuration history and snapshot updates to SNS, but it does not provide real-time notifications for individual API calls like DeleteBucket. Config focuses on what a resource looks like after a change, not the API action that triggered the change, and its notifications are tied to configuration item changes, which occur asynchronously and are not the same as CloudTrail's event-level API alerts. Hence, it is not a suitable mechanism for real-time API call notification.

Use AWS Config to find all EC2 instances that were terminated around that time. Then check the CloudTrail event for the IAM role. Finally, use the instance ID from the termination event to identify the source.

Why wrong: AWS Config only records the configuration history of resources, so it can show that certain instances transitioned to a terminated state, but it does not log who initiated the termination or from which IP. CloudTrail's TerminateInstances event contains the target instance IDs but not the source instance’s ID; the source is defined by the IAM principal, not by the instance being terminated. Therefore, using the termination event’s instance ID to identify the compromised source is logically incorrect and will lead to the wrong instance.

Check the CloudWatch Logs for the Auto Scaling group to find any error messages around the termination time. Correlate with the CloudTrail event to identify the IAM role. Then use the EC2 console to list all instances and check their IAM roles manually.

Why wrong: CloudWatch Logs for an Auto Scaling group capture scaling activities like instance launches and terminations, but they do not contain the API request details or the IAM identity that called TerminateInstances. Correlating these logs with CloudTrail would still require additional manual investigation, as the CloudTrail event would already provide the authoritative actor and source IP. Manually checking every instance’s IAM role is an unscalable, error-prone process that could miss the compromised instance entirely and does not leverage the forensics data available in VPC Flow Logs.

Amazon VPC Flow Logs

Why wrong: Amazon VPC Flow Logs capture metadata about network traffic at the elastic network interface level—source and destination IPs, ports, protocols, packets, and bytes—for both accepted and rejected flows. They operate at the network layer and do not include the API action name, caller identity, request parameters, or response details. As a result, VPC Flow Logs cannot be used to audit who or what performed API calls to AWS.

Amazon CloudWatch Logs

Why wrong: Amazon CloudWatch Logs is a centralized log store and monitoring service for application, service, and AWS log sources; it does not itself detect or record API calls. It can receive CloudTrail events only when CloudTrail is configured to deliver them, and it can then create metric filters or alarms. Without CloudTrail as the source, CloudWatch Logs has no intrinsic capability to capture API activity, so it is not the service that ensures all API calls are recorded.

AWS Config

Why wrong: AWS Config continuously records and assesses resource configuration changes and relationships, maintaining a timeline of what a resource looked like at each point in time. It applies rules to evaluate compliance, but it does not capture the API request or response data, the IAM principal who performed an action, or the exact API call. Its configuration history reflects the results of changes, not an auditable log of every API call made.

Step 1: Add protection to AWS resources. Step 2: Subscribe to AWS Shield Advanced. Step 3: Integrate with AWS WAF and create a mitigation rule. Step 4: Enable health-based detection.

Why wrong: This sequence is invalid because Shield Advanced is an opt-in, paid AWS service that must be subscribed to before the Add protection API will accept any resource. If you attempt to protect a resource first, the console/API has no active subscription context and returns an error, meaning the remaining configuration steps cannot be performed. Subscription is the prerequisite that enables all subsequent Shield Advanced capabilities.

Step 1: Subscribe to AWS Shield Advanced. Step 2: Integrate with AWS WAF and create a mitigation rule. Step 3: Add protection to AWS resources. Step 4: Enable health-based detection.

Why wrong: This ordering is flawed because the WAF mitigation rule is created to act on the specific resources you want Shield Advanced to protect, but no protections have been added yet. The rule's name, scope, and association depend on the ARN of the protected resource; without a protected resource, the rule cannot be attached or deployed. Adding protection first ensures the rule has a concrete target when it is integrated.

Step 1: Subscribe to AWS Shield Advanced. Step 2: Add protection to AWS resources. Step 3: Enable health-based detection. Step 4: Integrate with AWS WAF and create a mitigation rule.

Why wrong: Health-based detection is an advanced mitigation enhancement that should only be enabled after the WAF mitigation rule exists, because it uses health-check data to decide when to activate that rule. If you enable it before the rule is created, the health checks have no mitigation policy to trigger, so the detection is inert. Thus the WAF integration step must precede the health-based detection step in the setup.

Create a dedicated S3 bucket in the management account, enable S3 default encryption, and configure service delivery for each account.

Why wrong: Placing the centralized S3 bucket in the management account expands the attack surface of the root account and conflates administrative control with audit data, which is contrary to the AWS Well-Architected security guidance of separating logging into a dedicated account. S3 default encryption only encrypts objects at rest; it does not enforce encryption in transit or restrict which principals from member accounts can write to the bucket. A bucket policy with explicit allows for each account's logging service and condition statements such as aws:SecureTransport and s3:x-amz-server-side-encryption is still required, making this option incomplete.

Configure each account to deliver logs to the same S3 bucket used for other data.

Why wrong: Reusing an existing bucket that already stores operational or application data violates the principle of least privilege because the bucket policy must grant cross-account write access to logging services for a bucket that also contains sensitive non-log objects. This broadens the effective permissions of the logging service principal and makes it difficult to apply appropriate lifecycle, retention, and access-control policies that are specific to audit logs. Mixing logs with other data increases the risk of accidental deletion or modification of log evidence and complicates compliance audits.

Create an S3 bucket in each account and use S3 replication to copy logs to a central bucket.

Why wrong: This approach requires creating and managing a bucket in every account, duplicating storage costs and introducing asynchronous S3 replication delays, so logs do not arrive at the central bucket in near real time. S3 replication is not designed for log aggregation; it replicates objects based on source-bucket lifecycle rules and requires additional configuration for encryption, object ownership, and cross-account IAM, which scales poorly across many accounts in an organization. This also complicates data retention because replicated copies are subject to source-bucket lifecycle policies, undermining the goal of a single authoritative log archive.

Stream logs to an S3 bucket using Kinesis, then use S3 Lifecycle policies to transition logs to S3 Standard-IA after 90 days.

Why wrong: Streaming logs from CloudWatch Logs to S3 using Amazon Kinesis Data Firehose is a valid real-time delivery mechanism, but transitioning those objects to S3 Standard-IA after 90 days is not cost-optimal for 7-year archival that only needs occasional access. Standard-IA carries a per-GB retrieval fee and is designed for infrequent but immediate access, whereas S3 Glacier Deep Archive provides the lowest storage cost at the expense of hours-long retrieval. The Kinesis pipeline also introduces per-GB ingestion costs and additional operational overhead compared to a straightforward export task.

Set a retention policy on the CloudWatch Logs log group to 7 years and use CloudWatch Logs Insights for queries.

Why wrong: Keeping a 7-year retention policy directly on the CloudWatch Logs log group means paying CloudWatch Logs storage rates (per GB per month) for the entire duration, which is an order of magnitude more expensive than moving data to S3 Glacier Deep Archive. CloudWatch Logs Insights is an interactive query engine intended for real-time troubleshooting on recent logs, not a cost-effective archival or analytics solution, and it bills additional query costs. For compliance-grade data that is rarely accessed, storing everything in CloudWatch Logs for 7 years is financially impractical.

Set a retention policy on the CloudWatch Logs log group to 7 years and use CloudWatch Logs lifecycle policies to transition to Amazon S3 Glacier.

Why wrong: This option incorrectly assumes CloudWatch Logs has a native lifecycle policy that can transition log events directly to Amazon S3 Glacier. In reality, CloudWatch Logs only supports exporting data to an S3 bucket via export tasks or log subscriptions; there is no built-in S3 lifecycle integration within CloudWatch Logs itself. To ultimately archive in Glacier, you must first export the log data to S3 and then configure an S3 lifecycle rule — the retention policy on the log group only controls deletion in CloudWatch Logs, not movement to another service.

CloudTrail is not enabled in the account.

Why wrong: CloudTrail records API activity and management events, not network traffic. GuardDuty does use CloudTrail events for detecting suspicious API calls, such as unusual IAM actions or S3 operations, but the absence of CloudTrail would only suppress those API-based findings. The inability to analyze network traffic stems from missing VPC Flow Log data, which CloudTrail never provides. Therefore, disabling CloudTrail is not the cause of the network-related detection gap.

AWS Config is not enabled for the EC2 instance.

Why wrong: AWS Config tracks configuration changes and resource compliance, maintaining a historical inventory of resources. GuardDuty does not ingest AWS Config data as a threat-detection source, so enabling or disabling Config has no bearing on GuardDuty's findings. The missing network visibility is caused by GuardDuty not receiving VPC Flow Logs, not by a lack of configuration recording. Thus, this option is incorrect because it misidentifies the data source GuardDuty relies on.

VPC Flow Logs are only enabled for the subnet, not the instance's ENI.

Why wrong: VPC Flow Logs can be captured at the VPC, subnet, or ENI level, and subnet-level capture includes traffic for every ENI in that subnet, including the instance in question. GuardDuty can consume any of these scopes as long as the logs are delivered to CloudWatch Logs. It is not necessary to have flow logs enabled directly on the instance's ENI; the subnet-level configuration would still provide the required data. Therefore, this is not a valid explanation for the missing findings.

AWS CloudTrail and Amazon Simple Notification Service (SNS)

Why wrong: CloudTrail records the PutBucketPolicy API call as a control-plane event in its event history, but CloudTrail is an audit log, not a real-time event router. It delivers logs to an S3 bucket or CloudWatch Logs, and it does not natively invoke an SNS topic for each bucket policy change. To alert on the event you would need an Amazon EventBridge rule or a CloudWatch Logs subscription filter, so pairing CloudTrail and SNS alone does not satisfy the requirement.

S3 server access logs and Amazon Athena

Why wrong: S3 server access logs capture object-level requests such as GET, PUT, and DELETE against objects, not control-plane API calls like PutBucketPolicy. A bucket policy change is therefore absent from these logs, so Amazon Athena queries would never surface the modification. Even if the logs did contain relevant data, they are delivered on a best-effort basis with variable delays, making them unsuitable for real-time notification.

AWS Trusted Advisor and Amazon Simple Notification Service (SNS)

Why wrong: Trusted Advisor runs periodic checks—typically refreshed on a daily schedule—and its S3 permission checks are designed to flag publicly accessible buckets, not to detect every policy edit at the moment it occurs. Its SNS notifications are tied to overall check status changes or weekly digests, not to individual PutBucketPolicy events. Thus Trusted Advisor and SNS could eventually alert on a risky bucket configuration, but they cannot provide the real-time, change-triggered alerting described in the requirement.

VPC Flow Logs and Network ACL logs

Why wrong: VPC Flow Logs capture only network-layer metadata—source/destination IP, ports, protocol, and whether the packet was accepted or rejected—not the application payload or guest OS command input. A 'Network ACL log' does not exist as a service; Network ACLs themselves are stateless filters and do not emit logs. Therefore, this pair cannot reveal what commands were executed inside the instance, so it fails the investigation requirement.

S3 server access logs and CloudWatch Logs

Why wrong: S3 server access logs record requests made to an S3 bucket, which has no bearing on what was executed on an EC2 instance unless the instance was specifically interacting with that bucket. CloudWatch Logs can contain OS logs only if you have installed and configured the CloudWatch Logs agent or unified CloudWatch agent on the instance; it does not collect /var/log/secure by default. Even if OS logs were present, this combination would not link them to the IAM identity that launched the instance, so it is missing the actor attribution the investigation needs.

AWS CloudTrail and AWS Config history

Why wrong: CloudTrail logs AWS API calls, such as RunInstances or SendCommand, and AWS Config records configuration changes (e.g., instance type, security groups, AMI), but neither captures the actual commands entered into the guest OS shell. For example, a user could launch an instance via the console and then run arbitrary commands over SSH—those commands appear only in OS-level audit logs, not in CloudTrail or Config. Thus this pair provides the 'who created it' and 'what changed' but not the 'what command was executed inside it,' leaving a critical gap.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor is a best-practice recommendation engine that checks your account against AWS's predefined pillars—cost optimization, performance, fault tolerance, service limits, and security. For security, its IAM checks are configuration-focused, such as verifying access-key rotation or deleting unused credentials, and it reports against a static snapshot. It does not perform continuous, real-time analysis of CloudTrail events to spot behavioral anomalies like a user logging in from a new country or making atypical API calls. Therefore, while it might flag an insecure IAM config, it cannot detect and alert on suspicious IAM user activity as it happens.

AWS CloudTrail

Why wrong: AWS CloudTrail is the audit mechanism that records API calls made by or on behalf of an IAM user, delivering immutable logs to S3 or CloudWatch Logs for later analysis. However, it is purely a data capture service—it has no built-in machine learning or threshold-based logic to compare events against an expected baseline or produce a security finding. You could theorize and query the logs with Athena, or ship them to a SIEM, but the service itself will not 'alert' you to an anomalous pattern without that extra tooling. In short, CloudTrail answers 'what happened' but does not answer 'is this suspicious?', which is why it is not the correct answer.

Amazon Inspector

Why wrong: Amazon Inspector is a vulnerability management service that focuses on compute workloads, specifically Amazon EC2 instances, ECR container images, and Lambda functions at the package and network level. It assesses whether your resources have known CVEs, software flaws, or unintended network exposure, and it does not ingest CloudTrail data or interact with IAM roles' usage patterns. Since Inspector has no visibility into an IAM user's API behavior—whether that user is signing in from an odd location, making anomalous calls, or showing other red flags—it cannot generate findings for suspicious IAM activity. Therefore, using Inspector for this use case would simply be the wrong tool, as it addresses workload vulnerabilities rather than identity behavior.

Enable S3 Object Lock in governance mode on the bucket.

Why wrong: S3 Object Lock prevents deletion and overwrites but does not directly provide detection or alerting. While denied attempts are logged in CloudTrail, that requires CloudTrail data events to be enabled (not default) and still needs additional monitoring setup, making it an indirect and less reliable solution for this requirement.

Enable MFA Delete on the S3 bucket.

Why wrong: MFA Delete requires a valid multi-factor authentication code before a user can permanently delete an object version or suspend versioning, preventing unauthorized deletion at the API level. However, it does not generate its own audit log of denied attempts, and no alerting is built into the feature. Without additional server access logging or CloudTrail data events, you cannot detect that an unauthorized DELETE attempt occurred; it is a preventive, not detective, control.

Use a bucket policy that denies s3:DeleteObject for all principals.

Why wrong: A bucket policy with an explicit Deny for s3:DeleteObject on all principals blocks every delete request at the authorization layer, but bucket policies do not produce logs or notifications for denied actions. To see these denied attempts, you would need CloudTrail data events enabled and configured for the bucket, and then set up separate monitoring and alerting on the event stream. This means the policy alone fails the requirement to detect and alert on unauthorized DELETE attempts, as it only prevents them.

Amazon Kinesis Data Analytics

Why wrong: CloudWatch Logs subscription filters cannot deliver log events straight to Kinesis Data Analytics; they must first send to a Kinesis data stream or Firehose, and Kinesis Data Analytics then runs SQL or Apache Flink on that streaming data. This indirect pipeline adds operational complexity and still lacks the ready-built log visualization, dashboarding, and alerting features needed for typical log analysis.

AWS Glue

Why wrong: AWS Glue is a serverless ETL service optimized for batch-oriented data preparation and schema discovery over data lakes, not for consuming real-time log streams from CloudWatch Logs. Glue jobs are triggered on schedules or events and operate on data stored in Amazon S3, JDBC sources, or similar data stores; there is no native subscription integration to process CloudWatch Logs events as they arrive.

Amazon Athena

Why wrong: Amazon Athena is an interactive query engine that executes SQL against files already stored in Amazon S3, so it cannot receive a live stream directly from CloudWatch Logs. You would need an export task or a subscription filter into S3 (or Firehose) to land log files first, and even then Athena supports ad-hoc queries but not push-based real-time processing or streaming dashboards.

AWS Service Catalog

Why wrong: Service Catalog is for managing approved IT services, not for enforcing logging.

AWS CloudTrail

Why wrong: CloudTrail logs API calls, not resource configurations.