Refer to the Exhibit Practice Questions

The internet gateway is not attached to the VPC

Why it fails: The stem states the internet gateway is already attached to the VPC, so this contradicts the given facts. An unattached gateway would indeed block internet access, making this the right diagnosis only when the attachment is genuinely absent.

The subnet needs a NAT gateway for internet access

Why it fails: A NAT gateway is required for instances in private subnets to reach the internet, but the route table here points directly at an internet gateway, indicating a public subnet. NAT gateways are correct when instances must initiate outbound traffic without inbound exposure.

The subnet's route table does not have a route to the internet gateway

Why it fails: The stem explicitly states the route table already contains a 0.0.0.0/0 route to the internet gateway, so this contradicts the given facts. A missing default route would block access, making this correct only when no such route exists.

The Lambda function timed out while waiting for a response.

Why it fails: A timeout surfaces as a client-side timeout exception, not an SDK error naming the DynamoDB operation, so it cannot explain the logged failure. It is tempting because Lambda's execution limit genuinely causes timeouts, and raising the function's timeout would be the fix if the log showed a Task timed out message.

The Lambda function does not have permission to access DynamoDB.

Why it fails: Missing permissions produce AccessDeniedException from IAM authorisation, which is a distinct error string from the one logged. It is tempting because Lambda execution roles frequently omit DynamoDB actions, and attaching the correct IAM policy would fix it if the log showed an access-denied message.

The DynamoDB table is throttling requests.

Why it fails: Throttling returns ProvisionedThroughputExceededException or RequestLimitExceeded, not the error shown in the exhibit. It is tempting because DynamoDB capacity limits are a common Lambda integration failure, and switching the table to on-demand billing would resolve it if the log named throttling.

Remove the condition from the bucket policy.

Why it fails: Deleting the condition removes the encryption requirement entirely, weakening the bucket's security posture rather than satisfying it. The condition is what blocks unencrypted uploads, so removing it lets data land unencrypted. Editing the policy is tempting as a quick fix, but the correct approach supplies the encryption the condition demands.

Add an IAM policy that allows s3:PutObject to the role.

Why it fails: The role already allows s3:PutObject, so adding another identical permission changes nothing; the failure comes from the bucket policy's encryption condition, not from IAM. Duplicating an existing allow is tempting because IAM denials commonly cause access failures. Here the request must carry the required encryption header to pass the policy.

Grant the role permission to use the KMS key.

Why it fails: The bucket policy's condition requires a specific encryption header, so granting KMS permissions does not satisfy it; the upload still fails the policy check. KMS permissions matter only when objects use SSE-KMS, which is the tempting association here. The scenario needs the request to meet the encryption condition, not key access.

The EBS volume is detached but the data is preserved.

Why it fails: Stopping an EBS-backed instance detaches the volume from the host but retains it, and the data persists; the volume reattaches on start. DeleteOnTermination governs deletion only at instance termination, not at stop. This option is tempting because stop does release the volume from the running instance, but the data is not lost.

The EBS volume is deleted.

Why it fails: DeleteOnTermination applies only when the instance is terminated, not when it is stopped. Stopping preserves the volume and its data, so nothing is deleted. This option is tempting because the flag's name suggests deletion, but it has no effect on a stop operation; the volume survives and reattaches on start.

The EBS volume is deleted because the instance is stopped.

Why it fails: Stopping an instance never deletes attached EBS volumes; deletion occurs only at termination, and DeleteOnTermination is set to false here, so the volume persists regardless. This option is tempting because stop and terminate are easily confused, but stop merely releases the volume from the host while preserving its data.

The Lambda function has exceeded the maximum memory limit.

Why it fails: Memory limit would cause a different error, not a missing module.

The Lambda function handler is incorrectly configured.

Why it fails: The handler executed; the error occurred during module loading.

The Lambda execution role does not have permissions to access the module.

Why it fails: Module loading does not require IAM permissions.

The CLI command is querying the wrong instance

Why it fails: The exhibit shows the queried instance running, so a wrong instance identifier would not explain the SSH failure while that state persists. It is tempting because mistyped instance IDs do cause confusing CLI output, and verifying the identifier would be the correct step when the returned state contradicts expectations.

The instance is in a 'stopped' state

Why it fails: The exhibit already shows the instance in a running state, directly contradicting a stopped state, so this cannot be the cause. It is tempting because a stopped instance genuinely is unreachable over SSH, and that would be the correct diagnosis if the CLI output had reported stopped rather than running.

The instance does not have EBS optimization enabled

Why it fails: EBS optimisation affects storage throughput only; it has no bearing on whether SSH traffic reaches the instance. It is tempting because it is a genuine per-instance setting that can be enabled or disabled, and it would be the correct answer if the symptom were degraded disk performance rather than connectivity.

The bucket is not encrypted.

Why it fails: Encryption protects data at rest and has no bearing on recording who accessed objects. The stem requires access logging, which needs S3 server access logging or CloudTrail data events enabled on the bucket. Encryption would be the answer if the requirement were confidentiality of stored objects rather than an audit trail.

The bucket policy does not restrict access to a specific IP range.

Why it fails: An IP restriction limits who may access objects but records nothing about the requests themselves. The requirement is an audit trail of all access, satisfied by S3 server access logging or CloudTrail data events. An IP condition in the bucket policy would be correct if the goal were restricting access to a corporate network range.

Bucket versioning is not enabled.

Why it fails: Versioning preserves prior object versions against overwrite or deletion; it does not record access requests. The stem needs S3 server access logging or CloudTrail data events to capture every request. Versioning would be the correct addition if the requirement were recoverability of overwritten or deleted objects.

The trail is not a multi-region trail

Why it fails: A single-region trail still records management events from every organisation account in that region, so regional scope does not explain missing cross-account events. It is tempting because multi-region trails are standard for organisation-wide coverage, but the exhibit's issue concerns organisation-level event collection instead.

The trail does not include global service events

Why it fails: Global service events cover IAM, CloudFront and Route 53 activity, not the management events of member accounts, so omitting them cannot explain the gap. It is tempting because enabling global service events is a common hardening step, but the organisation trail's account coverage is the actual problem.

The trail has log file validation enabled, which prevents cross-account delivery

Why it fails: Log file validation only adds digest files to detect tampering after delivery; it does not block cross-account delivery to the central bucket. It is tempting because validation is a genuine integrity control worth enabling on organisation trails, but it is unrelated to the missing events described in the exhibit.

aws cloudformation describe-stacks --stack-name my-stack

Why it fails: describe-stacks returns stack metadata such as status and outputs, not the per-resource failure events. It is tempting because it confirms the stack's failed status, but the correct command is describe-stack-events, which lists the resource-level error messages explaining the failure.

aws cloudformation get-template --stack-name my-stack

Why it fails: get-template retrieves the submitted template body, which shows the intended configuration rather than the runtime error. It is tempting when suspecting a template syntax problem, but the correct command is describe-stack-events, which returns the resource status reasons recorded during the failed creation.

aws cloudformation list-stack-resources --stack-name my-stack

Why it fails: list-stack-resources returns the resources and their current statuses, but not the failure reason text. It is tempting to confirm which resource failed, yet the correct command is describe-stack-events, which supplies the detailed error messages for each resource event.

mgh:AssociateDiscoveredResource

Why it fails: mgh:AssociateDiscoveredResource is for associating resource data, not registering tasks.

mgh:CreateHomeRegion

Why it fails: mgh:CreateHomeRegion is not needed.

mgh:GetHomeRegion

Why it fails: mgh:GetHomeRegion is read-only.

The upload fails with an implicit denial because the Allow condition is not met.

Why it fails: The policy's Allow statement carries an aws:SecureTransport condition, so an HTTP request does not satisfy it; with no matching Allow, the request is implicitly denied. The option is tempting because conditions do gate Allow statements, but the failure is an implicit, not explicit, denial.

The upload succeeds because the Allow statement grants s3:PutObject.

Why it fails: The Allow statement grants s3:PutObject only when aws:SecureTransport is true; an HTTP upload fails that condition, so no Allow applies and the request is denied. It is tempting because the action and resource match, but the condition key must also evaluate true.

The upload succeeds because there is no explicit Deny for s3:PutObject.

Why it fails: IAM is deny-by-default: absent any matching Allow, the request is implicitly denied regardless of explicit Deny statements. The option is tempting because explicit Denies are absolute, but the aws:SecureTransport condition on the Allow already prevents it from applying to HTTP.

The sidecar container will be marked as essential.

Why it fails: Essential status is declared in the task definition at registration time; it is never assigned dynamically when a container exits. The sidecar's non-essential flag remains unchanged regardless of its exit code. Marking a container essential is a design decision made when authoring the task definition, not a runtime behaviour of ECS.

ECS will automatically restart the sidecar container.

Why it fails: ECS does not restart a non-essential container that exits; only the essential container's state governs the task. A non-essential container stopping is simply recorded, and the remaining containers continue running. Automatic restart applies to tasks managed by a service scheduler with a desired count, not to individual container exit within a running task.

The ECS task will be stopped.

Why it fails: ECS stops the entire task only when an essential container exits or fails. Because the sidecar is non-essential, its exit does not trigger task termination; the web container keeps running and the task remains in RUNNING state. Task stoppage would be the outcome had the essential web container exited instead.

The stack was deleted after creation.

Why it fails: The exhibit shows outputs, indicating successful creation.

The stack name is case-sensitive and should be 'MyApp'.

Why it fails: Stack names are case-sensitive but the command uses the exact name.

The '--query' parameter is incorrectly formatted.

Why it fails: The query syntax is correct.

Users from 192.168.0.0/16 can access objects in the confidential/ prefix.

Why it fails: The deny on confidential/ applies to every source outside 10.0.0.0/16, so 192.168.0.0/16 requests are blocked despite the bucket-level Allow. It tempts because the Allow statement names both ranges, but explicit Deny overrides Allow in S3 policy evaluation.

Users from 10.0.0.0/16 cannot access objects in the confidential/ prefix.

Why it fails: The deny statement permits 10.0.0.0/16 as its exception, so those users retain access to confidential/ objects. It tempts because the deny appears to block all S3 actions on that prefix, but the condition excluding the 10.0.0.0/16 range carves out that source.

The policy has no effect because the Allow and Deny statements cancel each other.

Why it fails: Explicit Deny overrides Allow in S3 bucket policies, so the deny on the confidential/ prefix restricts access rather than cancelling the allow. It tempts because Allow and Deny statements on the same resource appear contradictory, yet IAM evaluates them independently with deny taking precedence.

The Principal is incorrect; it should be the role name, not ARN.

Why it fails: Principal can be specified as ARN.

The Resource ARN is incorrect; it should be 'arn:aws:s3:::my-bucket'.

Why it fails: The resource ARN with /* is correct for objects.

The condition key is misspelled.

Why it fails: The key is correctly spelled.