Refer to the Exhibit Practice Questions

The principal "*" grants access to all AWS services

Why it fails: A principal of "*" in an S3 bucket policy denotes anonymous, unauthenticated access, not every AWS service identity. The confusion is tempting because "*" appears in service principals, but here it means anyone on the internet can reach the bucket, which is the real exposure.

The policy version is outdated and should be updated

Why it fails: The policy language version is a syntax declaration, not a security control; an outdated value does not widen access, so it cannot be the immediate concern. Version strings are tempting because they suggest staleness, but they only affect which policy grammar AWS evaluates, not who is granted what.

The resource ARN does not include the bucket itself, only objects

Why it fails: The resource ARN scoping only objects still covers every object in the bucket, so the grant's effect is unchanged; the actual exposure lies in the principal or action. Object-only ARNs are tempting to flag because bucket-level actions need the bucket ARN, but that mismatch merely fails those operations.

Outbound traffic should be allowed to any destination.

Why it fails: Allowing outbound traffic to any destination removes egress filtering, so a compromised web server can reach command-and-control infrastructure or exfiltrate data unchallenged. Egress rules should restrict destinations to required update and API endpoints. Permitting all outbound traffic suits trusted, isolated development sandboxes where connectivity troubleshooting matters more than containment.

Inbound HTTPS should be allowed from any source.

Why it fails: Allowing HTTPS from any source exposes the web server to the whole internet rather than the intended clients, defeating least privilege. The rule should restrict sources to known ranges. Any-source HTTPS suits public sites deliberately serving anonymous global traffic.

Security groups should not be used for web servers.

Why it fails: Security groups are the standard mechanism for controlling traffic to web servers; the violation lies in the rule's overly broad source range, not in using a security group. Security groups suit precisely this filtering role for any instance type.

Change the bucket's policy.

Why it fails: The IAM policy grants s3:PutObject on the bucket's objects, not s3:PutBucketPolicy, so changing the bucket policy is denied. Bucket-policy modification requires an explicit s3:PutBucketPolicy permission on the bucket resource. This action would be allowed if the policy statement targeted the bucket ARN with that action.

Upload a new object to the bucket.

Why it fails: The policy's action list covers object-level read operations such as s3:GetObject, not s3:PutObject, so uploading a new object is denied. Uploading requires s3:PutObject on the bucket's object ARN. This action would be permitted if the statement included s3:PutObject alongside the existing read permissions.

Delete an object from the bucket.

Why it fails: The policy grants read actions on objects, not s3:DeleteObject, so deleting an object is denied. Deletion requires s3:DeleteObject on the object ARN. This action would be allowed if the policy statement explicitly listed s3:DeleteObject for the bucket's objects.

The user is trying to access the bucket from a different AWS region.

Why it fails: S3 buckets are regional resources, but cross-region requests to a bucket's endpoint still resolve and authorise normally; region mismatch alone does not yield AccessDenied. It is tempting because region errors are common, yet the exhibit's policy or condition context indicates the actual denial source.

The bucket policy explicitly denies access to the 'Analysts' group.

Why it fails: An explicit Deny in the bucket policy overrides any Allow granted through IAM identity policies, which is exactly what produces AccessDenied for a group member. It is tempting because it is the textbook cause, but the exhibit's log details point to a different mechanism, such as a mismatched condition or resource ARN.

The bucket requires server-side encryption and the request did not include encryption headers.

Why it fails: Missing encryption headers produce a 400 InvalidRequest or KMS-related error, not AccessDenied, since SSE-S3 and SSE-KMS reject malformed requests before authorisation. It is tempting because encryption requirements do block uploads, but the correct answer involves an explicit policy statement denying the Analysts group.

It automatically encrypts all new object versions

Why it fails: MFADelete adds a second authentication factor before permanently deleting an object version; it does not encrypt anything. Encryption is handled by SSE-S3, SSE-KMS or SSE-C. It is tempting because both features appear under bucket properties, but MFADelete protects against destructive deletion, not confidentiality of object data.

It prevents any version of an object from being overwritten

Why it fails: MFADelete protects against permanent deletion of object versions; it does not stop a new version being written over an existing key. It is tempting because it hardens versioning, but overwriting simply creates another version, and only a delete operation on a version is gated by MFA.

It requires MFA for all operations on the bucket

Why it fails: MFADelete only gates permanent version deletion and changes to the bucket's versioning state when the requester supplies a valid MFA token; ordinary PUT, GET and LIST calls proceed without it. It is tempting as a blanket access control, but it is a narrow deletion safeguard, not an authorisation layer for every bucket operation.

Encrypt the database connection

Why it fails: Transport encryption protects data in transit from interception; it does not parse or sanitise SQL syntax, so injected statements still execute. Parameterised queries or input validation address the injection itself. Encryption is tempting because it hardens database traffic, and would be correct where confidentiality of credentials or data on the wire is the requirement.

Implement rate limiting on the login endpoint

Why it fails: Rate limiting throttles request frequency against the login endpoint, but the injected SQL still reaches the database and executes. It is the right control against brute-force or credential-stuffing attempts, whereas parameterised queries or input validation stop injection itself.

Enforce strong password policies

Why it fails: Password strength governs authentication, not query construction, so a valid session can still submit malicious SQL. Parameterised queries or input sanitisation prevent injection. Strong password policies are tempting because they harden access control, and would be correct where credential guessing or brute-force against accounts is the threat.

Virtual network peering

Why it fails: Virtual network peering connects two VPCs pairwise, so a full mesh of peerings is needed and each pair carries its own routes and policies; it provides no central hub for consolidated security enforcement. It is tempting because peering is simple for a few VPCs, and it would be correct for direct low-latency links between two networks.

Private link service

Why it fails: PrivateLink provides unidirectional private access to a single service via endpoint network interfaces, not transitive VPC-to-VPC routing, so it cannot form a hub-and-spoke topology with centralised policy enforcement. It is tempting because it privately exposes individual services across accounts, which is its actual purpose.

Virtual network endpoint

Why it fails: A virtual network endpoint is a private IP target for one service, not a routing or peering construct, so it cannot interconnect multiple VPCs into a hub-and-spoke topology. It is tempting because endpoints do enable private cross-account service access, which is their genuine role.

Access is denied because the Principal is set to "*", which is insecure.

Why it fails: Principal "*" is allowed but restricted by conditions.

Requests from IP 192.0.2.10 over HTTP are allowed because the deny statement only applies when SecureTransport is false.

Why it fails: The deny statement denies all actions when SecureTransport is false, so HTTP requests are denied.

Any IP address can perform GetObject requests if they use HTTPS.

Why it fails: The allow statement restricts to IP range 192.0.2.0/24 only.

Immediately revoke all admin privileges for the user.

Why it fails: Revoking admin privileges is a containment action, not an investigative step, and it destroys the ability to observe the account's ongoing behaviour. The analyst first needs to correlate the CreateKeyPair event with approved change records or tickets to establish authorisation before any remediation.

Review the key pair's usage to see if it was used to launch instances.

Why it fails: Usage of the key pair only shows whether it was later exploited; it cannot establish whether the admin's CreateKeyPair call was authorised. Correlating the event with the user's approved change requests, tickets or maintenance window is what distinguishes sanctioned activity from misuse.

Delete the key pair immediately to prevent any misuse.

Why it fails: Deleting the key pair is remediation that also destroys forensic evidence, and it presumes the action was malicious before authorisation is established. The analyst must first correlate the CreateKeyPair event with approved change requests, tickets or maintenance windows to determine whether the admin acted legitimately.

Remove Rule 2 because HTTPS should be restricted to a specific IP range.

Why it fails: Rule 2 permits HTTPS from any source, so narrowing it to a specific range still leaves the port exposed to the internet rather than restricting administrative or management access. Removing it entirely would be correct if the rule granted broad inbound access that no application flow requires.

Remove Rule 4 because outbound traffic should be restricted.

Why it fails: Removing Rule 4 strips outbound access the web server needs for patching, updates and back-end calls, breaking functionality. Outbound rules are tempting to lock down because egress filtering limits data exfiltration, and a default-deny outbound posture is correct where the application's required destinations are fully known and enumerated.

Remove Rule 3 because RDP should be allowed from anywhere.

Why it fails: Rule 3 permits RDP from a specific administrative range; deleting it removes legitimate management access rather than tightening exposure. Restricting RDP to a trusted bastion or VPN range is the correct control, so the tempting fix targets the right service but inverts the requirement by widening access to anywhere.

The VM's resource group has been moved to another subscription.

Why it fails: Moving a resource group to another subscription does not alter the VM's ProvisioningState; the resource simply relocates with its existing properties. Failed instead signals that the resource provider could not complete a create or update operation, such as an invalid image reference or exceeded quota.

The VM is in a deallocated state.

Why it fails: Deallocation is a normal stopped state reported through the VM's power state, not ProvisioningState; a deallocated VM still shows Succeeded for provisioning. Failed indicates the resource provider could not complete a create or update operation, such as a rejected image or quota error.

The VM was deleted by another administrator.

Why it fails: Deleted VMs would not appear in the list.

All upload requests will be denied unless they include encryption metadata

Why it fails: The policy's condition checks a specific encryption header, not the mere presence of metadata, so uploads lacking that exact key-value pair are denied rather than all unencrypted ones. It is tempting because metadata-based conditions do appear in bucket policies. Such a condition would be correct when enforcing a particular tagging or header requirement.

All objects must be encrypted with AWS KMS keys

Why it fails: The policy condition references a header value, not the KMS key used for server-side encryption, so it cannot mandate KMS encryption of objects. It is tempting because KMS-backed default encryption is a common S3 hardening measure. A policy using `s3:x-amz-server-side-encryption-aws-kms-key-id` would be correct when a specific KMS key must be enforced.

All objects uploaded must be client-side encrypted before uploading

Why it fails: Client-side encryption happens before upload, so S3 sees ordinary object data and cannot evaluate it through a bucket policy condition. It is tempting because client-side encryption is a legitimate data-protection approach. A policy condition on server-side encryption headers would be correct when the requirement is enforced at the storage service.

The bucket policy has a syntax error in the Condition block.

Why it fails: A malformed Condition block would cause S3 to reject the policy at save time, not to serve 403s at request time. The policy parses and evaluates; the Condition simply fails against CloudFront's origin-facing IPs. Syntax error would be correct if the policy had been rejected during PutBucketPolicy.

There is an implicit deny that overrides the explicit allow.

Why it fails: S3 evaluates explicit allows and implicit denies together; an explicit Allow for the principal and action overrides the default implicit deny. The 403 stems from the Condition's aws:SourceIp check rejecting CloudFront's edge IPs, not from any overriding deny. Implicit deny would be the answer if no statement granted the required action.

The bucket policy does not allow the s3:GetObject action.

Why it fails: The policy already grants s3:GetObject; the 403 arises because CloudFront fetches objects from its own IP addresses, which the Condition's aws:SourceIp allow-list rejects. GetObject omission would be the cause only if the action were absent from the policy statement entirely, which the exhibit contradicts.