Refer to the Exhibit Practice Questions

The user is denied access only if the bucket policy also denies access.

Why wrong: The IAM policy itself contains an explicit Deny, and that is sufficient to block the request. AWS authorization does not require a bucket policy to also deny access; an explicit deny in any applicable identity-based policy always overrides any allow from resource-based policies. Therefore, the user is denied regardless of what the bucket policy says.

The user can download the object because the Deny statement only applies to 's3:*' actions, not s3:GetObject.

Why wrong: The statement 's3:*' is a wildcard that matches every S3 action, including s3:GetObject. In IAM policy evaluation, an action set with a wildcard covers all action strings that begin with the specified prefix. Consequently, the Deny statement explicitly applies to s3:GetObject, and this explicit deny overrides the Allow statement, so the user cannot download the object.

The user can download the object because the Allow statement grants s3:GetObject on the bucket.

Why wrong: While the Allow statement does grant s3:GetObject, IAM authorization uses a default-deny model and applies explicit denies with higher precedence. When any statement in an applicable policy explicitly denies the action and resource in question, that deny overrides all allowances, including those from bucket-level allows. As a result, the Allow statement cannot grant access because the explicit Deny takes precedence.

The KMS key policy does not grant access to the developer's IAM user.

Why wrong: This is incorrect because the key policy includes the default statement allowing the root account, which does grant access to IAM users via their IAM policies.

The KMS key policy specifies 'kms:*' which is too broad and causes a conflict.

Why wrong: This is incorrect. `kms:*` is a permissive wildcard and does not cause conflicts; it actually grants all actions.

The developer's IAM policy uses 'Resource' with the full key ARN but the key policy requires a different format.

Why wrong: This is incorrect. The resource format in IAM policies can be the full key ARN, and the key policy does not require a different format.

The secret is not marked as AWSCURRENT.

Why wrong: The `AWSCURRENT` label indicates the current version of the secret. The command output explicitly shows `VersionStages: ["AWSCURRENT"]`, confirming that the retrieved secret value is indeed the current one. Therefore, the issue is not that the secret lacks the `AWSCURRENT` stage, but rather how the application handles the *content* of that current secret.

The CLI command should have used the --secret-string parameter.

Why wrong: The `get-secret-value` command is designed solely for retrieving a secret's value, not for setting it. The `--secret-string` parameter is specifically used with commands like `create-secret` or `update-secret` to provide the actual secret content to be stored in Secrets Manager. Using `--secret-string` with `get-secret-value` would result in a CLI error, indicating an invalid parameter for the operation.

The secret ID is incorrect.

Why wrong: If the `secret-id` provided in the AWS CLI command were genuinely incorrect or referred to a non-existent secret, the `aws secretsmanager get-secret-value` command would have failed. Such a failure would typically manifest as an error message, such as `ResourceNotFoundException`. Since the command successfully executed and returned a `SecretString`, the specified secret ID was valid and correctly identified the target secret.

Add an S3 bucket policy allowing the Lambda function's ARN to write objects.

Why wrong: An S3 bucket policy grants cross-account access or applies to anonymous principals, but here the Lambda function and bucket reside in the same AWS account, so resource-based policies are unnecessary; the correct mechanism is an IAM execution-role policy attached to the Lambda function. This option is tempting because bucket policies are the standard way to authorise writes from external accounts or unauthenticated callers, and would be correct if the function belonged to a different AWS account.

Add a policy statement to LambdaExecutionRole allowing 's3:*' on 'arn:aws:s3:::my-app-bucket'.

Why wrong: This option is incorrect because it violates the principle of least privilege and uses an imprecise resource ARN. Granting 's3:*' provides permissions for all S3 actions, far exceeding the requirement to simply write objects, which is poor security practice. Furthermore, specifying 'arn:aws:s3:::my-app-bucket' as the resource only grants permissions on the bucket itself, not on the objects *within* it, meaning 'PutObject' operations would still fail.

Add a KMS key policy to allow the Lambda function to use a customer managed key.

Why wrong: This option is irrelevant to the problem statement unless the S3 bucket is specifically configured for Server-Side Encryption with AWS KMS (SSE-KMS). By default, S3 buckets use S3-managed encryption (SSE-S3) or no encryption, neither of which requires the uploader to have explicit permissions on a KMS key. A KMS key policy would only be necessary if the Lambda function needed to encrypt or decrypt objects using a Customer Managed Key.

Add a new statement with a different Principal.

Why wrong: Adding a new statement with a different Principal would not resolve the issue of allowing multiple specific IP ranges for the *existing* access pattern. The current statement likely uses Principal: "*", indicating broad access for authenticated users, which is not the part of the policy that needs modification. The problem lies in the Condition block's handling of aws:SourceIp, and introducing another principal would only create a separate access rule, not fix the IP restriction for the intended users.

Change the Condition to aws:SourceIp: "203.0.113.0/24".

Why wrong: Modifying the Condition to exclusively specify aws:SourceIp: "203.0.113.0/24" would restrict access solely to that particular network. This change would inadvertently deny access from the 192.0.2.0/24 network, which is also required. The objective is to permit access from *both* specified IP ranges, and this option only allows one, thus failing to meet the complete requirement.

Remove the Condition block entirely.

Why wrong: Removing the entire Condition block would eliminate the IP address restriction, allowing access to the S3 bucket from any IP address globally. While this would technically permit access from both 192.0.2.0/24 and 203.0.113.0/24, it introduces a significant security vulnerability by removing a critical layer of network perimeter control. This approach is generally not recommended as it broadens access far beyond the intended scope.

Change the Lambda runtime to Python 3.9 which includes requests

Why wrong: AWS Lambda runtimes, including Python 3.9, are designed to be lean and only include essential libraries like `boto3` and `urllib` by default. Third-party libraries such as `requests` are not pre-installed in the execution environment. This design choice ensures smaller runtime images and faster cold starts, requiring developers to explicitly bundle external dependencies rather than relying on the runtime to provide them.

Use the 'urllib' library instead of 'requests'

Why wrong: While the `urllib` library is a standard Python module available in all Lambda runtimes and can perform HTTP requests, it is generally less convenient and user-friendly than `requests`. Developers often prefer `requests` for its simpler API, automatic JSON handling, and robust error management, which significantly streamlines web interactions. Replacing `requests` with `urllib` would require rewriting existing code and sacrificing the ergonomic benefits that `requests` provides, which is not what the developer intends.

Install the 'requests' library using pip in the Lambda console

Why wrong: Attempting to install the `requests` library using `pip` directly within the Lambda console or during function execution is not a viable solution. The Lambda execution environment's file system is read-only for the function's code and dependencies, preventing persistent package installations at runtime. Dependencies must be pre-packaged with the deployment bundle or provided via a Lambda Layer before the function is invoked, as the console does not facilitate dynamic package management.

Remove the MyQueue resource.

Why wrong: Removing the MyQueue resource is not the fix because SQS queue names are scoped to the account and region, whereas the failure in this CloudFormation stack comes from the S3 bucket name already being taken in the global S3 namespace. The queue is not involved in the S3 AlreadyExists error, and deleting it would only remove a valid resource without changing the bucket's name collision, so the stack would still fail.

Remove the VersioningConfiguration from the bucket.

Why wrong: The VersioningConfiguration on the bucket is just a configuration subresource that controls whether multiple versions of objects are kept; it has no bearing on the bucket's globally unique name. Removing it does not free the existing bucket name or change how S3 performs name resolution, so the stack will still fail with the same BucketAlreadyExists error and may also lose intended versioning behavior.

Set SqsManagedSseEnabled to false.

Why wrong: SqsManagedSseEnabled is an SQS-specific property that toggles server-side encryption using SQS-managed keys; it is entirely unrelated to S3 bucket name registration. Setting it to false would only disable encryption on the SQS queue, not alter the S3 bucket's name or make it globally unique, so the CloudFormation deployment will continue to fail on the S3 resource with the original naming conflict.

The policy does not allow ec2:DescribeImages.

Why wrong: This is incorrect because the IAM policy shown in the exhibit already grants ec2:DescribeImages, so CloudFormation can freely resolve the AMI ID referenced in the template. The failure occurs later in the deployment sequence, when CloudFormation attempts to call iam:PassRole to assign an instance profile to the EC2 instance. A deny for ec2:DescribeImages would produce an "unauthorized to perform ec2:DescribeImages" error, not the PassRole authorization error you're seeing. Therefore, this option is not the cause of the failure.

The policy does not allow ec2:RunInstances.

Why wrong: This is incorrect because the policy explicitly includes ec2:RunInstances, so CloudFormation has the necessary permission to create the instance. The deployment never reaches the point of successfully executing RunInstances because the earlier iam:PassRole call fails. If ec2:RunInstances were missing, the error would name ec2:RunInstances as the unauthorized action, not iam:PassRole. Thus, a lack of RunInstances permission cannot explain the observed failure.

The policy does not allow ec2:TerminateInstances.

Why wrong: This is incorrect because ec2:TerminateInstances is not called during initial stack creation; it is only needed if CloudFormation must clean up resources during stack deletion or a rollback triggered after a failure. The deployment failed during the create phase at the iam:PassRole authorization check, before any instance was launched and before termination could be relevant. Even if TerminateInstances were denied, that would not cause this error on a fresh deployment, so this option is irrelevant to the question.