Scenario practice questions

SSL/TLS certificate

Why it fails: SSL/TLS certificates are not recognized by the IAM user authentication process. While AWS services such as API Gateway can use client certificates for mutual TLS, IAM itself never validates a certificate as proof of identity for console or API access. Server certificates in IAM are used only to enable HTTPS on your custom domain, which authenticates the server, not the user. Thus, a certificate cannot substitute for an IAM password or access key.

MFA token

Why it fails: An MFA token provides a one-time code that must be combined with a primary credential—either a password for console sign-in or an access key for programmatic requests—to complete authentication. AWS treats MFA as an additional security factor designed to protect against credential theft, not as a standalone authentication method. While IAM policies can require MFA as a condition, the token itself never initiates an authenticated session. Therefore, an MFA token alone cannot authenticate an IAM user.

SSH key pair

Why it fails: SSH key pairs are primarily used to authenticate to EC2 instances over SSH, not to the AWS account itself. Although IAM supports uploading SSH public keys for use with AWS CodeCommit over SSH, this is a service-specific repository authentication mechanism, not a general IAM user authentication credential. An SSH key pair does not sign AWS API requests or allow console access. Therefore, it is not a valid way to authenticate an IAM user to AWS.

AWS Config

Why it fails: AWS Config tracks resource configuration changes and evaluates compliance against rules, but its purpose is not to analyze IAM resource policies for cross-account access. You could write a custom Config rule to inspect a policy document, but that requires custom logic and doesn't provide the automated, comprehensive external-entity analysis that IAM Access Analyzer performs. Config is a compliance and change-management tool, not a policy-analysis tool.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor offers checks for cloud security best practices, such as IAM root access, MFA on root account, open security groups, and public S3 buckets, but it does not analyze individual policy documents for complex cross-account grants. It might tell you a bucket is publicly accessible, but it won't identify that a specific IAM role policy grants read/write to a specific external account ID. Trusted Advisor lacks the granular policy-level analysis that IAM Access Analyzer provides, so it cannot satisfy this review requirement.

Amazon Macie

Why it fails: Amazon Macie is a data visibility and security service that discovers sensitive data (PII, credentials, etc.) in S3 buckets using machine learning and pattern matching. It doesn't evaluate IAM policies or resource policies to determine whether external principals have access; it inspects the data content itself. Therefore, while Macie could alert you to the presence of sensitive data in a bucket, it wouldn't tell you that a bucket policy grants DeleteObject to an external account.

The EC2 instance is in a VPC that has a VPC endpoint for CloudTrail, but the endpoint policy denies logging.

Why it fails: There is no VPC endpoint for CloudTrail; CloudTrail is a public AWS service, and API calls to CloudTrail are made over the internet or through AWS PrivateLink only for supported services, of which CloudTrail is not one. VPC endpoint policies apply only to endpoints that exist, so a policy denying CloudTrail logging is meaningless. CloudTrail logs management events independently of the caller's network path, so VPC configuration cannot cause individual API calls to be filtered out.

CloudTrail trail is not configured to log data events for EC2.

Why it fails: CloudTrail data events are an optional category that captures object-level activity for supported services such as S3, Lambda, and DynamoDB; EC2 is not a supported data event source. EC2 API calls like `RunInstances` or `DescribeInstances` are classified as management events, not data events. Enabling or disabling data events for EC2 is not a valid configuration, so a missing data-event setting cannot explain absent read-only EC2 API calls.

The IAM role used by the EC2 instance has a permissions boundary that excludes cloudtrail:PutLogEvents.

Why it fails: The IAM role attached to an EC2 instance governs only what that instance is allowed to call; CloudTrail's logging is performed by the CloudTrail service itself, which uses its own service-linked role to deliver logs. A permissions boundary on the instance role cannot prevent CloudTrail from recording API calls made by that instance, and there is no valid `cloudtrail:PutLogEvents` action in IAM (the correct action for log delivery is `logs:PutLogEvents`). Therefore, this configuration would not cause missing read-only entries.

The VPC Flow Logs service does not support cross-account delivery.

Why it fails: VPC Flow Logs do support cross-account delivery to S3, so this claim misstates the service's capability and cannot explain the failure. It is tempting because cross-account delivery does require the bucket policy and KMS key policy to grant the log-delivery principal access, which is the actual area to check.

CloudTrail must be enabled in the source account for Flow Logs to work.

Why it fails: Flow Logs publish to S3 independently of CloudTrail, so enabling a trail in the source account changes nothing about delivery. It is tempting because CloudTrail is the other major audit-log source and also writes to S3, making it the correct dependency when centralising API activity logs rather than network flow records.

The S3 bucket policy is missing a condition for source account.

Why it fails: A source-account condition is optional; the bucket policy already grants the delivery principal permissions, so its absence does not block delivery. Source-account conditions are tempting because they harden bucket policies against confused-deputy access, and would be the right addition when restricting which accounts may write.

Enable MFA delete on the S3 bucket that stores CloudTrail logs.

Why it fails: MFA delete is an S3 bucket setting that requires a second factor to permanently delete object versions or suspend versioning, which can help protect log files at the storage layer. However, it does nothing to prevent a user with cloudtrail:StopLogging or cloudtrail:DeleteTrail permissions from disabling the trail itself; those calls are made to the CloudTrail API, not to S3. Therefore, while MFA delete adds a layer of security for the log data, it falls short of the required control for trail configuration.

Apply an SCP to the management account to prevent disabling CloudTrail.

Why it fails: SCPs apply to all IAM principals in member accounts but explicitly do not apply to the management account, which remains exempt from any SCP restrictions. Since the management account is typically used to configure CloudTrail centrally and holds elevated permissions, attempting to attach an SCP to it would have no effect. Thus, this approach fails to protect the trail from administrators of the management account, making it an incorrect solution.

Create an IAM role for CloudTrail with permissions to write logs only.

Why it fails: An IAM role with write-only permissions for CloudTrail is a least-privilege practice for the service's own access, but it only governs what a single role can do. It does not revoke or limit the permissions of other IAM users or roles that may have administrative rights to stop or delete the trail. The role's existence is irrelevant to preventing account admins from calling cloudtrail:StopLogging, so it cannot satisfy the requirement.

Enable AWS CloudTrail data events for the Lambda function.

Why it fails: CloudTrail data events for a Lambda function record invocation metadata, such as which caller invoked the function and when, but they do not alter or restrict the function's execution role permissions. Enabling data events gives you forensic visibility after an unauthorized action occurs, making it a detective control rather than a preventive one. It cannot stop a Lambda function with an over-privileged role from making destructive AWS API calls, so it does not address the root cause of excessive permissions.

Attach a service control policy (SCP) that denies all actions except those explicitly allowed.

Why it fails: An SCP attached to the organization root or AWS account imposes a permission guardrail on every principal in that account, including human users, other Lambda functions, and AWS services; it cannot be scoped to one individual function. A blanket 'deny all except allowed' SCP would also require explicitly allow-listing every legitimate AWS service for the entire account, which is operationally unsustainable and would block critical actions. Because the SCP restricts the entire account rather than the function’s execution role, it fails the requirement to secure exactly the one Lambda function.

Place the Lambda function inside a VPC with no internet access.

Why it fails: Placing a Lambda function in a VPC with no internet route prevents it from reaching public internet destinations, but it does nothing to limit the API actions available through the function's IAM execution role. The function can still invoke AWS services through VPC interface endpoints, and the VPC configuration itself has no effect on IAM authorization. As a result, an over-privileged role remains over-privileged; network isolation is a separate concern from identity-based permission boundaries.

The Effect is set to Allow, which is too permissive.

Why it fails: The Effect line is correctly set to Allow because that is the only way to grant the application permission to call PutObject. Changing it to Deny would actively block every write request, including legitimate ones that include the required ACL header. The policy already applies least privilege by using a Condition that constrains allowed requests to those with bucket-owner-full-control, so Allow is not too permissive.

The policy does not allow server-side encryption.

Why it fails: Server-side encryption is a separate concern from the policy that governs access; the policy's lack of an encryption reference does not cause the failure. IAM policies cannot 'allow' encryption—they only allow or deny S3 actions, optionally conditioned on encryption headers. If encryption were required, the bucket would likely have a default or the application would need to send x-amz-server-side-encryption, but that isn't related to the x-amz-acl condition that is actually rejecting the request.

The resource ARN is incorrect; it should be arn:aws:s3:::my-log-bucket/*.

Why it fails: The resource ARN shown in the policy is already appropriate: it targets the AWSLogs/ prefix where the logs are written, e.g., arn:aws:s3:::my-log-bucket/AWSLogs/*. Using my-log-bucket/* would merely broaden scope to all objects, not fix the denial, because S3 would still refuse the request due to the missing ACL header. S3 resource ARNs for objects always end with /*, so the provided ARN is syntactically and semantically correct.

An internet gateway is attached to the VPC and a default route points to it.

Why it fails: An internet gateway (IGW) is a bidirectional device: if the subnet's route table had a default route pointing to an IGW, the subnet would no longer be private, and the instance would be both reachable from and able to reach the internet for IPv4 and IPv6. That would violate the observed outbound-only behavior, because the IGW forwards unsolicited inbound traffic just as readily as outbound. Egress-only connectivity for IPv6 requires an egress-only internet gateway, not an IGW.

A VPC endpoint for S3 is configured.

Why it fails: A VPC endpoint for S3 (whether gateway or interface type) provides private connectivity only to the S3 service prefix, not to the general internet. It works via route table entries for the S3 prefix (gateway endpoint) or via an ENI in the subnet (interface endpoint), neither of which establishes a default path to arbitrary internet hosts. Therefore, while an S3 endpoint could enable specific S3 API calls, it cannot explain general outbound internet traffic from the instance.

A NAT gateway is configured in a different availability zone.

Why it fails: A NAT gateway is IPv4-only and cannot forward IPv6 traffic, so it cannot be the mechanism behind egress-only IPv6 internet access. Additionally, if a NAT gateway were being used—even one placed in a different availability zone—it would appear as a target in the subnet's route table for the default IPv4 destination. If the route table shows no NAT gateway target and the traffic is IPv6, this option is definitively ruled out.

Add a rule to block cross-site scripting (XSS) attacks.

Why it fails: Cross-site scripting (XSS) and SQL injection are distinct vulnerability classes: XSS injects client-side script into web pages, while SQL injection manipulates backend database queries. AWS WAF offers separate managed rule groups for each, and the XSS detection rules will not match SQLi payloads like UNION SELECT or OR 1=1. Adding an XSS-specific rule would therefore leave the SQLi attack path unaffected.

Add a rate-based rule to limit requests per IP.

Why it fails: A rate-based rule imposes a cap on the number of requests from a single IP address over a fixed time window, typically to mitigate brute-force or DDoS-style high-volume attacks. SQL injection is often executed in a single, carefully crafted request, or via low-volume targeted attempts, so an attacker can easily stay under the rate threshold. Therefore, this control does not inspect request content and would not block the SQLi payload.

Add a geographic match rule to block traffic from specific countries.

Why it fails: A geographic match rule allows or blocks requests based on the country derived from the request's source IP, commonly used to restrict access to certain regions. It operates entirely on geolocation metadata and performs no content inspection, so it cannot differentiate benign requests from SQLi patterns. Since SQL injection can originate from any geographic area, including the company's own country, geo-blocking is not a valid countermeasure.

Use the AWS account root user for incident response actions to ensure full permissions.

Why it fails: Root user credentials are shared, long-lived, and typically lack fine-grained audit attribution, making them an unsafe choice for routine response actions. If an attacker rotates the root keys or enables virtual MFA, you can lose account recovery access; root also cannot be scoped by IAM policies. Pre-provisioned break-glass IAM roles with MFA, short-lived credentials, and a managed policy grant the necessary permissions while preserving traceability.

Store all evidence in an S3 bucket with public read access for easy sharing.

Why it fails: Public read access on an evidence S3 bucket can leak host logs, disk snapshots, or memory dumps containing customer data or secrets, creating a secondary breach and ruining legal admissibility. Evidence must remain in a private bucket with S3 Block Public Access enabled, SSE-KMS encryption, versioning, and an Object Lock policy to maintain integrity and chain of custody. Sharing is done through presigned URLs or controlled replication to authorized accounts.

AWS Config

Why it fails: AWS Config is a service that records and evaluates configuration changes to resources like EC2 security groups, IAM policies, and VPC settings. While it can help identify misconfigurations or drift that might have contributed to a compromise, it does not capture or inspect actual network traffic flows or packet payloads. Thus, it cannot provide the raw network data needed for deep investigation of a suspected breach.

AWS Network Firewall

Why it fails: AWS Network Firewall is a stateful managed firewall that inspects traffic at the VPC level using Suricata-based rules, and can generate alert logs via Amazon S3, CloudWatch, or Kinesis. However, its primary function is to allow or deny traffic based on policy; it does not provide full packet capture or a deep packet capture repository for retrospective forensic analysis. While it may log flow details or intrusion alerts, it is not designed to mirror raw traffic for a separate analysis tool.

Amazon Inspector

Why it fails: Amazon Inspector is a vulnerability management service that continuously scans workloads for software vulnerabilities and network reachability issues, producing risk scores based on CVEs and the Common Vulnerability Scoring System. It evaluates the security state of a resource but does not ingest or retain live network traffic, so it cannot be used to examine the contents of communications that occurred during an incident. For forensic packet analysis, a packet-capture mechanism would be required.

AWS CloudTrail

Why it fails: AWS CloudTrail is an audit service that records management and data-plane API activity, such as which principal made an API call, the source IP, and the request parameters. During a compromise, CloudTrail can reveal credential misuse or anomalous API sequences, but it does not analyze network flows or apply IP reputation scoring to outbound connections. Therefore, CloudTrail alone cannot tell you that an EC2 instance is communicating with a known malicious IP; it lacks the traffic visibility and threat-intelligence enrichment required for that specific detection.

VPC Flow Logs

Why it fails: VPC Flow Logs capture metadata about IP traffic reaching and leaving an elastic network interface, including source and destination addresses, ports, and protocol. They are passive logs with no built-in threat-intelligence context, so they do not identify whether a destination IP is known to be malicious. To detect communication with a malicious IP, you would need to export these logs to Athena and join them against an external reputation list, making VPC Flow Logs a raw telemetry source rather than a managed detection service that generates findings.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor inspects your AWS environment against best-practice checks for cost optimization, performance, security, and service limits. It does not ingest network traffic, monitor runtime behavior, or consult external threat intelligence to flag IP reputation. Because it is a policy-based advisory tool, Trusted Advisor cannot detect an active compromise involving outbound calls to a known malicious IP.