Select Two (Multi-Select) Questions

Allow contractors to use a shared account for simplicity

Why it fails: Shared accounts eliminate accountability and make auditing difficult.

Provide full network-level VPN access

Why it fails: Full VPN access gives contractors unnecessary network visibility and violates least privilege.

Right to unlimited data storage

Why it fails: GDPR grants no right to unlimited storage; Article 5(1)(e) instead imposes storage limitation, requiring data be kept no longer than necessary. It tempts because organisations do retain data indefinitely in practice, and long retention is lawful only where a specific legal basis or statutory obligation justifies it.

Right to data monetization

Why it fails: GDPR confers no right to monetise data; processing personal data for profit requires a lawful basis plus transparency, and data subjects hold rights such as access, erasure and portability instead. It tempts because organisations do commercialise aggregated data, which is lawful only when properly anonymised or consented.

Continuous deployment

Why it fails: Continuous deployment focuses on delivery automation, not security.

Code signing

Why it fails: Code signing verifies authenticity after development, not a core SSDLC process step.

Runtime application self-protection (RASP) deployment

Why it fails: RASP instruments a running application to detect and block attacks at execution time, so it belongs to the operations and maintenance phase, not development. RASP would be the correct choice when hardening a deployed application against live runtime exploitation.

Penetration testing on production environment

Why it fails: Penetration testing targets a deployed, running system, placing it in testing or operations rather than the development phase. It would be the correct activity when validating a completed build in a staging or production environment before release.

Relying on the vendor's own marketing materials and public certifications page to confirm its security posture

Why it fails: Marketing content and public badge pages are self-selected and unverified, so they provide no reliable evidence about the controls actually protecting the bank's data. Examiners expect independent validation through reports, assessments, or contractual assurances, not vendor-authored promotional claims, which is why this practice fails to demonstrate meaningful continuous oversight.

Ranking vendors solely by annual contract value and assigning oversight resources proportionally to spend

Why it fails: Contract value does not correlate with the sensitivity of data accessed or the operational criticality of the vendor, so spend-based ranking can under-supervise a low-cost vendor holding regulated customer data. Risk tiering should consider data classification, system access, and business dependency, making this approach a misallocation of oversight rather than a continuous monitoring practice.

Collecting a completed security questionnaire from each vendor once during initial onboarding and archiving the response

Why it fails: A questionnaire completed at onboarding captures the vendor's posture on a single date and becomes stale as the vendor's environment, personnel, and controls change. Archiving it without refresh means the bank relies on outdated self-reported information, so this practice reflects initial due diligence rather than the continuous oversight the examination is probing for.

Private

Why it fails: Private is a commercial classification, not standard in government.

Public

Why it fails: Public is a commercial classification, not standard in government.

Grant access based on network location

Why it fails: Zero trust rejects network location as a trust signal, so granting access by network location contradicts its core tenet of evaluating every request on identity and context. It is tempting because perimeter-based designs historically trusted internal subnets, and this would be correct for a traditional castle-and-moat architecture.

Assume implicit trust for internal users

Why it fails: Zero trust explicitly removes implicit trust, requiring continuous verification of every user and device regardless of internal or external position. It is tempting because legacy designs trusted users inside the corporate network, and this would be correct for a perimeter-based model rather than a zero trust one.

Use a single perimeter firewall

Why it fails: A single perimeter firewall assumes a defined network edge, whereas zero trust treats the network as hostile and enforces policy per resource through identity-based controls. It is tempting because firewalls remain valuable for traffic filtering, and this would be correct for a perimeter-defence question rather than a zero trust principle.

Easier to deploy in cloud environments than software.

Why it fails: While HSMs offer superior security, they are typically physical appliances requiring dedicated infrastructure, making them more challenging and costly to deploy in cloud environments compared to software-based solutions that can be provisioned as virtual machines or containers. This option is tempting because HSMs are indeed designed for high-security applications, and their physical separation from general-purpose computing environments provides a strong defence against software-based attacks, making them ideal for on-premises critical infrastructure or highly regulated industries.

Automatically receive security patches without manual intervention.

Why it fails: HSMs require firmware updates applied by the operator, so patches are not automatic; this describes managed cloud key services instead. It tempts because vendors do issue HSM firmware fixes, but the advantage over software modules lies in tamper-resistant key storage and FIPS validation, not patch automation.

Lower cost than software modules.

Why it fails: HSMs carry higher acquisition and operational cost than software cryptographic modules, so this inverts the actual trade-off. It tempts because software modules are indeed cheaper, but that is precisely why cost cannot be listed as an HSM advantage; the genuine benefits are physical tamper resistance and hardware-enforced key isolation.

Multiple HTTP GET requests to a known content delivery network

Why it fails: This is normal traffic to a CDN, not indicative of exfiltration.

A single large file upload to a cloud storage provider during work hours

Why it fails: This could be legitimate business use, especially during work hours, and is less suspicious than off-hours transfers.

High volumes of DNS queries to a single external domain

Why it fails: This indicates DNS tunneling, which is a form of exfiltration but is not necessarily encrypted; it uses DNS protocol. The question specifies encrypted tunnels.

Enforce multi-factor authentication for all users

Why it fails: MFA for all users is baseline identity hygiene, not a PAM control for critical servers. It is tempting because MFA genuinely strengthens privileged sign-ins, but the scenario targets privileged access management specifically, where just-in-time elevation and session brokering apply. Applying MFA universally does not address standing privileged entitlements.

Require periodic password rotation for all service accounts

Why it fails: Periodic rotation of service account passwords creates operational risk and does not constrain standing privilege, which is the PAM objective. It is tempting because rotation is a long-standing credential hygiene practice, yet modern guidance favours vaulted, rotated secrets managed by the PAM platform rather than scheduled manual rotation across all service accounts.

Send an alert to the user's manager for approval

Why it fails: Manager approval inserts a human authorisation step, which halts automated containment and delays isolation of the malicious email; SOAR playbooks execute containment directly once triage confirms malice. It is tempting because approval gates suit high-impact destructive actions, but phishing containment needs immediate automated quarantine, not managerial sign-off.

Automatically create a ticket in the service desk system

Why it fails: Ticket creation records the incident but performs no triage or containment, so the malicious email remains in the mailbox and other recipients stay exposed. It is tempting because ticketing is standard SOC practice for audit trails, but that fits post-containment documentation, not the containment actions this playbook must execute.

Initiate a full antivirus scan on the user's workstation

Why it fails: Initiating a full antivirus scan on the user's workstation is a remediation step that occurs after containment, not a containment action itself. The playbook specifically requires immediate containment to stop the threat from spreading, such as disabling the user's account or isolating the host via network access control. This option is tempting because antivirus scans are a standard response to confirmed malware, and they would be correct in a playbook focused on post-containment eradication or endpoint cleanup, where the goal is to remove the malicious payload rather than halt lateral movement.

Signature-based detection on malicious file hashes

Why it fails: LotL techniques reuse legitimate signed binaries, so file-hash signatures rarely match anything malicious; detection needs behavioural analytics over process lineage and command lines. It is tempting because signature scanning is a familiar, low-noise control, and would be correct against known malware with stable, previously catalogued hashes.

Blocking all scripts and macros by default

Why it fails: Blocking scripts and macros by default is prevention, not detection, and LotL activity abuses signed native binaries such as PowerShell and WMI that policy cannot simply forbid. It is tempting because script blocking does reduce attack surface, and would be correct as a hardening control rather than a detection strategy.

Single Loss Expectancy (SLE)

Why it fails: SLE is a component of traditional ALE calculations, not of the FAIR ontology, which instead uses primary loss and secondary loss factors. It tempts because SLE quantifies per-event loss, but FAIR decomposes magnitude differently, so SLE is not a primary FAIR component.

Annual Loss Expectancy (ALE)

Why it fails: ALE is a quantitative output of traditional annualised loss calculations, not a FAIR primary component; FAIR decomposes risk into loss event frequency and loss magnitude factors. It tempts because ALE is a familiar risk metric, but FAIR analysis derives its own factor taxonomy rather than using ALE as an input.

Annualized Rate of Occurrence (ARO)

Why it fails: ARO belongs to classic quantitative risk formulas, not FAIR's factor model, which uses loss event frequency and loss magnitude. It tempts because ARO sounds like a frequency measure, but FAIR expresses occurrence through vulnerability and threat event frequency instead of an annualised rate.

User acceptance testing (UAT) to validate business requirements.

Why it fails: UAT validates that software meets business requirements and functional expectations; it does not verify security controls. Security validation requires dedicated activities such as penetration testing and vulnerability assessment. UAT would be the correct choice if the question concerned functional acceptance rather than security engineering.

Daily stand-up meetings for developers.

Why it fails: Daily stand-ups coordinate development progress and surface blockers; they do not embed security engineering activities such as threat modelling, secure coding or security testing. Stand-ups belong to agile delivery ceremonies, and would be correct if the question asked about team communication rather than SSDLC security components.

Use SHA-1 for integrity

Why it fails: SHA-1 is cryptographically broken for collision resistance, so it cannot provide the integrity assurance the scenario demands; SHA-256 or stronger is required. It is tempting because SHA-1 was long the default hash in IPsec proposals and still interoperates with legacy devices, but it would only be the correct choice where peer support mandates it.

Use IKEv1 instead of IKEv2

Why it fails: IKEv1 lacks IKEv2's support for stronger integrity algorithms and its more robust rekeying and denial-of-service resistance, so selecting it weakens the tunnel. It is tempting because IKEv1 is the established legacy standard and remains valid for interoperability with older peers, but the scenario explicitly requires the strongest security.

Store database credentials in AWS Secrets Manager and retrieve them at runtime.

Why it fails: Secrets Manager protects credential storage, not the network path or transport channel, so it leaves the database reachable over the internet and unencrypted. It is tempting because centralised secret rotation genuinely removes hard-coded credentials; that would be the right control when the requirement is credential lifecycle management rather than private connectivity.

Configure VPC peering between the AWS VPC and the on-premises network.

Why it fails: VPC peering connects two AWS VPCs; it cannot extend to an on-premises network, so no private path to the database is created. It is tempting because peering does provide private, non-internet routing, and would be correct if both the application and database were AWS-hosted VPCs.

Configure the web application to connect to the database using TLS encryption.

Why it fails: TLS encrypts data in transit but does nothing to reduce internet exposure, since the connection still traverses public networks. It is tempting because encryption in transit is explicitly required, and TLS would be the right answer if the question asked only how to protect confidentiality of the database traffic.

Social media profiling

Why it fails: Social media profiling draws on third-party public content, generating no traffic to the target's infrastructure — passive reconnaissance. It is tempting because employee posts expose technologies, roles, and email formats, but the target's own systems neither receive nor log the activity.

WHOIS lookup

Why it fails: WHOIS queries public registry databases, so no packets reach the target's own systems — that is passive reconnaissance. It is tempting because WHOIS reveals registrant, nameserver, and contact data useful for mapping an estate, but the target never observes the query.

Searching job postings for technology details

Why it fails: Job postings sit on third-party sites, so reviewing them sends no traffic to the target — passive reconnaissance. It is tempting because adverts leak stack details such as cloud providers and versions, yet the target observes nothing, unlike direct scanning or DNS interrogation.

Use the latest base image from Docker Hub

Why it fails: This is important for image security, not runtime configuration.

CRL distribution points

Why it fails: CRL distribution points merely advertise where a full CRL can be fetched, so clients still download that entire list rather than querying a single certificate's status. They are tempting because they are the standard way to locate revocation data, and would be correct when distributing CRLs across multiple CAs or partitions, not for avoiding full-CRL retrieval.

Certificate transparency logs

Why it fails: Certificate transparency logs provide public append-only auditing of issued certificates to detect mis-issuance; they hold no revocation data, so they cannot answer whether a certificate is revoked. They are tempting because they are certificate-related and improve PKI assurance, and would be correct for monitoring unauthorised issuance, not for revocation checking.

Delta CRL

Why it fails: Delta CRLs publish only changes since a base CRL, so clients still require that base CRL to reconstruct full revocation state; they reduce, not eliminate, full-CRL downloads. They are tempting because they cut bandwidth for frequent updates, and would be correct alongside a base CRL in a bandwidth-constrained hierarchy, not as the on-demand per-certificate check the scenario demands.

Add random delays to cryptographic operations

Why it fails: Adding noise is less effective than constant-time algorithms; statistical analysis can still extract timing information.

Disable debug interfaces on the secure enclave

Why it fails: Disabling debug interfaces prevents debugging but does not mitigate timing side-channel attacks.

Replace ECDSA with Ed25519

Why it fails: Ed25519 also requires constant-time implementation to prevent timing attacks.