Hard Difficulty Questions

Custom regex pattern set

Why it fails: A custom regex pattern set lacks the contextual analysis of SQL injection and XSS payloads that AWS WAF’s managed SQL injection and XSS rule groups provide; regex can only match literal string patterns, so it cannot detect encoded, obfuscated, or variant attack vectors that bypass static signatures. It is tempting because regex offers flexibility for blocking arbitrary patterns in query strings, and would be correct for blocking a known, fixed string like `DROP TABLE` that does not require contextual decoding.

Rate-based rule

Why it fails: A rate-based rule tracks the number of requests from a single client IP within a configurable time window and triggers an action once the count exceeds a set threshold, which is ideal for mitigating volumetric attacks like credential stuffing, account takeover, or layer 7 DDoS. It does not inspect the content of the request body or query string, so although it might incidentally slow down an automated attack, it cannot distinguish a benign request from those containing SQL injection or XSS payloads.

Geographic match rule

Why it fails: A geographic match rule evaluates the country of origin of the requesting IP address and applies an allow or block action based on that location, typically used for regional compliance or to block traffic from high-risk areas. This rule never examines the request payload or parameters, so it provides no detection capability for SQL injection or XSS; an attacker in a permitted country can still exploit the vulnerability, and a blocked malicious request is blocked only because of its origin, not its content.

No, because the key policy does not allow the user to decrypt.

Why it fails: No, because the key policy is not the reason the request fails. The exhibit shows only an IAM policy granting kms:Decrypt on the key; whether the key policy separately permits the user is immaterial here since the request is denied earlier by the IAM policy's encryption context condition. In AWS KMS, both IAM policy and key policy must allow the action, but a condition mismatch in the effective IAM policy already produces an explicit deny, so blaming the missing key policy misidentifies the actual cause.

Yes, because the user has kms:Decrypt permission on the key.

Why it fails: Yes, because the user has kms:Decrypt permission on the key is incorrect because permission alone is insufficient—AWS KMS evaluates all conditions in the applicable IAM policy before granting the action. Even with kms:Decrypt listed on the key, the condition element restricts decryption to requests that present an encryption context of department=finance; a request using department=hr is denied despite the permission. Thus, the presence of kms:Decrypt does not override a failed condition check.

Yes, if the user also has kms:DescribeKey permission.

Why it fails: Yes, if the user also has kms:DescribeKey permission is incorrect because kms:DescribeKey is an independent read-only action that returns key metadata and does not authorize or influence kms:Decrypt. Adding kms:DescribeKey would not satisfy the encryption context condition in the IAM policy, nor would it alter AWS KMS's authorization decision for decryption. Therefore, even with DescribeKey, the request would still fail due to the mismatched encryption context.

Use AWS Config rules to detect accounts without CloudTrail and trigger a remediation via Systems Manager Automation.

Why it fails: An AWS Config rule such as cloudtrail-enabled only evaluates the configuration state of resources after they exist. When a new account is added, the rule reports noncompliant, and the Systems Manager Automation document runs only after that detection, leaving an unlogged window. This strategy is reactive: it does not provision or enable CloudTrail before activity occurs, and it requires the automation document, IAM roles, and permissions to already be set up in every account. Config's periodic evaluations add further delay, so it cannot guarantee continuous coverage from the moment an account joins the organization.

Use an SCP to deny cloudtrail:StopLogging and cloudtrail:DeleteTrail actions.

Why it fails: A service control policy (SCP) is a permission boundary that denies or restricts API actions across all principals in an account, but it cannot initiate any API call. Denying cloudtrail:StopLogging and cloudtrail:DeleteTrail would prevent an existing trail from being stopped or deleted, which is a protective guardrail rather than an enabling mechanism. Because SCPs never create or configure resources, they leave the original requirement unmet unless CloudTrail was already deployed by another mechanism. Also, an SCP alone cannot ensure that a trail is configured to log to a central bucket or track management events.

Create an AWS Lambda function that runs periodically to check and enable CloudTrail in each account.

Why it fails: A Lambda function that runs on a schedule is a custom, pull-based workaround that requires building cross-account IAM roles, writing code to iterate through accounts, and handling failures or throttling. If the function runs only periodically, there will be a gap between when an account is added and when the next invocation occurs, during which no CloudTrail logging is active. This also adds operational overhead for patching, managing permissions, and maintaining CloudWatch event rules, and it does not automatically deploy to new accounts unless you separately configure a trigger. It is inferior to CloudFormation StackSets, which natively handles deployment and drift without custom code.

Create a VPC endpoint for DynamoDB and associate it with the Lambda function.

Why it fails: A VPC endpoint for DynamoDB only establishes a private network path between your VPC and the DynamoDB service, bypassing the public internet. It does not, by itself, grant the Lambda execution role any permission to perform DynamoDB actions; IAM authorization is still enforced on every API call. Even if you attach the endpoint to the Lambda function's VPC configuration, the function's role must explicitly allow actions like GetItem or Query on the table — otherwise the call fails with an AccessDenied error.

Attach the AWS managed policy AmazonDynamoDBFullAccess to the Lambda execution role.

Why it fails: AmazonDynamoDBFullAccess is an AWS managed policy that grants full administrative and data-plane access to all DynamoDB resources, including CreateTable, DeleteTable, Scan, and DeleteItem on any table in the account. Attaching it to the Lambda execution role violates the principle of least privilege, which is a fundamental security best practice and often a compliance requirement. If the Lambda function is compromised, an attacker could use these excessive permissions to delete or exfiltrate data from unrelated tables. A scoped custom policy should be used instead, allowing only the specific actions on the specific table.

Store the database access keys in the Lambda environment variables.

Why it fails: Storing database access keys in Lambda environment variables is insecure because it hard-codes long-term credentials that do not rotate automatically. These keys could be exposed through the Lambda console, environment variable retrieval APIs, or CloudWatch Logs if the function logs its configuration. Additionally, AWS Lambda already uses an execution role to obtain temporary security credentials via the instance/role credential provider chain, making long-term access keys unnecessary and counterproductive. This approach also breaks the recommended practice of using IAM roles for AWS service-to-service access.

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.

Configure CloudWatch Logs cross-account subscription to aggregate findings.

Why it fails: Configuring a CloudWatch Logs cross-account subscription is not the mechanism for enabling GuardDuty multi-account management. GuardDuty generates findings from each account's own threat-detection data sources (VPC Flow Logs, DNS, CloudTrail) and natively replicates those findings to the GuardDuty administrator account. A CloudWatch Logs subscription could be used for separate log aggregation, but it does not establish the administrative relationship that lets a master account view or manage member findings, and it cannot replace the required invitation/acceptance workflow.

Create an EventBridge rule to forward findings to the master account.

Why it fails: Creating an EventBridge rule to forward GuardDuty findings to the master account is an optional integration, not the required step for delegating GuardDuty administration. When a member account is properly linked through GuardDuty's native master-member model, findings are automatically copied to the master account's GuardDuty console without any EventBridge rule. An EventBridge rule could be used for downstream automation, such as triggering a remediation Lambda or streaming findings to a SIEM, but it does not create the administrative relationship and would be redundant for the purpose of central GuardDuty visibility.

aws iam get-account-authorization-details

Why it fails: The get-account-authorization-details call returns a verbose JSON object that enumerates all IAM users, groups, roles, policies, and their attached policy documents, including ARNs and trust policies. It does not include metadata about access key creation or last rotation dates, so you cannot derive credential age from this output. This command is designed for analyzing authorization relationships, not for auditing credential hygiene.

aws iam generate-service-last-accessed-details

Why it fails: generate-service-last-accessed-details creates a report about the last time an IAM entity attempted to access AWS services, returning a job ID that you must poll with get-service-last-accessed-details. This output provides access timeline information intended for least-privilege reviews, but it says nothing about credential rotation dates or how long access keys have existed. Therefore, it cannot identify whether a user's access key is overly old.

aws iam list-access-keys --user-name suspectUser

Why it fails: The list-access-keys command, when supplied a --user-name, lists the key IDs, statuses, and creation dates, so you could calculate a key's age manually. However, it only covers the one specified user and does not show whether the key has ever been used, nor does it provide an account-wide audit of all users or other credential types like passwords and signing certificates. It is not the right tool for a broad security review of access key age across an account.

The S3 bucket has default encryption enabled, which interferes with CloudTrail writes.

Why it fails: Default encryption on the destination S3 bucket does not interfere with CloudTrail writes. CloudTrail supports writing logs to buckets with default encryption, whether SSE-S3 or SSE-KMS, as long as the trail has the necessary decrypt permissions when KMS is used. Moreover, the absence or presence of default encryption affects object-at-rest encryption only, not the delivery path, so it cannot cause intermittent missing log files.

The S3 bucket has a Lifecycle policy that deletes objects prematurely.

Why it fails: A lifecycle policy can only act on objects that have already been written to the bucket, typically transitioning or expiring them after a defined number of days. Since CloudTrail delivers log files within minutes of activity, an expiration rule cannot delete objects before they are delivered without also deleting them after a delay, which would result in consistent, not intermittent, gaps. The intermittent nature of the problem points to a delivery-time issue rather than a post-storage deletion issue.

The CloudTrail trail in each account is not associated with an SQS queue, causing delivery failures.

Why it fails: CloudTrail does not use an SQS queue as part of its log delivery pipeline; it writes log files directly to S3 or to CloudWatch Logs, or it can stream to Kinesis Data Firehose for further transformation. SQS is only used if you integrate CloudTrail with event notifications via SNS, and even then it is for triggering downstream workflows, never for the log file delivery itself. Therefore, the absence of an SQS association cannot cause delivery failures or missing logs.

The user must be an IAM user in the same account as the role.

Why it fails: This is incorrect because the trust policy explicitly names principals from account 1, meaning the role is designed to be assumed cross-account. An IAM user in the same account as the role would be a different principal (likely from account 1, but the account of the user is not the defining factor). Cross-account role assumption is a common pattern: the IAM role resides in the trusting account, and the IAM user resides in the trusted account (account 1). The user's account location does not need to match the role's account; the trust policy establishes the allowed principal, so being in the same account is not a requirement.

The user must have an IAM policy that allows sts:AssumeRole.

Why it fails: While the user does need IAM permissions to call sts:AssumeRole (typically via an IAM policy attached to the user that allows sts:AssumeRole on the role ARN), the trust policy condition in question is specifically about MFA. The trust policy already grants the principal permission to assume the role (in the Principal element), and the identity policy is a separate authorization check. The option is incomplete and misleading: having an IAM policy that allows sts:AssumeRole is necessary but not sufficient, and it does not address the MFA condition that is the core requirement in the trust policy. The presence of the MFA condition means the user must also present a valid MFA token, which is not implied by merely having an allow policy.

The request must originate from a specific IP address range.

Why it fails: This is incorrect because the trust policy does not include any IP address restriction, such as 'aws:SourceIp' in a condition. IP-based restrictions would limit the origin of the request to a specific CIDR range, but the trust policy's condition is focused on MFA presence. Even if the request originates from any IP address, the MFA condition still applies. The absence of an 'aws:SourceIp' condition means there is no requirement for the request to come from a particular network, so this option is not a condition specified in the trust policy.

Use a CloudHSM key store and enable automatic rotation

Why it fails: CloudHSM key stores hold keys in single-tenant hardware, but AWS KMS does not support automatic rotation for asymmetric or custom key store keys; rotation must be manual. A customer-managed KMS key in the standard key store supports annual automatic rotation, which DynamoDB encryption accepts.

Use an AWS managed KMS key and enable automatic key rotation

Why it fails: AWS managed KMS keys rotate automatically every year, but they are owned by AWS, not the customer, so the requirement for a customer-managed key fails. A customer-managed KMS key in the standard key store satisfies both encryption and annual rotation requirements for DynamoDB.

Enable encryption on the existing DynamoDB table and use a customer-managed KMS key

Why it fails: Wrong: You cannot enable encryption on an existing DynamoDB table; you must create a new table.

Create a multi-region CloudHSM cluster

Why it fails: CloudHSM clusters are confined to a single AWS region and consist of HSMs deployed across Availability Zones within that region; there is no multi-region cluster construct. Attempting to configure a cluster spanning regions is not supported by the CloudHSM service. If cross-region resilience is required, you must back up the cluster and restore the backup to a separate cluster in another region.

Store the keys in a file on an encrypted EBS volume

Why it fails: Storing encryption keys in a file on an encrypted EBS volume moves the key material out of the tamper-resistant CloudHSM hardware into software, where it can be accessed by the OS and any privileged process. Even if the volume is encrypted at rest, the key is available in plaintext in memory during runtime and bypasses the HSM's non-exportability guarantees. This approach violates the fundamental requirement that keys never leave the HSM in a usable form.

Use AWS KMS to import the keys from CloudHSM

Why it fails: AWS KMS does not provide an operation to import key material directly from a CloudHSM; key material can only be imported into KMS using the import key material feature, which requires wrapping a plaintext key with a public key from a KMS key. CloudHSM keys are designed to be non-exportable—the service does not allow you to extract key material from an HSM—so there is no source plaintext available for import. The only integration between KMS and CloudHSM is a custom key store, which uses CloudHSM as the underlying storage for KMS keys rather than migrating existing CloudHSM keys into KMS.

The user’s access keys are expired.

Why it fails: Expiring credentials are detected during request signing; S3 returns an authentication error such as InvalidAccessKeyId or ExpiredToken before it evaluates any bucket policy statements. Because the developer is receiving a policy-based denial rather than a signature/auth failure, the access keys themselves must still be valid. Thus, expired keys cannot be the cause of this particular 403.

The IAM policy does not include s3:PutObjectAcl.

Why it fails: Uploading an object via the S3 API only requires s3:PutObject permission on the bucket/object; the caller does not need s3:PutObjectAcl. The PutObjectAcl permission is only invoked when you explicitly call the independent PutObjectAcl API to modify an object's ACL after upload, not during the upload itself. Therefore, missing PutObjectAcl would not block a simple put operation, and the error you are seeing comes from a different policy restriction.

The CLI is not using HTTPS.

Why it fails: The AWS CLI always uses HTTPS by default for S3 endpoints; you would have to deliberately configure an insecure HTTP endpoint, which is not a typical setup and often not permitted by S3. Moreover, if the transport were HTTP, the request could fail with a different error (e.g., SSL/connection issues) or still be processed; it would not cause the bucket policy to reject the request based on the Referer header. The root cause is the missing Referer condition, not the protocol.

Use AWS CloudTrail to automatically disable the IAM user's access keys.

Why it fails: AWS CloudTrail is a read-only auditing service that records API activity across your account, but it provides no native remediation or automation capabilities. It cannot directly disable IAM access keys; any key deactivation would require external tooling such as an EventBridge rule invoking Lambda. Relying on CloudTrail alone leaves the compromised credentials active and only produces a log entry for post-incident analysis, so it is not a valid automated response mechanism.

Create an AWS Config rule that checks for excessive API calls and revokes keys.

Why it fails: AWS Config is designed for resource compliance and configuration history, not for real-time API call monitoring or volumetric threat detection. A Config rule can evaluate whether resources conform to desired policies and optionally run SSM Automation remediation, but it does not natively analyze CloudTrail logs for excessive API calls or trigger key revocation based on API behavior. Attempting to use Config for this purpose would require custom, inefficient workarounds and still would not provide the immediate, event-driven response needed for a credential compromise.

Enable Amazon GuardDuty to automatically revoke compromised credentials.

Why it fails: Amazon GuardDuty is an intelligent threat detection service that uses machine learning to identify suspicious activity, such as unusual API calls or credential usage, and generates findings. However, GuardDuty does not perform any automatic remediation actions—it only detects and alerts; you must build a separate response mechanism (e.g., EventBridge + Lambda) to act on those findings. Enabling GuardDuty alone will not disable compromised IAM keys, so this option is incorrect for an automated key-revocation requirement.

Amazon CloudWatch Metrics for the instance

Why it fails: Amazon CloudWatch Metrics provide only numerical time-series data, such as CPU utilization, disk I/O, and network throughput, which are aggregated into 1-minute or 5-minute periods. Even with detailed monitoring, they do not capture login attempts, executed commands, or file modifications—the forensic evidence needed to identify how an attacker gained access. While metrics can highlight an anomaly like a CPU spike, they are far too coarse to reveal the attack vector, making them unsuitable for incident investigation.

AWS Config configuration history

Why it fails: AWS Config tracks configuration changes to AWS resources over time, such as security group rule modifications, instance type changes, or tag updates, and maintains a timeline of those states for compliance auditing. While it could show that a security group was opened to the internet hours before the incident, it does not contain any authentication attempts, command execution, or attacker movement within the instance. Config history is therefore useful for understanding infrastructure evolution but cannot reveal the initial compromise vector or the attacker's actions on the host.

VPC Flow Logs

Why it fails: VPC Flow Logs capture metadata about IP traffic at the network interface level, including source and destination addresses, ports, protocols, and byte counts, but they do not perform deep packet inspection or payload analysis. A flow log might show a burst of connections from a suspicious IP, yet it cannot tell whether that traffic was a successful exploit, a brute-force login, or benign scanning. This lack of application-layer context means flow logs alone cannot prove maliciousness or identify the specific attack vector that compromised the instance.

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.

Use a Site-to-Site VPN connection between the VPC and the SaaS provider's on-premises network.

Why it fails: A Site-to-Site VPN requires a customer gateway device on the SaaS provider's side, which assumes the provider operates an on-premises network. Since the provider is an AWS-hosted SaaS application, it does not expose a customer gateway endpoint; instead it would expose an AWS PrivateLink endpoint service. Thus this option is architecturally invalid and cannot establish private connectivity to a VPC-based SaaS provider.

Create a VPC peering connection and use security groups to restrict traffic.

Why it fails: VPC peering connects two VPCs directly, but it does not encrypt traffic between them — packets traverse the AWS network without confidentiality protection at the network layer. Security groups are stateful firewalls that only filter allowed traffic; they do not provide encryption or prevent a provider from seeing the traffic. Additionally, VPC peering requires knowing the provider's VPC ID and is a one-to-one relationship, not the mechanism a SaaS provider uses to offer a service to many customers.

Use an AWS Transit Gateway with inter-region peering.

Why it fails: AWS Transit Gateway inter-region peering connects transit gateways in different AWS Regions, but it does not encrypt the traffic passing between those regions; the data is not protected at the network layer by default. Furthermore, inter-region peering requires the SaaS provider to create a transit gateway peering attachment, which is not how a multi-tenant SaaS service typically exposes connectivity. The provider would more likely publish a PrivateLink endpoint service rather than participate in a transit gateway peering topology.

The bucket policy changes were made through the AWS Management Console, which is not logged.

Why it fails: This is incorrect because AWS CloudTrail records management events regardless of whether they originate from the AWS Management Console, CLI, or SDKs. PutBucketPolicy is a management event for S3 and appears in CloudTrail when performed through the console. The actual reason no events seem to appear is that the command uses --max-results 1, which truncates the output to a single event.

The event is not logged because PutBucketPolicy is not supported by CloudTrail.

Why it fails: This is incorrect. PutBucketPolicy is a supported S3 control-plane (management) API and is logged by CloudTrail as a management event. S3 API calls such as PutBucketPolicy, DeleteBucketPolicy, and GetBucketPolicy are all tracked, so the absence of output is not due to lack of CloudTrail support. The command's --max-results parameter is what hides additional matching events.

The command is filtering by the wrong attribute.

Why it fails: This is incorrect because EventName is a valid LookupAttribute Key for the lookup-events operation, and PutBucketPolicy is an accurate event name for that API call. Other valid attribute keys include EventSource, Username, ResourceType, and ResourceName, but EventName is appropriate here. The filtering attribute is correct; the output is constrained by the maximum-results setting.

Use an SCP condition to restrict password policy changes to a specific Region.

Why it fails: IAM is a global service; password policy and other IAM actions do not have a Region dimension. An SCP condition key such as aws:RequestedRegion cannot match an iam:UpdateAccountPasswordPolicy request, so the condition would either allow all such actions or deny all of them, failing to enforce the minimum length.

Write an SCP that sets the password policy to require minimum length 12.

Why it fails: An SCP is a permission boundary that can only allow or deny actions; it cannot execute APIs or modify account configuration. To set a password policy, you must make the iam:UpdateAccountPasswordPolicy call itself, so writing an SCP that 'sets' the policy is syntactically impossible and functionally meaningless.

Set up CloudWatch alarms to notify when CloudTrail is modified or logs are deleted.

Why it fails: CloudWatch alarms are purely detective: they trigger a notification after a CloudTrail modification or log deletion has already occurred, leaving no mechanism to block the action. An attacker (or a compromised root user) could disable the alarm, delete the trail, and erase logs before an operator even sees the notification. This option fails to prevent the incident, so it cannot meet the requirement for a preventative control.

Use IAM policies in each member account to deny CloudTrail and S3 delete actions.

Why it fails: IAM policies are evaluated only for the IAM principal that assumes a role or user identity within a member account; the account root user, which has full administrative access, explicitly ignores IAM permission boundaries. Moreover, an IAM-based solution requires consistent deployment across every member account, and any account without the policy (or with a local administrator who can alter it) leaves CloudTrail and S3 vulnerable. Because root user activities are the highest-risk vector, this approach cannot truly prevent deletion of audit artifacts.

Apply an S3 bucket policy denying delete actions, and enable CloudTrail organizational trail.

Why it fails: An S3 bucket policy that denies s3:DeleteObject and s3:DeleteBucket protects the contents of the logging bucket from object-level deletion, but it does nothing to prevent an attacker from calling cloudtrail:StopLogging or cloudtrail:DeleteTrail. The organizational trail configuration remains fully manageable by any sufficiently privileged user (including root) in the management account, so the trail can be shut down before any new logs are written. Bucket policies alone do not shield CloudTrail's trail definition or logging activity, leaving a critical gap in the protective control.

Re-encrypt the snapshot with a customer managed key (CMK) in the target region

Why it fails: Re-encrypting the snapshot with a CMK in the target region is optional; you can restore the snapshot using the original key if it is available in the target region.

Store the encryption key in AWS CloudHSM in the target region

Why it fails: EBS uses KMS keys, not CloudHSM.

Share the snapshot with the target region using AWS RAM

Why it fails: RAM is for resource sharing, but encryption requires additional steps.