Refer to the Exhibit Practice Questions

The action is allowed because the first statement allows StopInstances

Why it fails: Deny overrides allow regardless of order.

The action is allowed because the resource is '*'

Why it fails: The Deny applies to all resources.

The action is denied only if the user is not using MFA

Why it fails: The condition does not mention MFA.

The security group has no outbound rules.

Why it fails: AWS security groups are stateful and include a default allow-all outbound rule unless it is explicitly removed; the exhibit shows that rule present. It is tempting to assume outbound is empty, but the default egress entry appears in the output, so the group does have outbound rules.

The security group allows SSH access from any IP address.

Why it fails: The rule shown specifies a particular source CIDR or security group rather than 0.0.0.0/0, so SSH is not open to every address. It is tempting because port 22 rules are frequently misconfigured to any source, but the exhibit's actual CidrIp or source group restricts the range.

The security group is associated with multiple EC2 instances.

Why it fails: The describe-security-groups output lists inbound and outbound rules only; instance associations appear in describe-network-interfaces or describe-instances output, not here. It is tempting because security groups are commonly attached to instances, but this command's JSON contains no instance or network-interface membership data.

Add a network ACL rule to deny SSH inbound from 0.0.0.0/0.

Why it fails: Network ACLs are applied at the subnet boundary, not to a single instance. Adding a deny rule for inbound SSH from 0.0.0.0/0 would block SSH for every resource in that subnet, including other instances that may need legitimate SSH access. Additionally, network ACLs are stateless, so this approach is broader than necessary and could also require careful return-traffic rule management. The security engineer should remediate at the instance level instead of impacting the whole subnet.

Disassociate the public IP address from the instance.

Why it fails: Disassociating the public IP address from the instance eliminates all direct internet access to that instance, not just SSH. If the instance is hosting a web server, inbound HTTP traffic destined for that public IP would also fail. This approach breaks legitimate HTTP services and may not even resolve SSH exposure if an Elastic IP or other routing still provides access. The correct objective is to selectively close the SSH port while preserving HTTP, so removing the public IP is an overly broad action.

Modify the security group to add a deny rule for SSH from 0.0.0.0/0.

Why it fails: Security groups do not support deny rules; they are exclusively allow-list filters. Attempting to add a deny rule for SSH from 0.0.0.0/0 is invalid and cannot be implemented in the AWS console or API. To stop SSH access, you must remove the allow rule, because security groups implicitly deny all traffic that does not match an explicit allow rule. Therefore, the only valid security group change is deletion of the permissive SSH rule, never the addition of a deny statement.

The CloudTrail log is incomplete; both VPCs exist.

Why it fails: CloudTrail records all management API calls, but a discrepancy between two CreateVpc events and a single VPC does not mean the log is missing data. If both VPCs were truly present, the describe-vpcs call in the evidence would return both VPC IDs, because there is no pagination or filtering mentioned that would omit one. The most direct explanation is not an incomplete log but a resource that was created and then deleted; assuming incomplete logging ignores the concrete current-state evidence.

Both VPCs were created successfully and still exist.

Why it fails: The claim that both VPCs still exist directly contradicts the describe-vpcs result, which lists only one VPC ID. AWS resource IDs are globally unique and immutable, so if the second VPC existed, its VPC ID would have to appear in the current output; it does not. The current state is the source of truth for existence, and the missing ID proves the second VPC is not alive at investigation time.

The user admin only created one VPC; the second event is a duplicate.

Why it fails: CloudTrail duplicating a single request would preserve the same event/request ID (or show the same VPC ID) in subsequent entries, but the two events have different event IDs and produce different VPC IDs. Each distinct event ID represents an independent API call, and a successful CreateVpc returns a newly created VPC ID. Thus the evidence shows two actual create operations, not one event being logged twice; the duplicate explanation ignores the unique IDs and the missing VPC.

The user can access objects because an Allow with conditions grants access by default.

Why it fails: AWS IAM never grants access by default; any request starts with an implicit deny. A statement such as Allow s3:GetObject with a condition only applies when the condition evaluates to true, so the presence of an Allow with conditions is not sufficient by itself. Since the request does not meet the IP condition, the Allow does not match, so the user cannot access the object.

The user will be denied access because the policy does not allow the action explicitly.

Why it fails: This policy does contain an explicit Allow for the action, so saying it fails because the action is not allowed is factually wrong. The denial is not caused by a missing permit but by the policy's condition block: the action is allowed only under certain conditions. Because the source IP is outside the permitted ranges, the Allow statement is filtered out and the implicit deny takes effect.

The user can access objects because the condition for SecureTransport is met.

Why it fails: The SecureTransport condition is indeed part of the statement, and if the user made the request over HTTPS that condition is true. However, IAM condition blocks apply all provided condition keys with logical AND; every key must match before the Allow is granted. The source IP condition is not met, so the request is denied despite the satisfied SecureTransport condition.

The bucket does not have versioning enabled.

Why it fails: Bucket versioning is a data-protection feature that retains previous object versions, but it has no influence on access control decisions. Even if versioning were enabled, the bucket would still be publicly accessible because the bucket policy grants public read access and BlockPublicPolicy is not configured to block that policy. The security issue here is specifically the unblocked public policy, not the lack of versioning.

The bucket policy grants public read access to the bucket, which overrides the PublicAccessBlock configuration.

Why it fails: Incorrect. The bucket policy does grant public read access, but the statement that it overrides PublicAccessBlock is false. In S3, PublicAccessBlock settings are evaluated first and can block public policies if BlockPublicPolicy is enabled. The issue is that BlockPublicPolicy is missing, allowing the policy to take effect.

The bucket policy uses an incorrect resource ARN.

Why it fails: An incorrect resource ARN in the bucket policy would either trigger a policy validation error or inadvertently attach the policy to a different bucket, yet in this scenario the policy is successfully applied to the target bucket. The real misconfiguration is the absence of BlockPublicPolicy, which permits any public bucket policy to be accepted and enforced. Correcting the ARN alone would not resolve the public exposure; you must enable BlockPublicPolicy to prevent such policies from becoming effective.

The source IP address 203.0.113.5 is from a known malicious IP range.

Why it fails: The IP address 203.0.113.5 belongs to TEST-NET-3 (203.0.113.0/24), a range reserved by RFC 5737 specifically for documentation and examples, so it is not a real internet-routable address. CloudTrail records sourceIPAddress as a descriptive field, but a documentation/test range cannot be treated as a known malicious range from threat intelligence. The presence of this IP is therefore not the security-relevant finding in this log entry.

The API call was made from the AWS CLI, which may indicate a compromised access key.

Why it fails: The log entry's userAgent is console.amazonaws.com, which indicates the request was made through the AWS Management Console, not the AWS CLI. CLI calls would have a userAgent such as aws-cli/2.x or botocore/1.x and require configured access keys. Because the entry clearly points to the console, the premise that the API call came from the CLI is false, and no conclusion about a compromised access key can be drawn from this field.

The user JohnDoe did not use multi-factor authentication (MFA) for this API call.

Why it fails: CloudTrail log entries for API calls do not include a standard MFA-status field; while some console sign-in events may contain additionalEventData with mfaUsed, that information is not present in this particular event. Whether JohnDoe authenticated with MFA cannot be determined from the fields shown in this entry, such as eventName, userIdentity, sourceIPAddress, and userAgent. Therefore this statement is unsupported and is not the security-relevant observation for this log entry.

Delete the root user account.

Why it fails: The AWS account root user cannot be deleted; it persists for billing and account recovery, so this action is technically impossible. It is tempting because removing a risky credential seems decisive, but the correct hardening is disabling root access keys and enforcing MFA on the root user.

Disable the root user password and require all logins via IAM users.

Why it fails: The root user password cannot be disabled; root credentials remain recoverable for account-level tasks, so this control cannot be applied. It is tempting because forcing IAM users appears to eliminate root exposure, but the achievable hardening is MFA on root plus removing root access keys.

Enable IAM Access Analyzer to detect and alert on root user activity.

Why it fails: IAM Access Analyzer evaluates resource policies for external access, not CloudTrail authentication events, so it cannot detect or alert on root console logins. It is tempting because it is an IAM security service, but root activity monitoring requires CloudWatch alarms or EventBridge rules on CloudTrail.

The security group egress rule is blocking return traffic.

Why it fails: The egress rule cannot be blocking return traffic because it is configured to allow all outbound traffic. Security groups are stateful, so after the inbound SSH connection is accepted, response traffic from the instance to the client's ephemeral port is automatically permitted irrespective of egress rules. Since the egress rule is permissive and stateful tracking covers the reply packets, this option is not the reason for the SSH failure.

The network ACL's default deny rule (32767) is blocking all inbound traffic.

Why it fails: The network ACL's default deny rule numbered 32767 is only a catch-all for traffic that has not already matched an earlier explicit rule. Inbound rule 100 in the exhibit explicitly allows SSH from all source IP addresses, and because network ACL rules are evaluated in ascending order, that allow match is applied before flow ever reaches the default deny. Therefore the catch-all rule is not blocking the inbound SSH connection.

The network ACL inbound rule for SSH is misconfigured, denying all traffic.

Why it fails: This is incorrect because the network ACL inbound rule for SSH is actually configured with an Allow action for all source IPs, not a Deny action. A network ACL is stateless, so the rule simply permits TCP port 22 from any source, which would allow rather than block the engineer's SSH attempt. The SSH failure therefore must be caused by a different layer, namely the security group's source restriction.

The flow log is not active; it shows ACTIVE, so that's not the issue.

Why it fails: The flow log's status is shown as ACTIVE, which means it is successfully capturing traffic for its attached resource. The problem is not that the flow log is inactive; rather, it is scoped to a different resource than the subnet being examined. Since the status is healthy, the root cause must lie in the flow log's resource scope, not its operational state.

The flow log is configured to deliver to CloudWatch, but the log group name is incorrect.

Why it fails: The CLI output displays the CloudWatch Logs destination along with the log group name, and that log group matches the filter pattern used in the query. The flow log is correctly configured to send logs to that log group, so the log group name is not the issue. The real issue is that the flow log is attached to the VPC, not to the subnet, so no subnet-specific logs are being generated.

The IAM role does not have permissions to deliver logs for subnets.

Why it fails: The IAM role listed in the flow log configuration is the same role used for VPC flow log delivery, and that role already has the required permissions to publish to CloudWatch Logs. For subnet flow logs, the identical IAM role is acceptable because the delivery mechanism and permissions are at the VPC level and apply equally to subnet-level flow logs. Therefore, IAM permissions are not the cause of the missing subnet logs.

Delete the 'admin' user and create a new user with limited permissions.

Why it fails: Deleting the IAM user and recreating a new user with limited permissions is an unnecessarily destructive and disruptive action. It removes the user's credentials, MFA devices, access keys, and any other attached policies, and it does not address the root cause: the AdministratorAccess policy is still attached to the original principal. The same least-privilege result can be achieved by simply detaching or replacing the policy on the existing user, preserving all other user attributes. Deleting the user also risks breaking any processes, scripts, or roles that reference that user's ARN.

Modify the AdministratorAccess policy to deny all actions.

Why it fails: AdministratorAccess is an AWS managed policy, and AWS does not allow customers to modify or edit managed policies — you can only create customer managed policies or attach/detach AWS managed ones. Even if modification were possible, rewriting it to deny all actions would be a global change affecting every principal that has the policy attached, and it would not be scoped to the 'admin' user. A proper fix is to replace the attached policy with a customer managed read-only policy, not to alter an AWS provided policy that other users or roles may depend on.

Attach a permissions boundary that denies all actions.

Why it fails: A permissions boundary is a guardrail that defines the maximum permissions a principal can receive, but it does not remove or replace the existing AdministratorAccess policy attached to the user. If the boundary is later detached or changed, the user's full administrator access would be restored, so this is not a durable remediation. Moreover, a boundary that denies all actions would effectively lock out the user rather than grant them read-only access, which is not the stated goal. The correct approach is to remove the excessive policy, not to layer conflicting policies on top of it.

The policy does not include ec2:RunInstances in the Action list

Why it fails: Omitting ec2:RunInstances from the Action list produces an implicit deny, whereas the simulation reports explicitDeny, meaning a Deny statement matched. It is tempting because missing actions are the usual cause of access failures, and would be correct if the result had shown implicitDeny.

The policy allows ec2:Describe* but the action ec2:RunInstances is not a Describe action

Why it fails: A missing ec2:RunInstances allow yields an implicit deny, not the explicitDeny shown, so the Describe wildcard is irrelevant to the result. It is tempting because action-name mismatches are a common cause of failed calls, and would be correct if the output had reported implicitDeny instead.

The policy uses a Resource of '*' which does not include the required resources

Why it fails: A Resource of '*' matches every resource, so it cannot produce an explicitDeny; explicit denies come from a Deny statement matching the action. It is tempting because wildcards often cause unintended matches, and would be correct if the policy used a narrower ARN that excluded the target instance.

The TrafficType is set to ALL, which captures too much data and causes throttling.

Why it fails: TrafficType ALL is a valid, intended configuration for VPC Flow Logs and simply captures both accepted and rejected traffic. Flow log records are batched and pushed to CloudWatch as a single PutLogEvents call, so a high volume of records does not cause API throttling or dropped logs. If logs are missing, the fault lies in the delivery role or destination, not in the traffic filter setting.

The flow log is attached to an ENI instead of a subnet.

Why it fails: Attaching a flow log to an ENI is fully supported; flow logs can be created at the VPC, subnet, or network interface level. The ENI attachment granularity does not disable or throttle delivery, and the service will publish records for that interface. Therefore, the attachment target cannot explain missing logs; you must inspect the IAM delivery role and the log group configuration instead.

The flow log destination is set to CloudWatch Logs but the log group is encrypted with KMS.

Why it fails: A KMS-encrypted CloudWatch Logs log group is a valid destination for VPC Flow Log delivery, because CloudWatch Logs transparently uses the configured key when writing log events. Encryption alone does not block PutLogEvents or alter flow log publication; at most, a restrictive key policy could deny the delivery role's kms:Encrypt/GenerateDataKey actions. Since the symptom is no logs, the missing PutLogEvents permission in the delivery role is the actionable root cause.

The request is allowed because the IP address matches the allow statement.

Why it fails: Although the request originates from an IP that matches the allow statement's condition, that allow is not conclusive. The bucket policy also contains a separate explicit deny statement for requests using HTTP (or lacking HTTPS), and in IAM/S3 policy evaluation, an explicit deny takes precedence over any allow. Therefore the IP match does not make the request allowed.

The request is denied because the IP is not in the allowed range.

Why it fails: This answer is incorrect because the IP address does fall within the range specified in the allow statement; it is the transport protocol that is the problem. The request is being denied because the condition in the deny statement (a non-HTTPS/HTTP request) is satisfied, not because the IP is out of range. In fact, the IP is valid, so this reasoning misidentifies the actual cause of the denial.

The request is allowed because the user is using a valid IP.

Why it fails: This answer ignores the effect of the deny statement. While the IP address may be within the allowed range and thus satisfies the allow condition, the request is still subject to the explicit deny for HTTP requests. In AWS policy evaluation, an explicit deny takes precedence over any allow, so using a 'valid IP' (one allowed by the allow statement) does not grant access when the protocol condition is violated.

The policy has no effect because there is no Allow statement.

Why it fails: Explicit Deny statements in IAM and S3 bucket policies are always evaluated and take precedence over any Allow statement, whether that Allow exists in the same policy or another policy. The absence of an Allow statement does not render a Deny inert; in fact, the default IAM behavior is to deny everything not explicitly allowed. Thus, this policy definitely has an effect by blocking HTTP requests.

All requests over HTTPS are allowed.

Why it fails: This statement does not contain an Allow effect, so it grants no permissions whatsoever. HTTPS requests are simply not matched by the Deny condition, but they still require an independent Allow from an IAM policy, bucket policy, or bucket ACL. Without such an allow, HTTPS requests are implicitly denied by the default S3/IAM fallback. Therefore it would be incorrect to claim that the policy allows all HTTPS traffic.

All requests to the bucket are denied.

Why it fails: The Deny statement is narrowly scoped by the aws:SecureTransport condition: it triggers only when the boolean value is "false". Requests using HTTPS are not denied because the condition evaluates to false for them, so the policy does not apply to secure connections. While the absence of an Allow statement might result in implicit denial for some principals, the explicit Deny in this policy cannot be characterized as denying all requests to the bucket, because it excludes HTTPS by design.