Refer to the Exhibit Practice Questions

The security group does not allow HTTP traffic.

Why it fails: The describe-instances exhibit contains no security group configuration details to evaluate, and even if the security group were misconfigured, a terminated instance has no running network stack at all, so a missing HTTP inbound rule is not a conclusion supported by the given output.

The instance does not have the correct Name tag.

Why it fails: Name tags are purely a labeling and organizational feature used for identification in the console and for resource filtering; an incorrect or missing tag has no effect on whether an instance can serve HTTP requests, and the exhibit shows the tag is present and correctly formatted regardless.

The instance does not exist.

Why it fails: The describe-instances command successfully returned a result for this instance ID, proving the instance record does exist within the account; if the instance truly did not exist, the API call would return an InvalidInstanceID.NotFound error instead of any output describing its state.

The template does not enable versioning on the bucket.

Why it fails: AWS S3 bucket versioning is an optional feature designed to keep multiple versions of an object in the same bucket, protecting against accidental deletions or overwrites. While highly recommended for data durability and recovery, its absence in a CloudFormation template will not prevent the successful creation of an S3 bucket. Therefore, this template omission is not a valid reason for deployment failure.

The bucket name must be in all lowercase letters.

Why it fails: AWS S3 bucket names must adhere to specific naming conventions, including being entirely in lowercase letters, not containing underscores, and being between 3 and 63 characters long. The provided bucket name, "myuniquebucket123", already satisfies the requirement of being all lowercase. Consequently, this statement incorrectly identifies a naming convention violation as the cause of the deployment issue.

The template does not specify a bucket policy.

Why it fails: An S3 bucket policy is an optional resource-based policy used to define access permissions for the bucket and its objects. While crucial for controlling access and often implemented for security best practices, a bucket policy is not a mandatory component for the initial successful creation of an S3 bucket via CloudFormation. Therefore, the absence of a bucket policy in the template would not cause the stack deployment to fail.

The user needs s3:PutObjectAcl permission

Why it fails: The `s3:PutObjectAcl` permission is specifically required only when an S3 upload operation explicitly attempts to set an Access Control List (ACL) on the new object, such as specifying a canned ACL like `bucket-owner-full-control`. For standard uploads where object ownership is enforced by the bucket policy or the object is owned by the uploading account, this permission is not necessary. Therefore, its absence does not inherently prevent a basic object upload.

The policy does not allow s3:ListBucket

Why it fails: The `s3:ListBucket` permission is used for listing the contents of an S3 bucket, such as retrieving a list of objects or common prefixes. This permission is entirely distinct from the `s3:PutObject` action, which is required for uploading new objects into a bucket. Therefore, the absence or presence of `s3:ListBucket` has no direct bearing on a user's ability to successfully upload an object.

The user does not have s3:GetObject permission

Why it fails: The `s3:GetObject` permission grants the ability to retrieve or download an object from an S3 bucket. While it is a common S3 action, it is completely separate from the `s3:PutObject` permission, which is necessary for uploading an object. The question specifically concerns an upload operation, making the user's `s3:GetObject` permissions irrelevant to the success or failure of that particular action.

The bucket will have versioning disabled because the rule conflicts.

Why it fails: This statement is incorrect. S3 Lifecycle rules that manage noncurrent versions, such as NoncurrentVersionExpiration, explicitly require S3 Versioning to be enabled on the bucket. These rules are designed to work *with* versioning, not conflict with it, by defining how older object versions are handled. Therefore, the presence of such a rule implies versioning is enabled and functioning correctly, not disabled.

Current versions are transitioned to another storage class after 30 days.

Why it fails: This statement is incorrect. The lifecycle rule described, NoncurrentVersionExpirationInDays, applies specifically to *noncurrent* object versions, not current ones. Furthermore, this rule specifies an *expiration* action, meaning deletion, rather than a *transition* action to move objects to a different storage class like S3 Glacier or S3 Standard-IA. A separate Transition action would be required to move current objects, and it would typically specify a target storage class.

Objects are automatically deleted after 30 days.

Why it fails: This statement is incorrect because the lifecycle rule specifically targets NoncurrentVersionExpirationInDays. This means only *noncurrent* versions of objects are subject to deletion after 30 days, not *all* objects or their *current* versions. Current versions of objects remain unaffected by this particular rule and will persist in the bucket unless a separate Expiration rule for current versions is defined.

The DynamoDB table is not encrypted with a KMS key.

Why it fails: If the DynamoDB table were not encrypted with a KMS key, or if it used an AWS owned key, a `KMSAccessDeniedException` would not be the specific error encountered. DynamoDB tables are always encrypted at rest, and this error explicitly points to a permission issue with a Customer Managed Key (CMK) during the decryption process required to retrieve data. The presence of a KMS-specific error indicates a CMK is actively in use.

The policy does not allow dynamodb:GetItem on the table.

Why it fails: The error message specifically indicates a `KMSAccessDeniedException`, not an access denied error for DynamoDB itself. If the IAM policy did not permit `dynamodb:GetItem`, the error would instead be a `DynamoDB:AccessDeniedException` or similar, preventing the operation from even reaching the KMS decryption stage. Therefore, the policy must allow `dynamodb:GetItem` for the KMS error to occur.

The DynamoDB table does not exist.

Why it fails: If the specified DynamoDB table did not exist, the API call would result in a `ResourceNotFoundException` from DynamoDB, not an access denied error related to KMS. The occurrence of a `KMSAccessDeniedException` implies that the table was successfully located and identified as being encrypted with a Customer Managed Key, but the subsequent attempt to decrypt its data failed due to insufficient KMS permissions.

Check the IAM role attached to the Lambda function for insufficient permissions.

Why it fails: Insufficient IAM permissions for the Lambda function's execution role would typically manifest as an AccessDeniedException or similar error within the function's CloudWatch Logs, often leading to a FunctionError status. If the function executed successfully without a FunctionError, it implies that the necessary permissions for its own execution and any AWS service calls it attempted were likely present.

Check the payload format against the function's expected input.

Why it fails: Although an incorrect payload format could certainly lead to unexpected behavior, if the Lambda function executed successfully without a FunctionError, it means the runtime successfully invoked the handler. Any issues with parsing or processing the event payload within the function's code would typically result in an error logged to CloudWatch, or the function would return an unexpected output based on its internal logic, rather than preventing the function from running at all.

Check the Lambda function's memory and timeout configuration.

Why it fails: Issues related to the Lambda function's memory allocation or timeout configuration would typically cause the function to terminate prematurely with a FunctionError or Task timed out message, respectively. Since the question implies the function executed successfully, these configuration parameters are unlikely to be the root cause of an unexpected output rather than a complete failure.

Remove the MyQueue resource.

Why it fails: 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 it fails: 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 it fails: 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 user is denied access only if the bucket policy also denies access.

Why it fails: 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 it fails: 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 it fails: 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 upload succeeds because the Allow statement grants s3:PutObject on the bucket.

Why it fails: While the Allow statement grants s3:PutObject permissions across the entire bucket, AWS IAM policy evaluation logic dictates that an explicit Deny statement always takes precedence. Therefore, despite the general Allow, the specific Deny targeting the confidential prefix overrides it, preventing the upload from succeeding.

The upload fails because there is no Allow statement for the confidential prefix.

Why it fails: The premise that there is no Allow statement for the confidential prefix is incorrect; the Allow statement granting s3:PutObject on 'your-bucket/*' inherently includes all prefixes within that bucket, including 'confidential'. The upload fails not due to a lack of permission, but because an explicit Deny statement specifically revokes that access for the confidential prefix, overriding the broader Allow.

The upload fails because the policy is malformed.

Why it fails: The policy is syntactically valid JSON and adheres to AWS IAM policy structure, allowing for both Allow and Deny statements to coexist and define permissions. A malformed policy would typically result in an immediate error during policy creation or attachment, preventing it from being evaluated at all. The failure here stems from the policy's content and its evaluation logic, not its format.

The CLI command is not supported on EC2 instances.

Why it fails: The AWS CLI is fully supported and commonly used on EC2 instances to interact with AWS services. EC2 instances are a primary environment for running automated scripts and applications that require programmatic access to AWS, making the CLI an essential tool in such scenarios. Therefore, stating that the CLI command is not supported on EC2 instances is fundamentally incorrect, as it contradicts standard AWS operational practices.

The IAM role does not have the required permissions for the CLI command.

Why it fails: A "missing credentials" error specifically indicates that the AWS CLI could not locate any valid authentication information to send with its request to AWS. This is distinct from a permissions error, which would occur if the CLI successfully authenticated with valid credentials but the associated IAM identity lacked the necessary permissions for the requested action. The error message clearly points to an authentication failure, not an authorization issue.

The instance does not have an IAM role attached.

Why it fails: The question stem explicitly states that an IAM role is attached to the EC2 instance. Therefore, this option directly contradicts the given information. While an unattached IAM role would indeed lead to the CLI being unable to retrieve instance profile credentials, the problem here is not the absence of the role, but rather the CLI's inability to correctly utilize the credentials provided by the present instance profile due to an override or misconfiguration.

Ensure the CodeDeploy agent is installed and running on the instance.

Why it fails: If the `BeforeInstall` script executed, even if it failed with an exit code 1, it confirms that the CodeDeploy agent was successfully installed, running, and actively managing the deployment on the instance. A non-running agent would prevent the deployment from even reaching the script execution phase, instead failing much earlier with an agent-related error or a timeout during the initial deployment setup. Therefore, the agent's operational status is not the root cause of a script execution failure.

Verify that the scripts location in the AppSpec file is correct.

Why it fails: The fact that the `BeforeInstall` script *ran* and produced an exit code implies that CodeDeploy successfully located and invoked it according to the AppSpec file. If the script's location in the AppSpec file were incorrect, CodeDeploy would report an error indicating it could not find or execute the specified script, rather than reporting an exit code from the script's execution itself. Thus, the AppSpec file's script path is validated by the script's attempt to run.

Check that the instance's IAM role has permissions to download the revision.

Why it fails: The `BeforeInstall` lifecycle hook executes *after* the application revision has been successfully downloaded from the S3 bucket or GitHub repository to the instance. If the deployment reached the `BeforeInstall` phase, it confirms that the instance's IAM role possessed the necessary `s3:GetObject` or equivalent permissions to retrieve the revision. A permissions issue for downloading would cause the deployment to fail during the 'Download Bundle' stage, long before any install scripts are invoked.

The secret is not marked as AWSCURRENT.

Why it fails: 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 it fails: 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 it fails: 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.

The CloudFormation template has invalid JSON syntax.

Why it fails: CloudFormation performs a syntax validation check on the template before attempting to provision any resources. If the template had invalid JSON syntax, the stack creation would fail immediately during the initial parsing phase with a syntax error, not a specific resource-level conflict error like 'Bucket already exists'. The error message indicates that the template was successfully parsed and CloudFormation proceeded to attempt resource creation, only to encounter a naming conflict.

The IAM user does not have permission to create S3 buckets.

Why it fails: If the IAM user or role executing the CloudFormation stack lacked the necessary `s3:CreateBucket` permissions, the error message would explicitly indicate an authorization failure. Such an error would typically manifest as 'Access Denied' or 'UnauthorizedOperation'. A 'Bucket already exists' error signifies that the principal *did* have permission to attempt the creation, but the resource name itself was unavailable due to a naming conflict, not a lack of authorization.

The bucket name is not available in the specified region.

Why it fails: S3 bucket names are part of a global namespace, meaning they must be unique across all AWS accounts worldwide, regardless of the region where the bucket is intended to be created. While S3 buckets themselves are regional resources, their names are globally reserved and cannot be duplicated. Therefore, the availability of a bucket name is not restricted to or determined by its presence or absence within a specific AWS region.

The KMS key policy does not allow the Lambda function role.

Why it fails: While a restrictive KMS key policy could indeed prevent the Lambda function from utilizing the key, the immediate and more direct cause of failure, as implied by a missing permission, lies with the IAM policy attached to the Lambda function's execution role. If the IAM policy itself does not grant the necessary kms:GenerateDataKey permission, then the Lambda function cannot even attempt to perform the action, regardless of how permissive the KMS key policy might be. The IAM policy defines the maximum permissions the role can ever assume.

s3:GetObject is missing for the bucket.

Why it fails: The s3:GetObject permission is specifically designed for retrieving or downloading objects from an S3 bucket. The scenario describes a Lambda function attempting to write an object to S3, which is an upload operation. For writing operations, the s3:PutObject permission is required, not s3:GetObject. Therefore, the absence of s3:GetObject is entirely irrelevant to the failure of an object write operation, as it serves a different purpose.

kms:ReEncrypt is missing.

Why it fails: The kms:ReEncrypt permission is specifically utilized when data that has already been encrypted under one AWS KMS key needs to be decrypted and then re-encrypted under a different KMS key. For an initial PutObject operation to S3 using server-side encryption with KMS (SSE-KMS), the data is being encrypted for the very first time. Since no prior encryption under a different key exists, the kms:ReEncrypt permission is not applicable or required for this initial write process.

The function returned an error in the LogResult field.

Why it fails: FunctionError 'Unhandled' means the function's code threw an unhandled exception, not that LogResult contains an error; LogResult holds base64-encoded tail logs. It is tempting because logs often reveal the exception, but LogResult is diagnostic output, not the error signal itself.

The function timed out during execution.

Why it fails: A timeout produces a `Task timed out` error message and typically a 502 status, not a 200 with `FunctionError: Unhandled`. That field signals the handler itself threw an uncaught exception. Timeout configuration is the right focus when a function exceeds its configured limit, but here the invocation completed and returned a response.

The function was invoked but there was a network error.

Why it fails: A network error would surface as a CLI transport failure or timeout, not a 200 response carrying a FunctionError field; the invocation clearly reached the function and returned a payload. It is tempting because network faults do disrupt Lambda calls, but those manifest before invocation completes, whereas 'Unhandled' signals the function code itself threw an uncaught exception.