Hard Difficulty Questions

Amazon Inspector and Amazon CloudWatch Logs.

Why wrong: Amazon Inspector is a vulnerability management service that scans compute workloads for software vulnerabilities and unintended network exposure; it does not generate or record S3 API call history. While CloudWatch Logs can store logs, Inspector has no S3 API event log integration, so this combination cannot provide the auditable record of who called which S3 operation.

Amazon GuardDuty and Amazon CloudWatch Logs.

Why wrong: Amazon GuardDuty is a threat detection service that analyzes telemetry from existing sources, including CloudTrail management events, VPC Flow Logs, and DNS logs, to identify suspicious activity; it does not independently log every S3 API call. GuardDuty might detect anomalies in S3 access, but the underlying audit events still originate from CloudTrail, so pairing GuardDuty with CloudWatch Logs omits the authoritative audit log needed to satisfy this requirement.

AWS Config and Amazon CloudWatch Logs.

Why wrong: AWS Config tracks configuration changes to AWS resources, such as an S3 bucket policy, lifecycle rule, or encryption setting, and evaluates them against rules; it does not capture API-call-level detail for every S3 operation. CloudWatch Logs can store emitted logs, but AWS Config does not emit a feed of S3 API calls, so this combination falls short of auditing all S3 API activity.

Create an IAM user for the vendor and attach a policy that allows access to 'vendor-bucket'.

Why wrong: Creating an IAM user for the vendor distributes long-lived access keys or passwords that can be leaked and require manual rotation. Because the vendor's staff become an IAM principal inside your account, you lose visibility into which specific third-party action was performed, and you cannot use cross-account trust to restrict the source account. Roles using temporary credentials are the intended, more secure mechanism.

Use an SCP to deny access to all S3 buckets except 'vendor-bucket'.

Why wrong: A service control policy applies to every principal in the AWS account, including AWS services and your own employees, not just the vendor's assumed role. Denying all S3 buckets except 'vendor-bucket' would likely break other applications that need other buckets and could block S3 service-linked operations. SCPs are also organization-level guardrails that do not grant the vendor any ability to assume the role, so they cannot by themselves provide the required cross-account access.

Create a new AWS account for the vendor and use VPC peering.

Why wrong: Creating a separate AWS account for the vendor and peering VPCs adds network connectivity between VPCs, but VPC peering does not confer IAM permissions to call S3 APIs, and S3 is a global service that does not require network peering to access. This solution is unnecessarily complex, still requires you to create credentials for the vendor, and does not scope access to the specific 'vendor-bucket' object space. A cross-account IAM role directly addresses the access control requirement without new account infrastructure.

The launch fails because the SCP denies all RunInstances actions.

Why wrong: The SCP does not deny all RunInstances actions; its Deny statement is scoped with a condition key such as ec2:InstanceType, so the denial only applies when the instance type is not t2.micro. A blanket deny of RunInstances would block every launch, including t2.micro, which contradicts the conditional structure described in the scenario. Therefore, the failure of the t2.small launch is not caused by a wholesale denial of the RunInstances action.

The launch succeeds because the SCP allows t2.micro only.

Why wrong: This option contains a fatal contradiction: saying the SCP 'allows t2.micro only' actually means it denies every other instance type, including t2.small, so the launch should not succeed. SCPs do not confer a positive allow for a specific resource; they act as a guardrail that either permits or blocks actions based on their statements. Since the developer launched t2.small, the accurate outcome is a denial, not a success, making this option incorrect.

The launch succeeds because SCPs do not apply to developers.

Why wrong: SCPs apply to all principals in an account, including developers, so the deny on non-compliant instance types blocks the t2.small launch regardless of the user's role. This option is tempting because IAM permission boundaries or resource-based policies can exempt developers from certain restrictions, but SCPs operate at the account level as a guardrail that cannot be overridden by any IAM entity.

Use AWS KMS to create a new key and re-encrypt all data. Then revoke the old key.

Why wrong: AWS KMS is a separate key management service that cannot revoke or invalidate key material stored in an AWS CloudHSM cluster; the application directly uses CloudHSM, so a KMS key revocation has no effect on the compromised HSM-backed key. Even if data were re-encrypted under a new KMS key, any data still encrypted with the old HSM key would remain exposed, and the copied backup is not remediated. Thus, this option does not address the actual compromise and is ineffective.

Change the HSM administrator password and the crypto user passwords.

Why wrong: Changing the HSM administrator and crypto user passwords only alters the credentials used to authenticate to the HSM; it does not modify or invalidate the cryptographic key material that was copied from the backup. The copied key material remains valid and usable in any HSM that accepts it, because CloudHSM keys are protected by the HSM's master keys, not by the cluster's user passwords. Therefore, password rotation leaves the compromised keys fully functional and the data still exposed.

Delete the HSM cluster and create a new one. Restore the backup from a known good time.

Why wrong: Deleting the HSM cluster and creating a new one does not delete the backups stored in the backup service; those backups are independent of the cluster and can be restored to any HSM by someone with access. Restoring from a 'known good time' is flawed because the backup that the employee copied may contain the same key material, and if it is from before the compromise, it still contains the keys that are now compromised. The correct action is to delete the backup and rotate the keys, not to rebuild the cluster from backups that may still include the exposed key material.

The finding type is not specified in the pattern.

Why wrong: A CloudWatch Events event pattern is a filter, not a schema, so any field you omit, including `detail.type`, is treated as a wildcard. GuardDuty publishes a single event detail-type, `GuardDuty Finding`, for every detection, while the `type` field inside detail varies by finding family. Leaving out `detail.type` simply matches all finding types and does not prevent the rule from firing.

CloudTrail is not enabled in the account.

Why wrong: GuardDuty generates findings from its own telemetry, such as VPC Flow Logs, DNS query logs, and threat intelligence, and it publishes those findings to the default CloudWatch Events/EventBridge bus. CloudTrail records API activity for governance and is not a required dependency for GuardDuty finding generation or for CloudWatch Events to receive those findings. Whether CloudTrail is enabled has no effect on whether a GuardDuty finding event is delivered to a CloudWatch Events rule.

The Lambda function does not have permission to be invoked by CloudWatch Events.

Why wrong: A missing Lambda invocation permission would matter only after the event pattern has matched, because EventBridge must successfully resolve the rule and then invoke the target with the appropriate resource-based policy. If the pattern does not match the GuardDuty event, the rule never attempts to invoke the Lambda in the first place, so no permission error is observed. A permission problem would instead surface as an invocation failure in CloudWatch rule metrics, not as a complete absence of triggers while GuardDuty events are being published.

The security group egress rule is blocking return traffic.

Why wrong: 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 wrong: 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 wrong: 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 role 'ec2-full-access' does not exist in the account

Why wrong: If the role did not exist, the error would be different, typically about the role not being found.

The policy is missing a condition key such as ec2:InstanceProfile

Why wrong: While a condition can be used, it is not required; the error is about PassRole, not RunInstances.

The user does not have permission to call ec2:RunInstances

Why wrong: The policy allows ec2:RunInstances on all resources, so that is not the issue.

aws:SourceVpc

Why wrong: The aws:SourceVpc condition key matches the ID of the VPC from which the request originates, and it is only available when the request comes through a VPC endpoint. Like aws:SourceVpce, it is a network topology condition that does not carry any information about the IAM principal. Hence, it cannot be used to control access based on a specific IAM role; it merely identifies the VPC, which may contain many roles and workloads.

aws:username

Why wrong: The aws:username condition key is only populated for requests made by an IAM user; it is absent for requests made by an IAM role or via temporary security credentials from an assumed role. Since the requirement is to allow a specific IAM role, aws:username cannot be used because it does not provide the role's identifier. In fact, for role-signed requests, aws:username is null, so the condition would never match.

aws:SourceVpce

Why wrong: The aws:SourceVpce condition key restricts access based on the ID of the VPC endpoint (e.g., vpce-12345678) that received the request. It is a network-origin condition, not an identity condition, so it cannot indicate which IAM role is allowed. While it can be useful to limit traffic to a particular endpoint, it is completely unrelated to the principal's ARN and therefore does not satisfy the requirement to restrict access by role.

Use AWS Config rules to detect users without MFA.

Why wrong: AWS Config rules such as iam-user-mfa-enabled assess whether each IAM user has an MFA device configured and report the account's compliance status, but they are purely detective controls. They do not intercept authentication requests or prevent a user from logging in without MFA; they only generate evaluation results and can trigger remediation actions that are not native to the login flow. Relying solely on Config leaves the unprotected access vectors open until manual or automated remediation completes, so this option does not ensure MFA enforcement for console access.

Apply an SCP that requires MFA for console access.

Why wrong: SCPs in AWS Organizations apply to all principal requests for account-level AWS service API actions, but they do not govern the IAM console login event itself. The login request is processed by IAM's authentication system before any SCP is evaluated, and the SCP cannot inspect the user's MFA session state to deny the initial sign-in. At best, an SCP could deny subsequent API actions when MFA is absent, but it cannot prevent a non-MFA user from completing console authentication, making it an incomplete and incorrect solution.

Configure an IAM password policy to require MFA.

Why wrong: The IAM password policy exclusively governs password requirements such as length, rotation, and complexity, and its MFA-related setting only mandates that users provide MFA when changing their own passwords. It does not apply to the initial console login process, so a user could still sign in without MFA as long as they know their password. Thus, configuring the password policy to require MFA for password changes has no effect on console access enforcement.

The user does not have a service-linked role for EC2.

Why wrong: Service-linked roles are predefined IAM roles that AWS services assume to call other AWS services on your behalf. For EC2, service-linked roles (such as AWSServiceRoleForEC2) are used for features like Spot, dedicated hosts, or managed instances, but a standard RunInstances call does not require one. The absence of a service-linked role does not produce an UnauthorizedOperation error when launching an EC2 instance; it would instead cause a specific prerequisite failure only if the requested feature depends on that role.

The IAM policy lacks a `Resource` element specifying which instances can be launched.

Why wrong: IAM policies for EC2 actions can use a wildcard in the Resource element, such as "Resource": "*", which is valid for RunInstances because the instance is created as part of the request. If the policy did require a specific resource, the error would typically be an explicit deny or a failure to match the resource ARN, but the common cause of an UnauthorizedOperation here is the condition key evaluating the requested region. Lacking a Resource element alone would not cause UnauthorizedOperation because a missing Resource defaults to the action's required resource, and RunInstances can be authorized with a wildcard.

The user is trying to launch an instance type that is not supported in us-east-1.

Why wrong: An unsupported instance type in us-east-1 would trigger an error like "InvalidParameterValue: The requested configuration is currently not supported" or "UnsupportedOperation", not an UnauthorizedOperation. UnauthorizedOperation specifically indicates that the IAM principal lacks permission to perform the action in the evaluated context, which is a policy or condition failure, not a capacity or regional availability issue. Therefore, the instance type being unsupported has no bearing on the authorization error described in the CloudTrail logs.

"Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}

Why wrong: This would allow only that IP range, but the requirement is to deny outside IPs; using IpAddress in an Allow statement would work, but the question asks for conditions to include in a Deny context.

"Condition": {"StringLike": {"aws:Referer": "https://corporate.internal/*"}}

Why wrong: This option relies on the HTTP Referer header, which is an application-layer value supplied by the client's browser or tool and is trivially spoofed, stripped, or altered by proxies and privacy extensions. AWS has long discouraged Referer-based access control because it does not provide a trustworthy identity, network, or transport guarantee. Moreover, even if a request has the correct Referer, it could still originate from an insecure HTTP connection or an unintended IP, so this condition does not meet the requirement of restricting sensitive data access to authenticated network sources.

The CloudWatch Logs log group retention policy is set to 0 days.

Why wrong: A CloudWatch Logs retention policy controls how long log events are retained after they are written, not whether a log group or log stream is created. The value 0 days is not a valid retention period in AWS (minimum is 1 day), and even an immediate-expiration policy would only delete events that already exist. Since no log streams are present at all, the problem occurs before any log event is written, which is unrelated to retention.

The Lambda function is not configured with a CloudWatch Logs log group.

Why wrong: The exhibit explicitly shows a log group in the describe-log-groups output that matches the Lambda function's expected name, such as /aws/lambda/your-function-name. Lambda automatically uses this convention, and the log group's existence confirms that the function is associated with it, either from automatic creation during an earlier invocation or manual setup. The statement that no log group is configured is directly contradicted by the evidence in the exhibit.

The Lambda function timed out before writing logs.

Why wrong: A Lambda timeout terminates the execution after a configured duration, but log events are written to CloudWatch Logs as they are generated during the invocation. Even if the function times out, a log stream would typically be created with partial logs or a timeout error message. The complete absence of any log stream indicates the logging runtime never successfully wrote, which points to an authorization failure rather than an execution-duration problem.

Manually encrypt each snapshot with a separate KMS key.

Why wrong: Manually encrypting each snapshot with a separate KMS key is both unnecessary and not a native backup feature: snapshots inherit the encryption configuration of the source database, so the original CMK already secures them. While you could create a snapshot copy with a different KMS key, doing so is optional and would not replace the automatic encryption already in place.

Create a new KMS key and assign it to the backup configuration.

Why wrong: RDS does not expose any backup-level KMS key assignment; the same customer master key that encrypts the database instance is the key used for its automatic backups and snapshots. Creating a new KMS key and attaching it to a 'backup configuration' is not a supported action, and it would add no benefit because the existing key already encrypts all backup data.

Enable encryption on the RDS instance after creation.

Why wrong: Encryption at rest on an RDS MySQL instance cannot be enabled after the instance is provisioned; AWS only applies this setting during creation or when you restore a snapshot into a new encrypted instance. Therefore, in this scenario, the instance is already encrypted, and attempting to enable encryption later would be invalid and unnecessary.

The source IP address is from an AWS service.

Why wrong: The source IP address 203.0.113.5 is a public IP from a non-allocated TEST-NET-3 documentation range, not an AWS-owned CIDR. AWS service traffic would originate from known AWS service IP ranges, and the user agent of the event is `console.amazonaws.com`, which points to a user operating in the AWS Management Console. Therefore, this IP is almost certainly the user's own public egress address, not an AWS service.

The trail was created using the AWS CLI.

Why wrong: The CloudTrail event's `userAgent` field is `console.amazonaws.com`, which is the user agent string used when an action is performed in the AWS Management Console. The AWS CLI and SDKs send user agents like `aws-cli/2.x` or `botocore/1.x`, not `console.amazonaws.com`. Hence, the trail was likely created by a user clicking through the console, not via programmatic CLI access.

The trail is a single-region trail.

Why wrong: The event's request parameters explicitly contain `isMultiRegionTrail: true`, which directly contradicts the claim that it is a single-region trail. `isMultiRegionTrail` is a boolean field in the CreateTrail API call that indicates whether the trail delivers log files from all AWS regions or only the region where it was created. Since it is `true`, the trail is multi-region, so this statement is incorrect.

Create a new IAM role that can only be assumed by instances in the VPC.

Why wrong: Creating an IAM role whose trust policy only allows instance profiles in the VPC to assume it does not constrain the network path that S3 API requests take after the credentials are obtained. An instance in the VPC could still use those credentials to access the bucket via an internet gateway or NAT, completely bypassing the VPC endpoint. The trust policy governs only who can assume the role, not the source address or endpoint of subsequent requests, so it cannot enforce the required VPC-endpoint restriction.

Add a condition in the IAM role policy using aws:SourceVpce.

Why wrong: Adding an aws:SourceVpce condition to an IAM role's permission policy is misplaced because identity-based policies control what actions a principal is allowed to take, not under what network conditions a resource will accept requests. While global condition keys can appear in IAM policies, AWS specifically recommends putting VPC endpoint conditions in the resource-based S3 bucket policy to gate access at the resource boundary. Placing it in the role policy also risks conflicting with other policies and does not directly protect the bucket if another principal already has access.

Add a condition in the bucket policy using aws:SourceIp with the VPC CIDR range.

Why wrong: Using aws:SourceIp with the VPC CIDR range is ineffective because the aws:SourceIp condition key is not reliably evaluated for requests that traverse a VPC endpoint; the endpoint changes the network path, and AWS documents that SourceIp should not be used to restrict VPC endpoint traffic. The source IP seen by S3 may not match the instance's private IP or the VPC CIDR, leading to either over-permissive or over-restrictive access. AWS recommends using aws:SourceVpce or aws:SourceVpc instead to accurately identify traffic coming from a VPC endpoint.

The KMS key used for encryption was disabled during the backup window.

Why wrong: A disabled KMS key would actually prevent an already-encrypted DB instance from being read or decrypted, and RDS backups generated from an encrypted instance remain encrypted with that same key until the key is disabled — at which point snapshot or restore operations would fail. It would never cause the automated backups to be silently stored without encryption. If the instance was never encrypted, no KMS key is involved in the first place, so this cannot explain unencrypted backups.

The automated backups are stored in an unencrypted S3 bucket.

Why wrong: RDS automated backups are stored in AWS-managed S3 infrastructure, but you do not control or choose the underlying S3 bucket or its encryption settings. When a DB instance has encryption at rest enabled, RDS automatically encrypts its automated backups and snapshots using the same KMS key before storing them; when the instance is unencrypted, the backups are unencrypted by inheritance, not because of an S3 bucket configuration. Therefore, pointing to an unencrypted S3 bucket misidentifies responsibility: the encryption state of the backups is determined entirely by the source DB instance, not the S3 bucket.

The automated backup encryption setting was turned off separately.

Why wrong: There is no separate RDS configuration option, parameter, or toggle to turn off encryption for automated backups independently of the DB instance. Encryption at rest is a single setting applied when the database instance is created, and that setting automatically governs the encryption of all associated backups, snapshots, and read replicas. The idea of separately disabling backup encryption misunderstands RDS's design — backups cannot have a different encryption state than their source instance.

Switch to using AWS Managed Rules for IP reputation lists.

Why wrong: AWS Managed Rules for IP reputation lists contain threat-intelligence ranges from third-party sources and block requests solely on IP address reputation, not on the actual request characteristics or your application's traffic profile. A legitimate user who happens to share an IP range with known abuse (e.g., a NAT egress or a cloud provider block) will still be blocked, making it a poor substitute for an application-aware rate limit. Additionally, managed IP lists are static between updates and don't adapt to your baseline, whereas a count-based custom rule can be tuned with your own metrics.

Increase the WAF rate-based rule threshold to allow more requests.

Why wrong: Simply raising the rate-based threshold widens the bandwidth of allowed requests, so while it may reduce false positives, it also lets more attack traffic pass under the ceiling. The correct approach is to first quantify normal traffic with count mode and then set the threshold at a statistically defensible point above that baseline. Without this data, any threshold increase is arbitrary and can leave the application more exposed to a distributed burst that your original threshold would have stopped.

Reconfigure the ALB idle timeout to a higher value.

Why wrong: The ALB idle timeout governs how long the load balancer keeps an HTTP connection open after the last request; it has no bearing on how WAF inspects requests, nor on the per-IP rate counters that feed a rate-based rule. Changing this setting does not alter whether a request is considered part of a burst or whether it matches an IP reputation block, so it cannot mitigate false positives. The WAF engine evaluates traffic before the ALB forwards it, so request-level blocking decisions are unaffected by connection timeout values.

In the KMS key policy, allow the application role to perform kms:Decrypt.

Why wrong: Allowing kms:Decrypt in the key policy for the application role without a condition grants that role the ability to decrypt any ciphertext with the CMK from any context, including direct KMS API calls outside DynamoDB. This violates the least-privilege requirement to limit the key's use to DynamoDB operations. You must pair the permission with kms:ViaService to scope it to DynamoDB; otherwise the key is effectively usable service-agnostically.

Use a KMS grant to allow the application to use the key.

Why wrong: A KMS grant is a mechanism for allowing a principal to use a key when the principal can't or shouldn't have direct IAM permissions; it is often used for temporary access or to allow AWS services to use a key on behalf of a user. However, grants cannot include service-specific conditions like kms:ViaService, so the grant would give the application role unfettered kms:Decrypt, enabling direct KMS calls. Because the goal is to constrain the role to decryption only through DynamoDB, a grant is not an appropriate solution.

Attach an IAM policy to the application role allowing dynamodb:GetItem and kms:Decrypt.

Why wrong: An IAM policy permitting dynamodb:GetItem and kms:Decrypt on the application role is necessary but not sufficient because KMS authorization requires both an IAM policy and a resource-based key policy to allow the role. If the key policy does not explicitly allow the role (or a grant), the implicit deny in KMS will block the decrypt operation. Furthermore, attaching such an IAM policy does not include a kms:ViaService condition, so it would permit decryption outside DynamoDB as well if the key policy did allow it.

Change the private subnet's route table to have a default route to the Internet Gateway instead of the NAT gateway.

Why wrong: Changing the private subnet's route table to point its default route to an Internet Gateway instead of the NAT gateway would make the subnet effectively public, allowing instances to have a direct, routable path both to and from the internet. Combined with the security group's current inbound HTTP rule, the web server would immediately begin accepting unsolicited HTTP traffic from any source, completely defeating the purpose of the private subnet. This change would increase exposure rather than reduce it, so it is not a valid fix.

Replace the NAT gateway with a NAT instance and configure it to block inbound traffic.

Why wrong: Replacing the NAT gateway with a NAT instance and configuring it to block inbound traffic is unnecessary and misdiagnoses the root cause, because both a NAT gateway and a properly configured NAT instance already discard unsolicited inbound packets. The web server's vulnerability stems entirely from the overly permissive security group rule, not from any inbound-packet-forwarding capability of the NAT device. Furthermore, substituting a NAT instance introduces significant operational overhead—such as managing a single point of failure and disabling source/destination checks—without addressing the actual security group misconfiguration, so the issue would remain.

Add a network ACL to the private subnet that denies inbound HTTP traffic.

Why wrong: Adding a network ACL to the private subnet that denies inbound HTTP is problematic because network ACLs are stateless: denying inbound traffic on port 80 would also block the return packets for any outbound HTTP requests the web server initiates, requiring a perfectly mirrored outbound allow rule to function correctly. Even with such a rule, the NACL operates at the subnet boundary and provides a broad, coarse-grained control that can inadvertently affect other instances in the same subnet. The stateless nature makes this change error-prone and less precise than the security group fix, which is stateful and scoped directly to the web server instance.

Manually reset each user's password to a strong password.

Why wrong: Manually resetting each user's password is an administrative one-off action that does not modify the account-level password policy or enforce future compliance. Even if you supply a strong temporary password, the user can immediately change it—unless your password policy already rejects weak passwords—and there is no guarantee that every user across the account is covered in a timely manner. This approach is not operationally feasible for large accounts and does not force existing users to adopt the new strong-password standard.

Enable 'Allow users to change their own password' in the policy.

Why wrong: Enabling 'Allow users to change their own password' in the IAM password policy simply grants users the self-service permission to update their password; it does not create any obligation or mechanism to change an existing weak password. Users may continue using their current credentials indefinitely without ever setting a strong password, so this setting alone fails to meet the requirement that all IAM users must use strong passwords. A corresponding expiration or forced-reset setting is necessary.

Re-apply the password policy to each user.

Why wrong: The IAM password policy is defined at the AWS account level, not per user, so 're-applying' it to individual users has no meaning and no effect on their current password state. Because the policy automatically governs all IAM users once set, existing passwords remain in force until they expire or are explicitly reset by an administrator. This action addresses no underlying problem and cannot compel users with weak passwords to rotate them immediately.