Refer to the Exhibit Practice Questions

The bucket allows anonymous GET operations from any IP

Why it fails: Anonymous GET access is a genuine exposure, but the exhibit's policy grants it only to a specific service principal, not any IP. It tempts because public-read buckets are a classic misconfiguration; here the flaw lies in the principal scope, not anonymous access.

The bucket policy is too restrictive

Why it fails: A bucket policy granting only the owner full control and denying all other principals is not a security issue; it is the intended least-privilege configuration. This option tempts candidates who equate restrictive access with misconfiguration, but over-restriction becomes relevant only when legitimate workloads or delegated users are blocked, which the exhibit does not show.

The bucket is not encrypted

Why it fails: Encryption at rest is configured separately from bucket policy, so the exhibit cannot demonstrate its absence. It tempts because unencrypted storage is a frequent finding; the policy's real issue is the permissive principal and action combination.

The ACL lacks a log statement

Why it fails: A missing log statement only affects whether denied packets are recorded; it does not itself drop traffic, so it cannot cause the block. It is tempting because absent logs make diagnosis harder, and adding logging would be the right action when you need visibility into which ACL entry is denying the traffic.

The web server is using port 443

Why it fails: Port 443 carries HTTPS, so a server listening there would not block inbound port 80 traffic; the two are independent listeners. It is tempting because web servers commonly redirect HTTP to HTTPS, and this would be correct if the requirement were secure browsing rather than explaining why port 80 is denied.

The destination IP is incorrect

Why it fails: The stem already states the web server is at 10.0.0.10, so the destination address in the traffic matches the server and cannot explain the block. It is tempting because a mistyped address is a common cause of failed connections, and this would be correct if the exhibit showed clients targeting an address other than the server's.

Correlation rule based on static thresholds

Why it fails: A static threshold rule fires on fixed values such as failed logon counts, not on deviation from a user's own historical login location and time. It is tempting because threshold correlation is simple to configure and effective for volumetric attacks like brute force, where absolute counts genuinely indicate malicious activity.

Signature-based detection

Why it fails: Signature-based detection matches known attack patterns or indicators, so a novel login from an unfamiliar location with no prior signature produces no match. It is tempting because signatures reliably catch documented malware and exploits, and would be correct when the activity matches a known threat pattern.

Threat intelligence feed correlation

Why it fails: Threat intelligence correlation matches observed IPs, domains or hashes against known-bad indicators; an unusual but unlisted login location carries no such indicator. It is tempting because feeds excel at flagging traffic to known command-and-control infrastructure, which is the right choice when indicators exist.

No versioning configured

Why it fails: Versioning is an S3 bucket property governing object overwrite and delete behaviour, not an IAM policy element, so it cannot describe any issue within the policy shown in the exhibit. It is tempting because missing versioning genuinely enables permanent data loss or ransomware overwrites, and enabling it would be the right control when the scenario concerns bucket resilience rather than policy permissions.

Missing server-side encryption

Why it fails: An IAM policy governs identity permissions, not data-at-rest protection, so it cannot cause or represent missing server-side encryption. It is tempting because encryption gaps are a common audit finding, and IAM policies can restrict who may disable default encryption; that scenario concerns storage or database configuration, not the policy document itself.

Insufficient logging and monitoring

Why it fails: The policy's flaw concerns overly broad permissions, not missing logging or monitoring. Insufficient logging is the correct finding when CloudTrail trails or log delivery are absent or disabled; here the issue lies in what actions the policy grants, not in audit capture.

Accept the risk as the data is not public

Why it fails: Accepting the risk leaves regulated cardholder data under-protected and contradicts the policy's own rules. It is tempting because the data is not public, implying low exposure, and would be correct only if the policy permitted Internal handling for that data type.

Remove the credit card numbers from the database

Why it fails: Removing the credit card numbers does not address the core issue: the database is mislabelled as 'Internal' despite containing PII and credit card data that, under the classification policy, likely requires a higher tier such as 'Confidential' or 'Restricted'. This action is tempting because data sanitisation is a legitimate method to reduce compliance scope, and it would be correct if the policy mandated eliminating sensitive fields to keep the database at the 'Internal' level, but here the policy violation stems from incorrect classification, not the data's presence.

Create a new classification level for mixed data

Why it fails: Creating a new level bypasses the existing policy rather than applying it, so it is not the first action. It is tempting because mixed PII and card data feels unclassifiable, and would be correct if the policy genuinely lacked a level covering combined data types.

Man-in-the-middle

Why it fails: Man-in-the-middle intercepts and relays traffic between two parties, requiring an adversary positioned in the communication path. The exhibit does not show interception or relayed sessions. MITM would be correct where a rogue proxy or ARP spoofing sits between endpoints.

Denial of service

Why it fails: Denial of service floods a service to exhaust availability, producing timeouts and resource saturation. The exhibit's evidence points elsewhere, so this label misreads the traffic pattern. DoS would be correct where traffic volume alone overwhelms a target.

Replay attack

Why it fails: Replay attacks capture valid authentication traffic and retransmit it later to gain access. The exhibit lacks duplicated captured credentials or repeated session tokens. Replay would be correct where identical authenticated packets recur without new credentials.

The policy denies all write access

Why it fails: A blanket write denial is a deliberate, visible restriction rather than a security weakness, and the exhibit's actual flaw lies elsewhere. Denying writes is the intended control when a bucket should remain read-only, such as serving static public assets.

The policy uses an outdated version

Why it fails: The policy language version is a syntax declaration; an older version still evaluates correctly and does not by itself expose data. Version choice matters when a policy needs features introduced in a later version, not as a security exposure in the exhibit.

The policy lacks encryption

Why it fails: Encryption is configured separately through bucket default encryption or object-level settings, not expressed in a bucket policy, so its absence cannot be read from the policy itself. Encryption requirements would be the concern when reviewing bucket configuration rather than the policy document.

Disable root login and remove the admin account.

Why it fails: Disabling root login and deleting the admin account removes the targeted credentials but leaves the attack channel open; the log shows repeated authentication attempts that require blocking the source or applying rate limits. It tempts because eliminating privileged accounts is sound hardening, and would suffice if the attack relied solely on those credentials.

Block the entire 192.168.1.0/24 subnet at the firewall.

Why it fails: Blocking the whole /24 severs every host on that subnet, including legitimate users, because the attack originates from a single compromised address within it. Firewall subnet blocks suit containing an entire untrusted network segment, not isolating one offending host identified in the log.

Change the SSH port to a non-standard port.

Why it fails: Moving SSH to a non-standard port only evades opportunistic scanners; the exhibit shows a targeted brute-force against a valid account, which continues regardless of port. It tempts because port obfuscation reduces background noise, and would be reasonable hardening alongside, not instead of, blocking the source and locking the account.

Threat intelligence feed integration

Why it fails: Threat intelligence feeds supply known indicators of compromise for matching against logs, so they detect traffic to malicious infrastructure rather than deviations from a user's own normal hours or transfer volumes. Tempting because it enriches detection, it would be correct when the requirement is identifying communication with known malicious IPs, domains or hashes.

Log normalization and aggregation

Why it fails: Normalisation and aggregation parse disparate log formats into a common schema and consolidate events, providing the data foundation but performing no behavioural deviation analysis. Tempting because it precedes every detection, it would be correct when the requirement is making heterogeneous sources searchable and reportable, not flagging anomalous user activity.

Correlation rules with threshold-based alerts

Why it fails: Threshold-based correlation rules fire on fixed counts within a window, so they cannot model each user's individual baseline of working hours and transfer volumes. Tempting because correlation combines multiple log sources, it would be correct when the requirement is alerting on a known static condition, such as repeated failed logons exceeding a set count.

The ACL only permits traffic from specific source IPs

Why it fails: Source-IP restrictions would equally affect port 443, since the same internet clients reach it successfully. Source-scoped ACLs suit restricting administrative access to known management subnets; here the differing behaviour between two ports on one host rules that out.

The firewall rule order is incorrect

Why it fails: Rule order only matters when overlapping rules conflict; a missing 8443 permit is absent regardless of sequence. Ordering errors suit shadowed or contradictory entries, whereas the stem shows 443 permitted and 8443 simply not allowed.

The firewall is blocking all traffic on port 8443

Why it fails: A blanket block on 8443 would also deny any other service using that port, yet the stem gives no evidence of such a rule. Port-wide denial suits deliberate service decommissioning; the scenario points to a rule matching 443 specifically, leaving 8443 unmatched.

No server-side encryption is specified

Why it fails: The question asks what is wrong with the policy's access logic; encryption is configured on the bucket or object, not in a bucket policy, so its absence is not a policy flaw. Encryption settings belong in a separate review of default bucket encryption configuration.

No version ID is specified in the resource

Why it fails: Omitting a version ID in the resource targets all object versions, which is normal for policy statements and not itself a security issue. Specifying version IDs matters when granting access to one immutable object version, such as in legal-hold scenarios.

No logging is enabled for the bucket

Why it fails: Bucket policy documents grant or deny principals access; logging is configured separately via S3 server access logging or CloudTrail data events, so its absence is not a policy defect. Reviewers often conflate policy content with bucket configuration, but logging would be the answer only if the stem asked about auditability rather than the policy itself.

New connections from the internet to 10.0.1.0/24 are allowed.

Why it fails: The exhibit's rules target the firewall's own interfaces and services, so they do not govern forwarded traffic to the 10.0.1.0/24 subnet. Allowing internet-to-subnet connections requires FORWARD chain rules plus NAT or routing, which is the scenario where this statement would hold.

All traffic is allowed by default because the policy is ACCEPT.

Why it fails: The policy ACCEPT only sets the default for chains without a matching rule; explicit DROP or REJECT rules earlier in the chain still block matching packets. Default ACCEPT is the correct reading when a chain contains no terminating rules, so unmatched traffic passes through rather than being discarded.

The rules apply to incoming traffic on the firewall itself.

Why it fails: Rules in the INPUT chain govern traffic destined for the firewall host itself, not traffic being forwarded to other hosts. This option would be correct if the exhibit showed rules in the FORWARD chain, which handles packets routed through the firewall to a different destination.

Source IP range is too broad

Why it fails: A broad source range permits traffic from addresses that should never reach the protected service, but the exhibit's rule must be read against its intended scope. It is tempting because wide ranges are a common misconfiguration. Narrowing the range to required hosts is correct where the rule's purpose is host-specific access.

No logging is enabled

Why it fails: Logging absence is a monitoring gap, not the rule's access-control flaw; the exhibit's vulnerability lies in the permissive source, port or action the rule allows. Logging would be the finding where traffic is correctly filtered but activity goes unrecorded for audit or incident response.

Missing application ID control

Why it fails: Application ID control restricts traffic to specific applications; omitting it permits any application on allowed ports. It is tempting because application filtering is a recognised hardening measure, and would be correct where the rule must enforce application-level identification rather than only port and address matching.

PCI DSS.

Why it fails: PCI DSS applies to organisations storing, processing or transmitting cardholder data, and its requirements are scoped to that environment. It is tempting because PCI DSS does mandate encryption of cardholder data in transit, and it would be correct if the exhibit quoted a card-data clause, but the clause shown belongs to a healthcare privacy and security regulation.

ISO 27001.

Why it fails: ISO 27001 specifies requirements for an information security management system, expressed as management-system controls rather than prescriptive cardholder-data clauses. It is tempting because ISO 27001 covers access control and cryptography, and it would be correct for an ISMS certification requirement, but the exhibit's wording matches a payment card standard.

HIPAA Security Rule.

Why it fails: The HIPAA Security Rule governs protected health information held by covered entities and business associates, so its clauses address ePHI safeguards rather than cardholder data. It is tempting because HIPAA does mandate administrative, physical and technical safeguards, and it would be the answer if the exhibit referenced ePHI, but the clause shown concerns payment card data.

Store the token in a Kubernetes secret and mount it.

Why it fails: Mounting a long-lived token via a Kubernetes secret still exposes a static credential to any container compromise, so theft risk is unchanged. Secrets suit distributing configuration data or certificates, not replacing short-lived, audience-bound projected service account tokens.

Use a different container runtime.

Why it fails: The runtime (containerd, CRI-O) executes containers; it does not govern token projection or mounting, so swapping it leaves the mounted credential exposed. Runtime selection matters for isolation hardening such as gVisor or Kata, not for service account token exposure.

Disable the service account for the pod.

Why it fails: Disabling the service account removes all pod identity, breaking legitimate API authentication rather than reducing theft risk. It is tempting because unused credentials should be eliminated, which is correct when a pod genuinely needs no cluster API access at all.