Select Two (Multi-Select) Questions

Enabling privileged mode for containers that need host access

Why it fails: Privileged mode grants the container all Linux capabilities and direct host device access, directly enabling the privilege escalation the question asks to reduce. It is tempting because some workloads genuinely need host access, and it would be correct only when that requirement outweighs the hardening objective.

Running containers as root

Why it fails: Running as root gives the container UID 0, so any process breakout inherits full root privileges on the host namespace, contradicting the goal of restricting escalation. It is tempting because many default images assume root, and it would be correct only for legacy images that cannot run unprivileged.

Allow all traffic from the internet.

Why it fails: Allowing all traffic removes segmentation.

Use a bastion host for all administrative access.

Why it fails: Bastion host is for secure admin access, not micro-segmentation.

Use a single network ACL for all subnets.

Why it fails: A single ACL does not provide granular segmentation.

Use a single master key for all encryption operations.

Why it fails: Single point of failure; best practice is to use unique keys per application.

Store keys in the same cloud region as the data to reduce latency.

Why it fails: Storing keys in the same region increases risk; should be separate.

Strategy to avoid vendor lock-in with the CSP.

Why it fails: Vendor lock-in is a procurement concern, not a BCP requirement.

A detailed risk assessment for all cloud services.

Why it fails: Risk assessment is part of risk management, not BCP.

Network topology diagrams of the cloud environment.

Why it fails: While helpful, diagrams are not a required element of a BCP.

Analyzing network latency between cloud regions

Why it fails: Latency is a performance metric, not a risk factor.

Evaluating the CSP's physical security controls in detail

Why it fails: Physical security is often inherited from the CSP and not a primary focus in customer risk assessment.

Encrypt all discovered data

Why it fails: Encryption is a subsequent action, not part of discovery.

Create backup copies of data

Why it fails: Backups are not part of discovery.

Enable the kubelet read-only port and disable anonymous authentication to the kubelet API.

Why it fails: Disabling anonymous authentication and the read-only port is a good hardening step for the kubelet API, but it primarily protects against unauthorized API access. It does not directly prevent a container that is already running from escalating privileges or breaking out to the node. Therefore it is not the most effective measure for the stated goal.

Configure the container runtime to use the overlay2 storage driver with a dedicated volume for each container.

Why it fails: The overlay2 storage driver is a performance and layering mechanism, not a security boundary. Giving each container a dedicated volume may help with data separation but does not restrict capabilities, root execution, or filesystem writes. It does not materially prevent container breakout or privilege escalation on the node.

Enable audit logging on the Kubernetes API server and ship logs to a central SIEM for alerting.

Why it fails: Audit logging provides visibility and forensic evidence, which is valuable for detection and compliance, but it is a detective control. It does not prevent a compromised container from escalating privileges or breaking out to the node. The question asks for measures that reduce the attack surface and prevent escalation, not merely detect it.

Web Application Firewall (WAF) deployment

Why it fails: A WAF filters HTTP traffic at the network edge in production, after deployment, so it cannot inspect source code, dependencies or artefacts during pipeline stages. It is tempting because it is a core application security control, but it addresses runtime threats rather than shifting detection earlier into the CI/CD pipeline.

Runtime Application Self-Protection (RASP)

Why it fails: RASP instruments a running application to detect and block attacks at execution time, which occurs in production, not during CI/CD build or commit stages. It is tempting because it is a genuine application security control, but it belongs in runtime protection alongside WAFs, not in shift-left pipeline scanning.

Implement runtime application self-protection (RASP)

Why it fails: RASP instruments a running application to detect attacks in-process; it operates after the image is deployed and cannot scan or sign image artefacts during the build. It is tempting because RASP protects containerised workloads at runtime, which is the correct choice for blocking exploitation attempts, not for enforcing image integrity in the pipeline.

Use a cloud WAF to protect the containerized application

Why it fails: A cloud WAF inspects inbound HTTP/S traffic at the application edge; it cannot scan image layers, base images or package manifests inside a registry, so it does not enforce image security. It is tempting because WAFs protect containerised workloads at runtime, which is the correct choice for filtering malicious web requests, not for validating images during CI/CD.

Run SAST on the application source code

Why it fails: SAST analyses application source code for coding flaws; it does not inspect container image layers, installed OS packages or base image provenance, so it cannot enforce image security. It is tempting because SAST runs early in the CI/CD pipeline, which is the correct choice for catching code-level vulnerabilities before the image is built.

Lack of encryption options

Why it fails: Cloud providers offer customer-managed keys, HSM-backed encryption and per-object controls, so encryption availability is not the constraint; the challenge is holding keys and proving custody across jurisdictions. It is tempting because encryption is a standard data-protection control, and would be correct if the provider offered no encryption at all.

Excessive cost of cloud storage

Why it fails: Storage cost is a commercial matter, not a legal obstacle; eDiscovery turns on where data resides and which jurisdiction's process governs its disclosure. It is tempting because multi-region replication does generate egress and duplication charges, which would be the answer if the question asked about financial rather than legal exposure.

Expose all API endpoints automatically for transparency

Why it fails: Auto-exposing every endpoint enlarges the attack surface and reveals undocumented routes attackers can probe. It appeals as a transparency or discovery convenience, yet recommended API security requires explicit, authenticated exposure of only intended endpoints, with the rest disabled or hidden.

Allow mass assignment for ease of development

Why it fails: Mass assignment lets clients set object properties they should never control, enabling privilege escalation and data tampering. It is tempting because it speeds CRUD development, but secure APIs bind only explicitly permitted fields; mass assignment is never a recommended hardening practise.

Higher likelihood of vendor lock-in due to proprietary services

Why it fails: Multi-cloud reduces lock-in by design, since workloads can migrate between providers; lock-in is the concentration risk that single-cloud adoption creates. The option tempts because proprietary services do cause lock-in, but that applies within one provider, not across several.

Greater difficulty in meeting data sovereignty requirements across jurisdictions

Why it fails: Multi-cloud spreads data across more jurisdictions, which can ease sovereignty alignment rather than hinder it, since workloads may be placed in-region. The difficulty arises in single-cloud or hybrid designs spanning regions; here the added provider contracts do not themselves create the sovereignty burden described.

A SOC 2 Type II report covering the provider's security controls in each region

Why it fails: A SOC 2 report attests to security, availability, or confidentiality controls but is not a GDPR transfer mechanism. It can support due diligence and demonstrate that encryption or access controls exist, yet it does not provide the legal basis required by Chapter V. A provider could hold a clean SOC 2 report and still lack a valid transfer safeguard.

Registration of the cloud provider as a data controller with the customer's supervisory authority

Why it fails: Registering a provider as a controller does not create a transfer safeguard, and the provider typically acts as a processor in this arrangement. Controller registration obligations apply to the controller's own processing activities and do not substitute for an Article 45 or Article 46 mechanism. This option mischaracterizes both the provider's role and the transfer requirements.

An ISO/IEC 27701 certification held by the cloud provider

Why it fails: ISO/IEC 27701 extends ISO/IEC 27001 to privacy information management and can evidence a mature privacy program, but it is not a recognized Chapter V transfer tool. Certification does not bind the provider to specific data subject rights or government-access protections the way SCCs do. It may support the transfer impact assessment but cannot replace the required legal mechanism.

Data masking is a form of encryption.

Why it fails: Masking is not encryption; it substitutes data rather than encoding it.

Data masking is primarily used for production environments.

Why it fails: Masking is used in non-production to protect original data.

Data masking is reversible.

Why it fails: Masking is designed to be irreversible to prevent re-identification.

Ensuring data is accessible only via a specific IP range

Why it fails: IP-range restriction governs network access control, not erasure; it neither locates nor deletes replicated object versions. It is tempting because restricting access limits exposure, and it would be correct when the requirement is to confine data reach to trusted networks rather than to remove personal data entirely.

Encrypting the data at rest with customer-managed keys

Why it fails: Customer-managed keys protect confidentiality; they do not remove replicated object versions, so erasure remains unfulfilled. Encryption is tempting because it can render data unreadable, and it would be correct when the requirement is to control cryptographic access rather than to delete the data itself.

Exporting data in a machine-readable format

Why it fails: Machine-readable export supports GDPR portability, not erasure; it neither finds nor deletes object versions across replicas. It is tempting because both rights appear in the same regulation, and export would be correct when a data subject requests their data in a portable format rather than its deletion.

Configure IP whitelisting for all users

Why it fails: Whitelisting every user's address is unworkable and, applied at the gateway, restricts callers by network origin rather than authenticating them. It is tempting because IP filtering is a legitimate gateway control when the consumer set is a known, fixed range of partner or corporate addresses.

Store secrets in Azure Function environment variables

Why it fails: Environment variables hold configuration inside the Function App, not at the API Management gateway, so they secure nothing at the boundary the question targets. It is tempting because secret storage is genuine security work, and it would be correct for protecting connection strings consumed by the function code itself.

Disable API keys

Why it fails: Disabling API keys removes a gateway-level authentication mechanism rather than adding one, leaving endpoints open unless another scheme replaces it. It is tempting because API keys are weak shared secrets, so disabling them is defensible when subscription keys are superseded by OAuth 2.0 or Microsoft Entra ID tokens.

PrivateLink for database access

Why it fails: PrivateLink exposes a service privately to other VPCs or accounts; it cannot inspect HTTP traffic for web attacks, nor filter tier-to-tier flows. It is tempting because it secures database access by removing internet exposure, which would be correct if the requirement were private connectivity to a database rather than application-layer protection.

VPC peering with all VPCs

Why it fails: VPC peering merely connects networks, permitting traffic by default once routes and security groups allow it; it provides no application-layer inspection and no tier segmentation. It is tempting because peering is the standard way to join VPCs, and would be correct where two VPCs must exchange traffic privately without a transit gateway.

Network ACLs for each subnet

Why it fails: Network ACLs are stateless subnet-level filters operating on IP, port and protocol; they cannot detect SQL injection or cross-site scripting at the application layer. They are tempting because they do restrict traffic between tiers, and would be correct where the requirement is coarse subnet-level allow/deny rules rather than web attack inspection.

Enabling CORS (Cross-Origin Resource Sharing) for all domains

Why it fails: Wildcard CORS permits any origin to read responses, so a malicious site can invoke the API with the victim's ambient credentials. CORS is legitimately used to restrict which specific trusted origins a browser may call, but only when scoped to named domains rather than all.

Using HTTP basic authentication over plain HTTP

Why it fails: Basic authentication transmits base64-encoded credentials, which are trivially decoded on the wire, so plain HTTP exposes them to interception. Basic auth is acceptable only when tunnelled inside TLS, where the transport encrypts the header in transit.

Sarbanes-Oxley Act (SOX)

Why it fails: The Sarbanes-Oxley Act (SOX) is a financial reporting and corporate governance law for public companies. It does not impose any geographic storage requirements on data, so it is not a data sovereignty law.

California Consumer Privacy Act (CCPA)

Why it fails: The California Consumer Privacy Act (CCPA) is a privacy law that grants consumers rights over their personal data, but it does not mandate where data must be stored geographically. Therefore, it is not a data sovereignty law.

Payment Card Industry Data Security Standard (PCI DSS)

Why it fails: The Payment Card Industry Data Security Standard (PCI DSS) is a security standard for protecting payment card data. It does not include any data localization requirements, so it is not a data sovereignty law.

Health Insurance Portability and Accountability Act (HIPAA)

Why it fails: The Health Insurance Portability and Accountability Act (HIPAA) is a healthcare privacy and security law. It does not mandate specific geographic storage locations for data, so it is not a data sovereignty law.

Greater control over the underlying OS

Why it fails: PaaS abstracts the operating system, so customers lose OS-level control rather than gaining it; that control is an IaaS advantage. It is tempting because control sounds beneficial, and IaaS would be the right choice when the workload demands custom OS configuration, patching or kernel-level tuning.

Lower cost due to shared infrastructure

Why it fails: Shared infrastructure lowers cost for both IaaS and PaaS, so it does not distinguish them as a PaaS advantage. It is tempting because multi-tenancy genuinely reduces spend, and cost savings would be a valid selection criterion when comparing cloud against on-premises ownership rather than PaaS against IaaS.

Higher flexibility to customize networking

Why it fails: PaaS constrains networking customisation because the provider manages the platform layer, whereas IaaS exposes virtual networks, subnets and security controls for full configuration. It is tempting because flexibility sounds desirable, and IaaS is correct when the design requires bespoke routing, firewalls or network segmentation.