Security Logging and Monitoring practice questions

Configure a CloudWatch Events rule to ignore the findings

Why it fails: CloudWatch Events (now Amazon EventBridge) can route GuardDuty findings to downstream targets like Lambda functions or SNS topics, but an event rule merely reacts to findings; it does not modify GuardDuty's internal state or remove them from the console. The finding remains active and visible in GuardDuty, whether or not the rule chooses to act on it, because the rule is a consumer of the finding stream, not a control on the detector. Thus, configuring a rule to 'ignore' findings has no effect on the GuardDuty console listing.

Manually delete the findings from the GuardDuty console

Why it fails: GuardDuty findings are immutable records of security-relevant activity; the service provides no delete operation in either the console or the API. You can archive findings, which moves them out of the active list, but archiving does not delete the finding and does not prevent the same finding type from recurring. Manual deletion is simply not possible, so the only effective suppression mechanism is a filter with conditions that exclude the false-positive pattern.

Disable the GuardDuty detector for the affected accounts

Why it fails: Disabling the GuardDuty detector is a region-level switch that stops all threat detection and halts generation of every finding type for that account, not just the low-severity item you want to suppress. This also suspends access to the findings list (or stops updates to existing findings) and disables downstream integrations such as EventBridge and Security Hub, so real high-severity threats would go unnoticed. Suppressing a single false positive should never require giving up all visibility into that account, which is why filters are the correct approach.

AWS CloudTrail

Why it fails: AWS CloudTrail is an auditing service that records API calls made to AWS, such as who launched an EC2 instance or modified an S3 bucket policy. It captures control-plane activity and user identity, not the actual data packets or connections flowing between resources inside a VPC. Therefore, it cannot be used to capture network traffic.

AWS Config

Why it fails: AWS Config evaluates and records configuration changes to AWS resources, such as when a security group rule or route table changes. It provides a timeline of resource configurations and compliance history, but it does not observe or record live network traffic passing through the VPC. This makes it irrelevant for capturing network traffic.

Amazon GuardDuty

Why it fails: Amazon GuardDuty is a threat detection service that analyzes VPC Flow Logs, DNS logs, and other sources to identify suspicious activity such as port scanning or crypto-mining. It does not capture or store raw network traffic; it only consumes existing log data and generates findings. Therefore, GuardDuty is a detection mechanism, not a traffic capture solution.

Amazon S3

Why it fails: S3 requires S3 event notifications or Lambda to send to CloudWatch.

Amazon Route 53

Why it fails: Route 53 logs DNS queries to Route 53 Resolver logs, not CloudWatch Logs.

AWS CloudTrail

Why it fails: CloudTrail delivers logs to S3; to send to CloudWatch Logs, a subscription is needed.

Amazon VPC Flow Logs

Why it fails: Amazon VPC Flow Logs capture metadata about IP traffic traversing VPC network interfaces, such as source and destination IPs, ports, protocols, and packet counts, but they do not record IAM identities or AWS API request context. Flow logs cannot indicate that a principal from account A assumed a role in account B or invoked an API action; they only show raw network packets moving between hosts. Therefore, VPC Flow Logs are not suitable for monitoring cross-account access, which is a logical API-level activity rather than a pure network flow.

Amazon Inspector

Why it fails: Amazon Inspector is a vulnerability management service that scans workloads for software vulnerabilities, unintended network exposure, and deviations from security best practices by using an agent installed on EC2 instances and network reachability assessments. Inspector has no capability to log or monitor IAM-based cross-account access, because it does not ingest CloudTrail events or record API activity, identities, or session context. Its scope is assessing workload risk, not detecting or logging the logical access that occurs between accounts, so it is irrelevant to this monitoring requirement.

The security group rule allows SSH from 0.0.0.0/0

Why it fails: 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 it fails: 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 it fails: 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 member accounts have not enabled CloudTrail Insights

Why it fails: CloudTrail Insights is optional and not required for logging.

The S3 bucket policy does not grant the correct permissions to the member accounts

Why it fails: The engineer verified the policy is correct.

The trail is not configured as a multi-region trail

Why it fails: Organization trails are multi-region by default.

Enable CloudTrail in each account and aggregate logs to a centralized S3 bucket. Use Athena queries to detect root activity and send alerts via SNS.

Why it fails: Athena queries are not real-time; they run on a schedule, causing delays.

Use AWS Lambda functions in each account to poll CloudTrail logs and send root activity to a central SQS queue.

Why it fails: Polling adds complexity and latency; Lambda functions would need frequent invocations and are less efficient than CloudWatch alarms.

Enable AWS Config rules in each account to detect root user activity and send notifications to a central SNS topic.

Why it fails: AWS Config rules are for resource configuration compliance, not for monitoring API activity in real-time.

Review the VPC Flow Logs for any traffic to the EC2 API endpoint. Look for the source IP that made the API call. Then use that IP to find the instance in the EC2 console. Check the IAM role attached to that instance.

Why it fails: VPC Flow Logs capture the network traffic between EC2 instances and the EC2 API endpoint, recording the source private IP and destination IP for each connection. By filtering Flow Logs for the API endpoint’s IP address on port 443 around the time of the termination event, you can identify the source IP and then match that IP to a specific ENI and EC2 instance in the console. Once the instance is identified, you can inspect its attached IAM role to see which credentials were used for the unauthorized call.

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

The condition key should be 'aws:sourceIp' (lowercase 's').

Why it fails: The condition key 'aws:SourceIp' is case-sensitive and must have a capital 'S'.

The policy should use the 'NotIpAddress' condition operator instead of 'IpAddress'.

Why it fails: Using 'NotIpAddress' would deny access from the specified IP range, not allow it.

The resource ARN should be 'arn:aws:s3:::example-bucket' without the '/*' suffix.

Why it fails: The resource ARN for GetObject and PutObject must include the object path '/*'.

CloudTrail is not enabled in the account.

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

Enable S3 Object Lock in governance mode on the bucket.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: Service Catalog is for managing approved IT services, not for enforcing logging.

AWS CloudTrail

Why it fails: CloudTrail logs API calls, not resource configurations.

Use CloudWatch Logs to stream flow logs to a Lambda function that writes to S3.

Why it fails: Using CloudWatch Logs with a Lambda function to write to S3 introduces unnecessary compute overhead and latency, whereas VPC Flow Logs can publish directly to S3 without any intermediary service. This option is tempting because CloudWatch Logs subscriptions are a common pattern for processing log streams, and would be correct if transformation or enrichment of the logs were required before storage.

Configure each account's VPC Flow Logs to a local S3 bucket, then use S3 replication to copy to the central bucket.

Why it fails: Replication introduces a dependency on source bucket permissions and lifecycle policies, which adds operational overhead and potential points of failure for centralised log collection. It is tempting because S3 replication is designed for cross-region or cross-account data synchronisation, and would be correct if the requirement were to maintain identical copies of objects across buckets for redundancy or latency reduction, rather than to collect logs directly from multiple sources into one destination.

Use AWS Organizations to centrally enable VPC Flow Logs in all accounts and deliver to the central S3 bucket.

Why it fails: Using AWS Organizations enables centralized, repeatable deployment of VPC Flow Log configurations through CloudFormation StackSets, which can automatically create flow log resources in every account (and future accounts) within the organization. The flow logs can be delivered directly to a central S3 bucket by specifying the bucket ARN, eliminating the need for per-account manual setup and ensuring consistent log delivery with centralized access control.

Use Amazon EventBridge to capture S3 events and forward them to CloudTrail.

Why it fails: EventBridge is not used to feed events into CloudTrail; CloudTrail directly monitors S3 API calls.

Enable S3 server access logs for all buckets and aggregate them using Athena.

Why it fails: Server access logs are different from CloudTrail data events; they do not capture API calls.

Create a new trail in each member account to log S3 data events and deliver to a central S3 bucket.

Why it fails: This increases operational overhead and does not leverage organization trails.

Create a single VPC Flow Log subscription in the security account that captures logs from all VPCs.

Why it fails: VPC Flow Logs are inherently a VPC-level resource—you must create a flow log for each VPC, and a flow log created in the security account can only capture traffic for VPCs in that same account. There is no single subscription or parameter that can point to all VPCs across your organization; each flow log requires its own definition and destination. This option mistakenly assumes a global aggregator exists, but Flow Logs are collected locally and then published to a chosen destination, so a security-account-only configuration cannot see other accounts' traffic.

Create a CloudWatch Logs subscription filter in each account to stream logs to the security account.

Why it fails: A CloudWatch Logs subscription filter routed to the security account would force you to configure and maintain a separate subscription in every account and region, along with cross-account delivery infrastructure such as Kinesis Data Streams and matching IAM roles, creating significant operational overhead. It also assumes flow logs are already enabled in CloudWatch Logs, which adds another layer of per-account setup and cost for data ingestion. This approach is much more complex than using StackSets to directly publish to S3, and it is not the intended centralized solution for multi-account logging.

Configure S3 replication from each account's bucket to the central bucket.

Why it fails: S3 replication is asynchronous and typically delivers objects only after the objects are already written to the source bucket, so it cannot give the near-real-time visibility expected for VPC Flow Logs; it also requires enabling bucket versioning on both source and destination buckets. You would need to create a dedicated flow log bucket in every account, set up replication rules per bucket with IAM roles, and incur per-replication request and storage costs. For a centralized logging design, directly publishing flow logs to one bucket is simpler and more cost-effective than replicating copies from many buckets.

Amazon Kinesis Data Streams

Why it fails: GuardDuty does not directly send to Kinesis; you need EventBridge.

Amazon Simple Queue Service (SQS)

Why it fails: GuardDuty does not directly send to SQS; you must use EventBridge as an intermediary.

AWS Lambda

Why it fails: Lambda is a compute service, not a destination; it can be invoked by EventBridge.

Amazon CloudWatch Logs Insights

Why it fails: CloudWatch Logs Insights is a query engine for logs that are stored in Amazon CloudWatch Logs, not for objects in an S3 bucket. If WAF logs were streamed to CloudWatch Logs rather than S3, Insights would be appropriate, but the scenario implies S3 storage based on the Athena answer. Since Insights cannot access S3 directly, it is the wrong tool for querying WAF log files delivered to S3.

Amazon QuickSight

Why it fails: Amazon QuickSight is a business intelligence service for building interactive dashboards and visualizations, not for querying raw log files directly. Although QuickSight can connect to Athena and visualize query results, it does not provide SQL access to WAF logs stored in S3 by itself. To analyze WAF logs with QuickSight you would first need to run an Athena query, making QuickSight a secondary visualization layer rather than the query engine required here.

AWS WAF console

Why it fails: The AWS WAF console displays real-time metrics, sampled requests, and traffic trends pulled from Amazon CloudWatch, but it does not offer a query interface for raw log data stored in S3. You can see aggregate counts and inspect a small sample of requests within the console, but you cannot run complex, filter-specific SQL queries across the full log history. For detailed forensic or analytical queries, you must use a dedicated query service like Athena rather than the console.

The bucket is not in the same region as the trail

Why it fails: S3 buckets are Region-scoped, yet CloudTrail writes to any bucket regardless of the trail's Region, so cross-Region placement does not stop delivery. It is tempting because latency and data-residency concerns make co-location seem mandatory, but the bucket policy's principal or ACL is what governs writes.

The bucket policy does not specify a condition

Why it fails: A missing condition does not block delivery; CloudTrail's PutObject succeeds under a matching principal and resource. Conditions such as aws:SourceArn or s3:x-amz-acl tighten access but are optional. Engineers add them for confused-deputy protection, so their absence is tempting yet unrelated to the failure.

The bucket is encrypted with SSE-KMS

Why it fails: SSE-KMS encryption does not itself prevent delivery; CloudTrail supports KMS-encrypted buckets provided the key policy grants the trail's role kms:GenerateDataKey and kms:Decrypt. It is tempting because missing key permissions do break delivery, but encryption alone is not the cause.

The log group does not exist

Why it fails: The log group does not exist is not the cause of the missing metric data because the exhibit shows a metric filter created on the log group, and CloudWatch Logs permits a metric filter to be defined regardless of whether the log group currently contains log events. If the log group were entirely absent, the PutMetricFilter API call would have failed with a ResourceNotFoundException during creation, so the fact that the filter exists indicates the log group exists. Additionally, CloudWatch Logs can display a metric filter for an empty log group, so the absence of data is more likely due to the filter pattern not matching any log events or being syntactically malformed.

CloudTrail is not enabled for the account

Why it fails: CloudTrail not being enabled for the account is not the reason the metric filter shows no data because the exhibit already demonstrates that a metric filter was successfully created on a log group, and CloudTrail logs are typically delivered to that log group only after CloudTrail is configured. If CloudTrail were disabled, the log group would have no incoming events, but that would produce a different symptom—a complete absence of log streams—rather than a malformed filter pattern error. Moreover, the metric filter's pattern syntax is evaluated when log events are ingested, and an invalid pattern would prevent matches even if CloudTrail were fully enabled and delivering events.

The metric namespace is invalid

Why it fails: The metric namespace is invalid is not the cause because the exhibit does not show an explicit namespace being set; when no namespace is specified during metric filter creation, CloudWatch defaults to a namespace derived from the log group name or the filter's 'metricTransformations' configuration. An invalid namespace would typically trigger a validation error at the time the PutMetricFilter or PutMetricData call is made, not silently produce zero data points. Since the filter was created, the namespace—whether explicit or default—was accepted by the CloudWatch API, so the absence of metrics must stem from the filter pattern not matching the log events.