Threat Detection and Incident Response practice questions

Modify the network ACL for the subnet to deny all outbound traffic.

Why wrong: Modifying the network ACL to deny all outbound traffic is not the correct approach because NACLs are stateless and apply at the subnet level, meaning every instance in that subnet is affected, not just the compromised one. This creates a broad denial-of-service for legitimate workloads in the subnet and, because NACLs are stateless, you must also carefully configure inbound rules to allow return traffic, making the change complex and error-prone. It fails to provide the targeted, instance-specific containment that a security group rule offers.

Detach the instance from the Auto Scaling group.

Why wrong: Detaching the instance from the Auto Scaling group does not affect network access or running state; it only removes the instance from the group's lifecycle and scale-in/out management. The compromised instance continues to run and remains fully reachable on its current network path, so the attacker can still communicate with it and exfiltrate data. This action primarily prevents the ASG from replacing or terminating the instance, but it provides no isolation or containment for the compromise.

Terminate the EC2 instance immediately.

Why wrong: Terminating the EC2 instance immediately is inappropriate because it destroys volatile forensic evidence such as running processes, memory contents, and open network connections, and it makes any required root cause analysis difficult or impossible. Since termination is irreversible and removes the instance from the environment entirely, incident responders lose the ability to harvest indicators of compromise from the live system. A proper incident response approach would first isolate the instance and preserve its storage before considering any destructive action.

Create an AMI of the instance.

Why wrong: Creating an AMI of the instance is a poor fit for live forensics because the AMI creation process, although built on EBS snapshots, typically requires either a reboot or a stop for instance state consistency and then registers a deployable image artifact. That reboot or stop destroys the volatile memory you need to capture, violates point-in-time evidence integrity, and yields an image meant for deployment, not for bit-for-bit forensic acquisition. A raw EBS snapshot of the root volume is the correct disk-level artifact during incident response.

Use AWS Systems Manager Inventory to collect memory and disk information.

Why wrong: AWS Systems Manager Inventory is an agent-based configuration tool, not a forensic collection mechanism: it reports installed software, patches, services, and other metadata by querying the operating system through the SSM agent, but it never produces a raw memory dump or a block-level disk image. On a compromised host, the SSM agent and its results are subject to tampering, and running inventory commands writes additional log entries that alter the evidence. It therefore is not a substitute for an EBS snapshot plus a separate memory acquisition step.

Use AWS Backup to create a backup of the instance.

Why wrong: AWS Backup creates managed recovery points for disaster recovery, using services such as EBS snapshots, but it does so under a backup schedule and lifecycle policy, not under an incident-response acquisition workflow. To achieve application-consistent backups, AWS Backup may invoke pre- and post-snapshot scripts or require a reboot, and in all cases it excludes the instance's RAM contents, so volatile memory is lost. Its output also lacks the forensic integrity controls—for example, recording the snapshot ID and volume IDs with a cryptographic hash immediately after collection—that a dedicated EBS-snapshot-based evidence capture would include.

Amazon GuardDuty with threat detection enabled.

Why wrong: Amazon GuardDuty is a threat detection service that consumes CloudTrail management events, VPC Flow Logs, and DNS logs to identify malicious behavior; it does not itself record or expose the raw API-call history needed for compliance audits. Enabling GuardDuty would give you findings and alerts, but it would not provide a queryable, timestamped record of every API action across your accounts. Therefore, it cannot satisfy a requirement to audit API activity.

AWS Config with recording enabled for all resources.

Why wrong: AWS Config records configuration state changes and resource relationships, with configuration history delivered to S3 and compliance evaluated through rules. Although it may capture a resource's changed configuration and sometimes last-change information, it does not log the individual API calls, user identities, or request parameters that produced those changes. Config is configuration governance, not an API activity or cloud-trail audit.

VPC Flow Logs for all VPCs.

Why wrong: VPC Flow Logs capture metadata about network traffic at the elastic network interface level—source/destination IPs, ports, protocol, and packet/byte counts—but they contain no information about IAM users, roles, or API actions in AWS. They can help investigate network anomalies or exfiltration, yet they cannot serve as a record of who performed which API call. Thus, enabling VPC Flow Logs alone fails the API-auditing requirement.

The AMI ID ami-0abcdef1234567890 is not a standard Amazon-provided AMI.

Why wrong: A custom AMI ID does not inherently indicate an intrusion. Organizations routinely build and use golden images for consistent deployments, so a non-standard AMI is expected in many accounts. The CloudTrail log only shows the AMI ID used for the launch; without a pre-established whitelist of approved AMIs or additional context, this field is not a reliable sign of compromise.

The instance type m5.xlarge is unusually large compared to previous launches.

Why wrong: Instance size alone is not a useful indicator of compromise because resource requirements vary by application and workload. A change to a larger instance type could be legitimate scaling, and an attacker might also use a smaller instance; the CloudTrail log provides no baseline or expected instance type for comparison. Without a pattern of abnormal launches, such as a sudden increase in count or a change in region, this field does not provide actionable evidence.

The security group sg-0123456789abcdef0 allows inbound SSH from 0.0.0.0/0.

Why wrong: This statement about the security group rule cannot be verified from the CloudTrail RunInstances event, which includes only the security group IDs in the request parameters, not their ingress rules. Determining whether SSH is open to the world requires a separate DescribeSecurityGroups call or reviewing the security group's configuration. Even if the rule existed, it would be a misconfiguration that should be remediated, but it is not an anomaly revealed by the log entry in question.

Amazon CloudTrail event history.

Why wrong: Amazon CloudTrail event history records the API actions performed on a security group, such as AuthorizeSecurityGroupIngress or RevokeSecurityGroupEgress. However, it only shows that an action occurred and by whom, not the resulting set of rules in effect at the moment of the incident. You would have to correlate and replay all events to reconstruct the state, which is error-prone and not a supported point-in-time view.

AWS Systems Manager Inventory.

Why wrong: AWS Systems Manager Inventory is an agent-based feature that collects information from your EC2 instances, such as installed software, OS updates, and network configuration. It does not have any visibility into VPC-level resources like security group rules, which are managed by the EC2 and VPC services. Therefore, it cannot provide evidence of the security group state needed for forensic analysis.

VPC Flow Logs.

Why wrong: VPC Flow Logs capture metadata about IP traffic entering or leaving a network interface, including source/destination addresses, ports, and whether the traffic was permitted or denied. They do not contain the security group rule definitions themselves; they only reflect the outcome of those rules. Thus, flow logs can help you understand what traffic occurred, but they cannot tell you which specific rule allowed or denied a particular packet.

Subscribe the Lambda function to an SNS topic that GuardDuty publishes findings to.

Why wrong: This pattern is not supported by GuardDuty: GuardDuty does not publish findings to an SNS topic directly. Instead, findings are emitted as EventBridge events, and if a notification is desired, an EventBridge rule must first route the finding to an SNS topic as a target. Directly subscribing a Lambda function to a GuardDuty SNS topic would require a manually-created publisher that duplicates findings, adds latency, and risks missing events unless you build a separate polling mechanism.

Use CloudWatch Logs subscription filter to trigger Lambda on GuardDuty log entries.

Why wrong: GuardDuty never writes its findings to CloudWatch Logs as log entries, so a log subscription filter has no GuardDuty data to match. A CloudWatch Logs subscription filter is intended for VPC Flow Logs, CloudTrail logs, or application log groups, not for GuardDuty finding streams. Even if you configure it, the filter pattern will never match because there is no corresponding log group or log stream containing GuardDuty finding JSON. The real-time integration point is EventBridge, not Logs.

Have the Lambda function poll the EC2 instance metadata for threat indicators.

Why wrong: EC2 instance metadata (accessed at http://169.254.169.254/latest/meta-data) contains instance identity, IAM role, or user data, but it has no relationship to GuardDuty findings. GuardDuty generates findings by analyzing VPC DNS logs, VPC Flow Logs, and threat intelligence, and it publishes those findings through its API and EventBridge. Polling metadata would neither retrieve findings nor trigger a Lambda function; it would also add unnecessary custom infrastructure, latency, and credential-handling risk compared to the event-driven EventBridge integration.

Tag all instances with 'PatchGroup=Critical' to include them in the patching.

Why wrong: Tagging instances with `PatchGroup=Critical` only creates a patch group label; it does not by itself include them in any patching activity because AWS does not recognize a tag key of `PatchGroup` unless you have also registered that group to a patch baseline. Patch Manager uses the tag key exactly as `Patch Group` (with a space) when auto-associating groups, but even then the crucial missing step is calling `Register-PatchBaselineForPatchGroup` to assign a baseline. Merely tagging instances cannot cause them to receive a specific patch or be included in a patching schedule; the tag is the group membership mechanic, not the assignment action.

Use the AWS-provided default patch baseline for Windows.

Why wrong: The AWS-provided default patch baseline for Windows contains Microsoft's default patch selection rules, which typically approve updates based on classification and severity with an auto-approval delay, but a newly required critical patch may not be approved immediately if it falls outside the default auto-approval window or is not yet classified. Since the company must patch a specific critical patch that is 'required now', relying on the default baseline could leave the patch unapplied until the next auto-approval cycle that covers it. A custom baseline with an explicit approval rule for that patch (or an immediate approval) is needed to ensure it is installed deterministically, whereas the default baseline has no guarantee.

Use SSM Run Command to execute a script that downloads and installs the patch.

Why wrong: While SSM Run Command can execute a script to download and install a patch manually, it circumvents Patch Manager's lifecycle of patch scanning, compliance reporting, and baseline-based approval, leaving the instance out of the centralized patch management and audit trail. More importantly, the question asks for a Patch Manager-based approach, and Systems Manager Patch Manager itself uses Run Command under the hood to perform patching; manually scripting the install is brittle, lacks the patch baseline compliance integration, and does not register the patch in the Patch Manager console. Therefore, the intended and more reliable solution is to define a patch group and assign a custom baseline, not to launch an ad-hoc Run Command script.

Modify the security group attached to the instance to deny all outbound traffic, and let Auto Scaling launch a replacement instance.

Why wrong: Modifying the security group to remove all outbound rules (or restrict to a non-existent destination) is the correct first step because security groups are stateful and evaluated in real time: once the outbound rules are removed, the compromised instance loses all outbound connectivity instantly, preventing further data exfiltration or command-and-control traffic. While the instance is isolated, Auto Scaling can detect the unhealthy instance via a failed health check or by manually setting its health to 'Unhealthy', triggering a replacement launch. This approach both contains the breach and restores service capacity without relying on the compromised instance itself.

SSH into the instance and run a script to kill the mining process.

Why wrong: SSHing into a potentially compromised instance is dangerous because the attacker may have installed a rootkit or modified system binaries, making the environment untrustworthy; any commands you run, including killing the mining process, could be subverted or logged by the attacker. Even if the process is killed, there is no guarantee that persistence mechanisms—such as cron jobs, systemd services, or launch daemons—won't restart it immediately. This manual approach also leaves the instance connected to the network, allowing the attacker to maintain access or pivot to other resources while you are attempting remediation.

Immediately terminate the compromised EC2 instance and allow Auto Scaling to launch a new instance.

Why wrong: Terminating the instance immediately does not instantly sever its network path—there is a brief window during the termination sequence where the instance may still send outbound traffic, and an attacker with root-level persistence could have already launched secondary instances or scheduled re-launch via other AWS services. Immediate termination also destroys volatile memory and on-disk forensic evidence, making post-incident analysis difficult if you need to identify the attack vector. While Auto Scaling will replace the instance, the replacement inherits the same launch configuration and security group, so without addressing the underlying vulnerability (e.g., open inbound SSH rule or weak credentials), the new instance may be compromised just as quickly.

VPC Flow Logs

Why wrong: VPC Flow Logs capture metadata about IP traffic passing through VPC network interfaces, such as source and destination IP addresses, ports, protocol, and bytes transferred. They do not record the API request's content, the authenticated IAM identity, or the specific AWS operation performed, so they cannot directly reveal which credentials were used or what actions were attempted. Even if a malicious credential is used, Flow Logs might only show a network connection to an AWS API endpoint, offering no forensic detail about the call itself.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor provides point-in-time assessments and recommendations across cost optimization, performance, security, and fault tolerance, using checks such as leaked IAM access keys or overly permissive security groups. It does not maintain a historical log of API calls or user authentication events, so it cannot be used to trace how a credential was used or when it may have been compromised. In an investigation, Trusted Advisor can flag that a credential is publicly exposed or that IAM key rotation is overdue, but it offers no event-level audit data.

Amazon CloudWatch Logs

Why wrong: Amazon CloudWatch Logs is a centralized log storage and analysis service, but it does not natively ingest or generate AWS API call records. To get API activity into CloudWatch Logs, a security engineer must explicitly configure AWS CloudTrail to deliver management and data events to a CloudWatch Logs log group, or have applications ship their own logs via an agent — without that setup, no credential usage history exists there. While useful for monitoring or searching CloudTrail-delivered events, it is only a downstream consumer and cannot serve as the primary forensic source for investigating credential misuse.

AWS Config conformance packs and AWS Systems Manager Automation

Why wrong: AWS Config conformance packs consist of collections of Config rules and remediation actions that continuously evaluate resource configuration, and Systems Manager Automation documents can then fix resources that drift from compliance. However, Config does not subscribe to or react directly to Security Hub findings—it tracks configuration changes against its own rules, not the consolidated security findings aggregated by Security Hub. As a result, this combination would not automatically process Security Hub finding events unless you first build a custom EventBridge connector to translate those findings into Config rule evaluations or Automation executions. It is a valid remediation toolkit, but it is not the native trigger for Security Hub findings.

Amazon Inspector and AWS Step Functions

Why wrong: Amazon Inspector performs automated vulnerability assessments on EC2 instances, ECR container images, and Lambda functions, while AWS Step Functions adds orchestration to automate multi-step workflows. Inspector's findings can be integrated with Security Hub, but Inspector itself is not a consumer of Security Hub findings and cannot react to the full breadth of findings from services like IAM Access Analyzer or S3. Pairing Inspector with Step Functions would only address workload vulnerability findings, not the compliance and defensive findings that the security hub aggregation contains. Therefore, it is not the correct choice to automate responses to Security Hub findings generally.

Amazon GuardDuty and AWS Lambda

Why wrong: Amazon GuardDuty is a threat detection service that identifies suspicious behavior (e.g., unauthorized API calls or malicious files), and Lambda can be used to isolate affected resources. GuardDuty findings are ingested by Security Hub, but the finding events originate from GuardDuty's own EventBridge event bus, not from Security Hub's consolidated findings. If you configured a Lambda trigger directly on GuardDuty, you would miss findings from other Security Hub integrated sources and also bypass the multi-account administrator aggregation that Security Hub provides. Thus, the correct integration for this scenario must consume Security Hub events, making GuardDuty + Lambda unsuited as the primary answer.

Enable GuardDuty to export findings to CloudWatch Logs and then create a metric filter.

Why wrong: Enabling GuardDuty to export findings to CloudWatch Logs is not a native integration—GuardDuty automatically emits each finding as an event to Amazon EventBridge, not to a CloudWatch Logs group. Even if you used an EventBridge rule to deliver those events into CloudWatch Logs, you would then need a metric filter and alarm to trigger an action, adding latency and operational complexity. The metric filter would only match log text after the logs are written, so this approach is slower and more brittle than consuming the finding event directly.

Create an Amazon SNS topic and subscribe the Lambda function to it, then configure GuardDuty to publish to SNS.

Why wrong: GuardDuty has no native capability to 'publish to SNS'; its findings are delivered to EventBridge, so any SNS-based flow would require an extra EventBridge rule to route the finding to the SNS topic and then the Lambda function. That SNS hop is unnecessary for a single subscriber, and it means more IAM roles, permissions, and failure points to manage. Directly invoking Lambda from EventBridge is simpler and more reliable for an automated incident response playbook.

Set up a CloudWatch Logs subscription filter to forward GuardDuty logs to the Lambda function.

Why wrong: A CloudWatch Logs subscription filter only works against log groups and log streams that actually contain data, but GuardDuty does not write its findings to CloudWatch Logs by default—it emits each finding as an EventBridge event. Without a log stream populated by GuardDuty findings, the subscription filter would never match anything, so the Lambda function would never fire. Even if you piped GuardDuty events into CloudWatch Logs, you would have to parse encoded log events rather than receiving the structured finding directly from EventBridge.

Add a rate-based rule to a web ACL first, then create the web ACL, then associate with a resource, then test, then monitor.

Why wrong: This ordering is fundamentally invalid because AWS WAF has no construct for a standalone rule—a rate-based rule exists only as a rule statement within a WebACL. You must first create the WebACL to obtain the WebACL ID, then add the rule in an update or during creation; attempting to add a rule before the ACL exists has no target to attach to. The API model (e.g., UpdateWebACL) requires an existing WebACL, so the first step in any valid sequence must be creating the ACL.

Create a web ACL, then associate it with a resource, then add a rate-based rule, then test, then monitor.

Why wrong: This sequence associates an empty web ACL with your resource, meaning that the rate-based rule is not yet in place when the ACL starts evaluating traffic. Although a WebACL can be updated while associated and the rule would take effect immediately after the update, this ordering creates an intentional or accidental window in which the resource is exposed to unthrottled traffic. For a rate-based rule to be active from the moment the resource is protected, the rule must be added to the ACL before association.

Create a web ACL, then add a rate-based rule, then test the rule, then associate the ACL with a resource, then monitor.

Why wrong: Testing a rate-based rule requires the web ACL to be actively associated with a resource so that real or simulated traffic can be evaluated by the rule. If you test before association, the rule has no traffic path and thus cannot produce actual metrics or trigger a blocking action, so any 'test' is meaningless. The correct flow is to associate first, then send test traffic to the resource and observe the rule's behavior in AWS WAF metrics. This is also why the final monitoring step matters: you need the resource associated before you can derive useful thresholds from metrics.

AWS WAF: Managed DDoS protection service.

Why wrong: This pairing is incorrect: AWS WAF is not a managed DDoS protection service; that role belongs to AWS Shield. DDoS protection mitigates volumetric, protocol, and other attacks that target network availability, often at Layers 3 and 4, whereas WAF operates at Layer 7 and blocks specific HTTP/S request patterns. While using AWS WAF can help stop the application-layer flood component of an attack, it cannot absorb the massive network/transport-level traffic that AWS Shield handles, so labeling WAF as a DDoS service conflates two distinct services.

AWS Shield: Threat detection service.

Why wrong: This pairing is incorrect: AWS Shield does not serve as a threat detection service, which is the core function of Amazon GuardDuty. Shield detects and mitigates DDoS attack traffic in real time based on traffic characteristics such as volume, packet statistics, and protocol anomalies, but it does not analyze CloudTrail, DNS, or flow logs for compromise indicators. GuardDuty continuously processes those log streams and uses machine learning to generate security findings, so misattributing threat detection to Shield misrepresents the services' roles in the AWS shared responsibility model.

Identity-based policy: Attached to a resource and defines which principals can access it

Why wrong: Identity-based policies are JSON permission documents attached to an IAM user, group, or role, not to a resource. They define what actions the principal can perform on specified resources. A policy that is attached to a resource and names which principals can access it is called a resource-based policy, so this answer misidentifies the attachment target and purpose.

Resource-based policy: Attached to an IAM user, group, or role

Why wrong: Resource-based policies are attached directly to AWS resources such as S3 buckets, SQS queues, or KMS keys, and they grant access by explicitly listing the principals allowed to perform actions on that resource. Attaching a policy that defines permissions to an IAM user, group, or role is the definition of an identity-based policy, making this option incorrect.

CloudTrail and SNS

Why wrong: CloudTrail records management and data-plane API calls made by or on behalf of the Lambda function, such as Invoke, CreateFunction, or policy changes, but it does not capture the function's stdout/stderr, runtime exceptions, or custom application logs. Therefore SNS alerts triggered by CloudTrail events would not indicate processing errors or anomalous execution of the function. It is useful for audit trail analysis, not real-time application-level log monitoring.

AWS Config and SQS

Why wrong: AWS Config evaluates resource configurations, such as whether the Lambda function's environment variables are encrypted or its IAM role is compliant, and can deliver configuration snapshots or compliance changes via SNS, but it cannot inspect log output or runtime errors. SQS is a message queue, not a notification destination, and Config would only trigger on resource configuration changes, not on sensitive data processing failures. Hence this combination is unsuitable for real-time alerting on function execution.

Amazon Detective and SES

Why wrong: Amazon Detective ingests findings from GuardDuty, CloudTrail, VPC Flow Logs, and EKS and builds behavior graphs for post-incident security investigations; it does not continuously monitor CloudWatch Logs from a Lambda function or generate real-time operational alerts. SES is an email-sending service and could theoretically deliver an alert, but Detective does not emit event notifications when application logs contain an error. This combination is designed for forensic analysis after a security event, not for immediate processing-failure alerts.

Immediately terminate the instance to stop any ongoing malicious activity.

Why wrong: Immediately terminating the instance is a destroy-in-place action that permanently discards volatile data such as memory contents, open file handles, active network connections, and any ephemeral instance-store volumes, as well as clearing kernel-level evidence. Even if delete-on-termination is disabled for the EBS volume, the crash-dump and process state are gone, and the forensic chain of custody is broken because the runtime evidence no longer exists. This may also trigger Auto Scaling to launch a replacement host, potentially destroying the original’s placement data and making attribution harder.

SSH into the instance and run forensic tools to capture memory.

Why wrong: SSHing into the instance to run forensic tools alters the very evidence you intend to collect: the login writes to /var/log/wtmp and lastlog, updates shell history and atime, injects new processes into the process table, and modifies memory, so a defensible forensic timeline is contaminated. Interactive sessions can also trip EDR or shell monitoring, alerting an active attacker who may then accelerate destroying logs or move laterally. Even if you use a static binary, the act of connecting over SSH and executing commands is not an acquisition technique that preserves the original state.

Detach the instance from the Auto Scaling group and leave it running without changes.

Why wrong: Detaching the instance from the Auto Scaling group only prevents scaling actions from managing its lifecycle; it does nothing to interrupt the attacker’s active network sessions or stop ongoing write/delete operations on the compromised host. Leaving the instance fully connected to the VPC and its existing security group allows the attacker to continue exfiltrating sensitive data, pivoting to other resources, or planting backdoors, and any resulting writes can overwrite forensic evidence. The correct move is network-level isolation, not just lifecycle detachment.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a threat detection service that uses machine learning and anomaly detection across CloudTrail logs, VPC Flow Logs, and DNS logs. It can identify suspicious patterns of unauthorized S3 access, but it operates as a finding-generation service rather than a per-request alarm system. Findings are produced after correlation and analysis, so there is an inherent delay, and GuardDuty cannot be configured to trigger immediate CloudWatch alarms on individual API error codes like AccessDenied. Therefore, it does not provide the real-time, API-call-level detection that CloudTrail with CloudWatch metric filters offers.

S3 server access logs

Why wrong: S3 server access logs provide detailed records of requests made to a bucket, including requester, bucket name, request ID, and HTTP status. However, these logs are delivered on a best-effort basis, typically in batches with delays ranging from several minutes to hours, so they cannot drive real-time alarms. They are stored as objects in a destination bucket and require separate log processing and alerting logic; there is no native integration with CloudWatch for immediate threshold-based alarms. Consequently, they are useful for audit forensics but not for immediate unauthorized access detection.

AWS Config

Why wrong: AWS Config records configuration changes to AWS resources, such as modifications to S3 bucket policies, lifecycle rules, or encryption settings, and can evaluate them against compliance rules. It does not log individual API calls or object-level access events like GetObject or PutObject, so unauthorized access attempts that do not change configuration go completely undetected. While AWS Config can alert you if a bucket policy becomes public, it cannot tell you that a specific user unsuccessfully accessed an object. Thus it is a configuration governance tool, not an access monitoring tool for S3 operations.

Amazon Detective

Why wrong: Amazon Detective focuses on investigative analysis after a potential issue is identified, using machine learning and prebuilt data aggregations to build behavioral graphs of resources and identities. It does not serve as the centralized multi-account aggregation hub that ingests, consolidates, and normalizes security alerts across AWS services such as GuardDuty, Inspector, and IAM Access Analyzer; that operational aggregation role belongs to AWS Security Hub.

Amazon CloudWatch

Why wrong: Amazon CloudWatch is primarily an operational monitoring service for metrics, logs, and alarms, such as EC2 CPU utilization or Lambda errors, rather than a security findings aggregator. Even though security-related events can be streamed into CloudWatch Logs or trigger CloudWatch Events/EventBridge, CloudWatch does not normalize or consolidate findings from multiple security services, so it cannot provide the single-pane-of-glass view required for multi-account security posture.

AWS Config

Why wrong: AWS Config captures resource configurations and configuration changes, and evaluates those configurations against managed or custom rules to produce compliance scores; its Config aggregator can combine compliance snapshot data across accounts and Regions. However, Config only understands infrastructure configuration and compliance, not variable threat findings like a GuardDuty finding or an Inspector vulnerability result, so it cannot aggregate security alerts from those services as Security Hub does.

Use AWS Systems Manager to run a compliance scan on the running instance.

Why wrong: A compliance scan via Systems Manager on the live instance is unreliable because a compromised host may have tampered agents, logs, or kernel state, making the scan results deceptive. Furthermore, SSM compliance checks configuration baselines rather than performing a comprehensive vulnerability and CVE analysis of the AMI's software packages. The instance itself could also be affected by ongoing malicious activity, so isolating a copy is necessary.

Create an EBS snapshot from the AMI and scan the snapshot with Amazon Detective.

Why wrong: Amazon Detective is built to analyze telemetry such as VPC Flow Logs, AWS CloudTrail, and GuardDuty findings to identify root cause, not to scan EBS snapshots for vulnerabilities. Creating a snapshot from the AMI preserves the block-level state, but no native AWS service scans snapshots directly; you must launch a compute instance from it to run Inspector. Thus, this option misunderstands Detective's purpose.

Launch a test instance from the AMI in an isolated VPC and analyze its behavior.

Why wrong: While launching a test instance in an isolated VPC and observing its behavior can reveal suspicious processes or network calls, it is entirely manual and does not systematically identify known software vulnerabilities. Behavior analysis may miss dormant threats or CVEs that Amazon Inspector automatically detects by inspecting installed packages and configurations. For a thorough, evidence-based assessment, you need both isolation and an automated scanning layer.

Enable S3 event notifications on the CloudTrail bucket for DELETE events.

Why wrong: S3 event notifications on the CloudTrail bucket are triggered by object-level operations like s3:ObjectRemoved:* (DeleteObject), but the deletion of a CloudTrail trail itself is a control-plane API call (DeleteTrail) that produces no S3 object-level event. Even if you configured the bucket to send DELETE notifications, you would only learn about the removal of log files, not the trail configuration, and S3 notifications are delivered asynchronously with no tight CloudWatch alarm integration, making them slower and less deterministic than a CloudWatch Logs metric filter.

Use AWS Config to track CloudTrail configuration changes and trigger a Lambda function.

Why wrong: AWS Config records configuration changes to your trails but does so asynchronously and evaluates rules on a periodic schedule (for example, every 10 minutes or several hours, depending on the rule trigger). While you can write a custom Lambda function to react to a Config rule that detects 'CloudTrail deleted', the delay is not real-time and the setup is convoluted compared to a straightforward CloudWatch alarm. Additionally, Config is a resource-tracking service, not an event-driven alerting service; it is designed for compliance assessment, not for immediate notification of a single API action. This makes it a suboptimal choice for urgent deletion alerts.

Enable Amazon GuardDuty to monitor CloudTrail management events.

Why wrong: Amazon GuardDuty ingests CloudTrail management events as one of its data sources, but it applies threat intelligence and anomaly detection models to identify suspicious behavior; it does not generate a deterministic alert for every DeleteTrail API call. GuardDuty may flag the action as part of a policy activity that is considered risky, but findings are typically generated minutes to hours after the event, and they are surfaced in GuardDuty's console or through EventBridge for those who have built custom integration. Its primary purpose is detecting threats like compromised IAM credentials, not providing a real-time, specific alarm for a single API operation, so it is not the appropriate service for this requirement.