Threat Detection and Incident Response practice questions

Create an AMI of the instance.

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

AWS Config with compliance rules.

Why it fails: AWS Config checks resource configurations, not data transfer.

VPC Flow Logs.

Why it fails: VPC Flow Logs capture traffic to/from S3 via VPC endpoints, but the data transfer itself is encrypted and not visible in flow logs; they show connection metadata but not object-level details.

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

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

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

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

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

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

Take an EBS snapshot and analyze network logs from the snapshot.

Why it fails: An EBS snapshot is a point-in-time block-level backup of the attached volumes, containing only the file system and on-disk data. It does not capture any network traffic that never touched the disk, nor does it actively collect network metadata; any network logs present in the snapshot would be only what the OS or applications previously wrote to disk. Taking a snapshot does not help 'capture' network logs for the incident timeframe unless logging was already enabled and persisted to disk, and it certainly does not provide live traffic information, so it cannot be used as a network capture mechanism.

Use AWS Traffic Mirroring to mirror traffic to a monitoring appliance.

Why it fails: AWS Traffic Mirroring copies full IP packets from a source ENI to a monitoring appliance, offering deep packet inspection, but it is a resource-intensive feature that requires pre-provisioning a destination appliance and adds overhead at the hypervisor/instance level, consuming extra bandwidth and CPU. This overhead can degrade application performance during a live incident, which directly conflicts with the requirement to avoid performance impact. Furthermore, Traffic Mirroring can only capture traffic that occurs after it is configured; it cannot retroactively capture traffic that already happened, making it ineffective for an incident that has already occurred unless it was set up in advance.

Terminate the instance and launch a new one to capture network logs.

Why it fails: Terminating the instance destroys all evidence, including the live memory, ephemeral storage, network connections, and any forensic data that could be collected from the running system. Launching a new instance provides a completely clean environment with no relationship to the compromised one, and it cannot recover the old instance's network logs or traffic because those were never stored persistently. The correct incident response action is to preserve evidence by isolating the instance (e.g., modifying security groups to block traffic) while leaving it running to allow forensic analysis of live memory and disk, not to terminate it.

AWS Config

Why it fails: AWS Config records resource configuration changes and evaluates them against managed rules, such as detecting an S3 bucket that became public or whose policy was altered. It does not capture data-plane access events or byte-level transfer, so it cannot prove that any objects were read or copied out of the bucket. At best, it may flag a configuration that made exfiltration possible, but it does not provide evidence of the exfiltration itself.

AWS CloudTrail

Why it fails: AWS CloudTrail records who made API calls, including management events and, when explicitly enabled, S3 data events such as GetObject. But CloudTrail logs the API request/response metadata and not the object payload or bytes transferred, so it cannot quantify or prove data exfiltration of content. It might indicate that an authenticated principal issued a GetObject call, yet the definitive evidence of the data leaving the bucket is the server access log entry with the byte count.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor is a support/consulting tool that runs automated checks for security, cost optimization, performance, and fault tolerance, providing recommendations like enabling MFA delete or securing access keys. It does not collect or store historical access logs, network packets, or API activity, so it has no capability to provide forensic evidence of data exfiltration. Relying on it would be a category error because it reports on best practices, not on what actually happened in the environment.

AWS CloudTrail console notifications

Why it fails: The CloudTrail console displays recorded events but cannot push real-time alerts on API patterns such as DeleteTrail. It tempts because the console is where trails are created and logs browsed, yet event-driven notification requires Amazon EventBridge matching CloudTrail events and routing them to Amazon SNS.

Amazon VPC Flow Logs

Why it fails: VPC Flow Logs capture IP-level traffic metadata for network interfaces, not CloudTrail management API calls, so DeleteTrail never appears. It tempts because flow logs do support network anomaly alerting, which suits connectivity investigations, but the requirement is API-call detection via EventBridge and Amazon SNS.

Amazon S3 event notifications

Why it fails: S3 event notifications fire on object-level actions within a bucket, not on CloudTrail management events, so DeleteTrail cannot trigger them. It tempts because CloudTrail delivers logs to S3, but notification on the API call itself needs EventBridge rules forwarding matched events to Amazon SNS.

Amazon VPC Flow Logs

Why it fails: VPC Flow Logs capture IP-level metadata for traffic traversing elastic network interfaces, not the API-level detail of AWS service calls. It is tempting because it does log network activity, and would be correct for diagnosing connectivity or rejected packets between instances, but CloudTrail is what records API actions.

Amazon CloudWatch Logs

Why it fails: CloudWatch Logs stores application and service log output, not a record of every AWS API call across the account. It is tempting because CloudWatch is the natural home for log data, but API activity auditing requires CloudTrail, which captures management events per call.

AWS Config

Why it fails: AWS Config records resource configuration state and changes over time, not the API calls themselves. It is tempting because Config tracks who changed what, but it evaluates resource compliance rather than logging every API request, which CloudTrail does.

The principal is set to root, which cannot be used in bucket policies.

Why it fails: The root user principal is not invalid for S3 bucket policies. In fact, arn:aws:iam::123456789012:root is a commonly used principal that represents all IAM identities in the account, including IAM users and roles. Using the account root ARN in a bucket policy is a standard way to grant broad account-level access. Therefore, this is not the cause of the policy failing to restrict access as intended.

The resource ARN is incorrect because it should include the bucket name without /*.

Why it fails: For object-level operations such as s3:GetObject or s3:PutObject, the resource ARN must include the trailing /* to explicitly target objects inside the bucket. The bucket-level ARN without the wildcard, arn:aws:s3:::my-bucket, only applies to bucket-level actions like s3:ListBucket. Since the policy is intended to control object access, the resource element with /* is correct. The flaw in the policy is unrelated to the resource ARN.

The condition key 'aws:SourceIp' is not supported for S3 bucket policies.

Why it fails: Asserting that aws:SourceIp is unsupported in S3 bucket policies is incorrect. AWS explicitly supports aws:SourceIp as a global condition key that can be used in S3 bucket policies for requests arriving from public IP addresses. The key functions as expected when traffic does not traverse a VPC endpoint. However, it fails to capture the original client IP for VPC endpoint traffic, which is why the correct key for that scenario is aws:VpcSourceIp. The key is not unsupported overall; it simply has a limitation with VPC endpoints.

aws ec2 get-console-output --instance-id i-1234567890abcdef0

Why it fails: The get-console-output API returns only the instance's console or serial output, such as boot logs and kernel messages. It does not expose the volatile memory (RAM) or current running processes, so you cannot use it to acquire a memory image for Volatility analysis. During incident response, memory forensics requires direct access to /dev/mem or a dedicated memory acquisition utility, which this CLI call cannot provide.

aws ssm send-command --instance-ids i-1234567890abcdef0 --document-name AWS-RunShellScript --parameters commands='volatility -f /dev/mem imageinfo'

Why it fails: The send-command operation runs a one-off, non-interactive command via the SSM Agent; it does not provide an interactive TTY for forensics tasks. In this example, 'volatility -f /dev/mem imageinfo' is flawed because /dev/mem is not a complete physical memory device on modern Linux kernels and is typically restricted, and Volatility expects a captured memory image file rather than a live device. Even if the command succeeded, send-command can only collect command output, not transfer a multi-gigabyte memory dump in a practical way, making it unsuitable for memory acquisition.

aws ec2-instance-connect send-ssh-public-key --instance-id i-1234567890abcdef0 --instance-os-user ec2-user --ssh-public-key file://key.pub

Why it fails: The ec2-instance-connect send-ssh-public-key call merely pushes a temporary SSH key to the instance's metadata, granting you permission to start an SSH session as 'ec2-user.' It does not execute any forensic commands; it only authenticates you for a later SSH connection. To actually capture memory you would still need to establish a shell and run a memory acquisition tool, and the key-push step itself does nothing to preserve volatile evidence.

The policy grants excessive permissions by allowing all actions.

Why it fails: The statement's Action element is explicitly limited to `lambda:InvokeFunction`; it does not use a wildcard like `lambda:*` or include other API actions such as `UpdateFunctionCode` or `AddPermission`. Invocation is a read/execution operation that does not grant the caller any ability to modify the function's code, configuration, or permissions. Therefore, the policy does not 'allow all actions' — it grants a single, narrowly scoped action.

The policy does not specify a resource ARN, so it applies to all functions.

Why it fails: This statement is incorrect because the Resource element is present and explicitly set to a fully qualified function ARN, such as `arn:aws:lambda:us-east-1:123456789012:function:MyFunction`. This ARN pins the policy to that exact Lambda function, so the statement does not apply to all functions. If the Resource were omitted or used a wildcard it would be a valid concern, but that is not the case here.

The policy allows the Lambda service to modify the function code.

Why it fails: The only action granted in this policy is `lambda:InvokeFunction`, which triggers the function synchronously or asynchronously. Modifying function code would require `lambda:UpdateFunctionCode`, and changing runtime configuration would require actions like `lambda:UpdateFunctionConfiguration` — neither of which is present in the statement. Therefore, this policy does not give the Lambda service any ability to alter the function's code.

Create an AWS WAF IP set and associate it with the CloudFront distribution. Configure CloudFront to block the IP.

Why it fails: A WAF IP set only inspects web requests (HTTP/S) at the CloudFront edge, so it cannot block non-web protocols like SSH/RDP or traffic that bypasses CloudFront entirely. Since CloudTrail logs API calls made to service endpoints, the source IP may be hitting AWS directly rather than through the distribution. Relying on WAF leaves the IP address untouched for any other network traffic to your VPC.

Add the IP address to a security group with a DENY rule and enable AWS Security Hub to send alerts.

Why it fails: Security groups are stateful and only support allow rules; they have no explicit deny list, so you cannot add a DENY rule for a specific IP address. Even if you attempted to remove all allow rules for that IP, it would disrupt legitimate traffic from other sources, and Security Hub is solely an aggregation and findings service that cannot block traffic or execute IP-level alerts. Thus this option fails both on the firewall capability and the alerting mechanism.

Revoke IAM permissions for the user associated with the IP and enable GuardDuty for alerting.

Why it fails: CloudTrail records the source IP, but that IP is frequently a shared NAT or proxy address, so it may not map cleanly to a single IAM user; revoking permissions for one user would not stop other activity from that IP. Revoking IAM permissions only prevents that principal from making authenticated API calls — it leaves the network path open, so the IP can still probe other services or use different credentials. GuardDuty is a detective service that generates findings but does not provide IP-specific blocking or IP-triggered alarms without additional custom configuration.

Disable GuardDuty for that member account and rely on other accounts.

Why it fails: Disabling GuardDuty in the member account is a disproportionate, all-or-nothing action. It stops all threat detection and alerting for that specific account, so you would not see any GuardDuty findings—including genuinely critical ones—from that account. Unlike a suppression rule, disabling the service cannot target finding types or criteria, and it forces you to rely on other accounts that have no visibility into the traffic in that member account.

Use AWS Security Hub insights to filter out those findings from the aggregated view.

Why it fails: Security Hub insights are simply aggregated views and filtering tools—they do not change what GuardDuty generates or reports. When you filter out a GuardDuty finding through Security Hub insights, the underlying finding still exists, still counts toward active findings, and can still trigger EventBridge rules or compliance checks. This approach only hides the finding from the Security Hub dashboard and does not suppress it in the member account or any other GuardDuty account.

Ask the delegated administrator to add a suppression rule in the GuardDuty console for that account.

Why it fails: The delegated administrator can manage GuardDuty for member accounts, but suppression rules are local account settings, not something a delegated administrator applies to a member's console. GuardDuty treats each member account's configuration (including suppression rules, trusted IP lists, and threat lists) as account-specific, so the rule must be created by the member account itself. Asking the delegated administrator to add the rule is therefore ineffective; they can view findings, but they cannot alter the member account's suppression rules on their behalf.

Delete the bucket and recreate it.

Why it fails: Destructive, not containment.

Enable MFA Delete on the bucket.

Why it fails: Does not stop existing access.

Enable default encryption for the bucket.

Why it fails: Does not affect access.

AWS WAF

Why it fails: AWS WAF is a web application firewall that protects HTTP/HTTPS endpoints by inspecting Layer 7 traffic; it is typically attached to ALBs, CloudFront, or API Gateway. It has no visibility into the EKS data plane, pod processes, syscalls, or Kubernetes audit events, so it cannot observe or detect a container escape. Even in an EKS ingress path, WAF only filters incoming web requests and would not flag a process that has broken out of its container.

VPC Flow Logs

Why it fails: VPC Flow Logs capture metadata about IP traffic at the elastic network interface level, including source/destination addresses, ports, protocol, and accepted or rejected actions. They lack container identity, process, user, and syscall context, and they only reflect network conversations, not kernel-level events or file system activity. A container escape might eventually cause unusual east-west traffic, but Flow Logs cannot directly identify the exploit or the container boundary breach itself.

High volume of inbound network traffic.

Why it fails: High volume of inbound network traffic does not map to crypto-mining: mining workers maintain persistent outbound TCP connections to pool servers and consume almost no inbound bandwidth proportionally. Heavy inbound traffic is just as often legitimate user load, a web application spike, or an inbound DDoS attack, and GuardDuty would classify those under denial-of-service patterns rather than cryptocurrency-related findings. Volume alone, too, is not an indicator GuardDuty uses because findings require known threat context or abnormality.

High disk I/O operations.

Why it fails: High disk I/O operations are not a crypto-mining symptom because mining software performs negligible storage reads and writes; it works in memory and by issuing CPU instructions. Elevated disk I/O on an EC2 instance more likely indicates a database query storm, log flushing, or an application performing file operations, which is outside the crypto-mining detection model. GuardDuty does not emit a crypto-mining finding based on storage metrics, and disk I/O spikes are not in the same behavioral class as CPU or network mining indicators.

Detach the EBS volume from the instance.

Why it fails: Detaching the EBS volume leaves the instance running and still exfiltrating, and it destroys volatile memory evidence. Isolation via a security group or network ACL stops traffic while preserving the instance. Detaching suits snapshotting data from a stopped instance, not containing live network exfiltration.

Terminate the EC2 instance immediately.

Why it fails: Termination destroys volatile memory and instance state, and the Auto Scaling group immediately launches a replacement that may also be compromised. Isolation preserves evidence while halting traffic. Termination is tempting as instant containment, and suits disposable instances with no forensic requirement, but here it defeats evidence preservation.

Shut down the instance from within the OS.

Why it fails: An OS-level shutdown depends on the compromised instance obeying, which malware can subvert, and it clears volatile memory. Network isolation stops exfiltration externally while keeping the instance intact for forensics. Shutting down suits graceful decommissioning, not containment of an actively hostile host.

The trail had an explicit deny in the same policy that was overridden by a separate allow.

Why it fails: In IAM, an explicit deny in any applicable policy always overrides an allow, regardless of whether the allow is in the same policy or a different one. A statement with Effect: Deny for the CloudTrail action would cause the request to fail before any allow could be considered, so an allow cannot override it. Therefore, this explanation is invalid because the user could not have succeeded if an explicit deny was present and matched the action/resource.

The user's permissions were granted through a service control policy (SCP) that allowed the action.

Why it fails: Service control policies (SCPs) act as permission boundaries for entire accounts or OUs; they do not grant permissions. An SCP that allows an action only means the action is not prohibited at the organization level—the user or role still needs an identity-based IAM policy (or resource policy) that explicitly allows the CloudTrail operation. Thus, citing an SCP allow does not explain how the user obtained the required IAM permission; without an allow, the default-deny would still block the call.

CloudTrail API calls are not logged and bypass IAM policies.

Why it fails: CloudTrail is an AWS service whose control-plane operations, such as creating or updating trails, are themselves API calls subject to IAM authentication and authorization. CloudTrail logs data events and management events for other services, but that does not exempt its own management APIs from IAM policy evaluation. Therefore, the claim that these calls are not logged and bypass IAM policies is false; in fact, a trail can record the very call that created or modified it.

Assign a new security group that denies all inbound and outbound traffic.

Why it fails: A replacement security group denying all traffic isolates the instance at the network layer but leaves the original group's rules intact and does not block instance metadata access. It is the standard isolation step when containment alone is required. Preserving forensic data needs the instance's EBS volumes snapshotted before any state changes.

Shut down the instance from the OS.

Why it fails: Shutting down from the OS stops the instance, but memory contents and volatile artefacts are lost, and the shutdown itself alters disk state, compromising forensic integrity. It is used for cost control or planned maintenance. Isolation with forensic preservation requires network-level containment while the instance keeps running.

Terminate the instance.

Why it fails: Termination destroys the instance and its ephemeral storage, and by default deletes the root EBS volume, eliminating the evidence the team must preserve. It is used to remove disposable or immutable infrastructure. Forensic response instead snapshots EBS volumes and isolates the running instance from the network.