Hard Difficulty Questions

VPC flow logs

Why it fails: Virtual network flow logs capture traffic metadata but do not include details about storage operations like requester identity or object-level access.

Cloud management events (e.g., CloudTrail equivalent)

Why it fails: Cloud API activity logs (management events) log control-plane operations, not data-plane operations such as object reads.

Log aggregation service for storage (e.g., CloudWatch equivalent)

Why it fails: Cloud monitoring logs for object storage may provide aggregate metrics but not granular details about individual requests.

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.

Consent from all data subjects

Why it fails: Consent is not a practical mechanism for large-scale transfers and must be specific and informed.

Binding Corporate Rules (BCRs)

Why it fails: BCRs are for transfers within a corporate group, not for transfers to external third parties.

Privacy Shield

Why it fails: Privacy Shield was invalidated by the European Court of Justice and is no longer a valid mechanism.

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.

The employee intentionally accessed the data from that country

Why it fails: Deliberate access by the legitimate employee would not explain the foreign IP unless the employee was abroad; the scenario's framing points to credential compromise, such as phishing or credential stuffing, where stolen credentials are replayed from attacker infrastructure. It is tempting because insider threat is a valid vector, but only when evidence ties the employee to the activity.

A distributed denial-of-service (DDoS) attack overwhelmed access controls

Why it fails: A DDoS attack saturates availability; it does not authenticate as a user or grant access to a bucket. The logs show successful authenticated access from a foreign IP, which points to stolen credentials. DDoS would be the answer if the symptom were service unavailability rather than unauthorised data retrieval.

The cloud storage bucket was misconfigured as public

Why it fails: A public bucket would allow unauthenticated access without using the employee's credentials, yet the logs show those specific credentials were used, indicating credential compromise rather than exposure. Public buckets are the right finding when anonymous requests appear in access logs, not authenticated ones from an unexpected location.

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.

Store credentials as environment variables in the pod manifest

Why it fails: Environment variables in a pod manifest are static, visible to anyone with pod-spec read access, and cannot rotate without redeploying the workload, so they fail the rotation requirement. They suit non-sensitive configuration such as feature flags or log levels, where values rarely change and exposure carries no credential risk.

Embed credentials in the container image during build

Why it fails: Embedding credentials in the image bakes static secrets into every layer, so rotation requires rebuilding and redeploying, and anyone pulling the image can extract them. It is tempting because image builds routinely inject configuration, and this works for non-sensitive, immutable defaults. Secrets management, not image baking, satisfies the rotation requirement.

Use Kubernetes Secrets without encryption at rest

Why it fails: Unencrypted Kubernetes Secrets are stored as base64 in etcd, readable by anyone with API or etcd access, and lack automated rotation. Kubernetes Secrets suit non-sensitive configuration; encrypted secrets with an external rotation controller are needed here.

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.

Use a condition in the policy that checks the source IP address.

Why it fails: Lambda invocations originate from AWS service infrastructure, not fixed addresses, so an IP condition cannot identify the calling bucket or account. It is tempting because IP restrictions genuinely secure API Gateway or on-premises callers with stable egress ranges.

Place the Lambda function inside a VPC with a VPC endpoint for S3.

Why it fails: A VPC endpoint governs the function's outbound traffic to S3, not which buckets or accounts may invoke it; invocation authorisation lives in the resource-based policy. It is tempting because VPC placement is a real hardening step for data exfiltration paths, but it addresses egress, not ingress.

Attach a resource-based policy that allows any S3 bucket to invoke the function.

Why it fails: Allowing any S3 bucket to invoke the function is precisely the cross-account exposure the architect must prevent, so it inverts the requirement. It is tempting because broad invoke permissions simplify initial event-source wiring during prototyping, before source-account restrictions are added.

Set allowPrivilegeEscalation to true

Why it fails: Setting allowPrivilegeEscalation to true permits a process to gain more privileges than its parent, directly weakening container isolation, so it contradicts the hardening goal. It is tempting because some workloads need setuid binaries or sudo, but the secure setting is false unless a documented exception exists.

Use a more restrictive runAsUser value like 2000

Why it fails: Changing runAsUser to 2000 alters the UID but does not itself restrict capabilities, privilege escalation, or filesystem access, so the pod's excessive permissions remain. It is tempting because non-root UIDs are a hardening step, and it is correct when the exhibit shows the container running as UID 0.

Use a trusted image from a private registry

Why it fails: A trusted private-registry image addresses provenance and supply-chain integrity, but the exhibit's pod already references an image; the missing control concerns runtime privilege context, which registry choice does not alter. It is tempting because image trust is a genuine best practice, and it is correct when the pod pulls from an untrusted public source.

Runtime security monitoring

Why it fails: Runtime monitoring inspects running containers, so a vulnerable image has already been deployed before detection. It suits detecting live exploits and anomalous behaviour, but the stem requires scanning before deployment, which an image-scanning gate in the build stage satisfies.

Pre-commit hook in source control

Why it fails: A pre-commit hook runs on source code before an image exists, so it cannot scan container layers or base-image packages. It suits secret detection and linting at commit time, but the stem requires scanning built images before deployment, which a pipeline stage after the build performs.

Admission controller in Kubernetes

Why it fails: An admission controller evaluates pods at deploy time, after the image is built and pushed, so scanning there blocks at the cluster rather than in the pipeline. It suits enforcing cluster policy, but the stem asks for the pipeline integration point, which a build-stage scan provides.

Patching of the hypervisor

Why it fails: Patching the hypervisor is the provider's responsibility.

Network firewall configuration

Why it fails: In IaaS, the provider manages the underlying network, but the customer may manage firewalls; however, encryption is more directly the customer's responsibility.

Physical security of the data center

Why it fails: Physical security is typically the provider's responsibility.

Deny access because the request does not meet the SecureTransport condition

Why it fails: Incorrect: The request does meet SecureTransport, but Deny still applies.

Allow access because the condition for Deny does not include SecureTransport

Why it fails: Incorrect: Deny does not require SecureTransport condition to block.

Allow access because the request uses HTTPS

Why it fails: Incorrect: The Deny overrides the Allow.

The policy restricts read access to a specific role, which is too permissive

Why it fails: Restricting read access to a specific role is appropriate.

The policy does not enable server-side encryption

Why it fails: Server-side encryption is not configured in the policy, but this is not a security issue with the policy itself.

The policy contains a syntax error in the JSON

Why it fails: The JSON is syntactically correct.

Requests from 10.0.0.0/24 over HTTP are allowed because the Allow statement matches.

Why it fails: The Deny statement explicitly denies non-HTTPS requests, overriding the Allow.

The policy is invalid because it combines Allow and Deny statements.

Why it fails: Combining Allow and Deny statements is valid; explicit deny overrides allow.

All requests from 10.0.0.0/24 are denied because the Deny statement applies to all actions.

Why it fails: The Deny only applies when SecureTransport is false; HTTPS requests are not denied.

Use TLS 1.3 to encrypt all traffic between clients and the gateway.

Why it fails: TLS 1.3 encrypts data in transit, protecting confidentiality and integrity, but it authenticates neither the client nor the request volume, so an attacker with a valid session can still flood the gateway. Transport encryption is the right control when the threat is interception or tampering, not abuse.

Validate and sanitize all input parameters to prevent injection attacks.

Why it fails: Input validation blocks injection payloads reaching backend services, yet it does not limit request frequency, so credential-stuffing or enumeration floods pass through untouched. Sanitising parameters is correct when the threat is malformed data corrupting queries, not the request rate itself.

Require API keys for all requests and revoke keys of suspicious clients.

Why it fails: API keys identify the calling application but are static shared secrets, so a leaked or embedded key grants full access until revoked; they cannot stop volumetric abuse from many distinct clients. API keys suit simple partner identification, not the dynamic per-client throttling and anomaly detection this scenario demands.

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.

Physical security of the data center housing the cloud servers

Why it fails: Physical data centre security belongs to the cloud provider, which owns and operates the facilities under the shared responsibility model. The institution's ITGC obligations concern logical access, change management, and application controls it configures. Physical security would be the institution's concern only for on-premises or colocated infrastructure it directly controls.

Network intrusion detection at the cloud perimeter

Why it fails: Perimeter intrusion detection monitors the cloud provider's network boundary, which the provider operates under the shared responsibility model. The customer's ITGC scope covers its own applications, identity, and data. Intrusion detection at the perimeter would fall to the institution only in self-hosted or IaaS-managed network scenarios.

Patching of the hypervisor that hosts the virtual machines

Why it fails: Hypervisor patching sits with the cloud provider, who owns and operates the physical hosts and virtualisation layer under the shared responsibility model. It tempts because ITGC scoping often includes platform hardening, and in IaaS or on-premises deployments the customer would indeed patch the hypervisor themselves.