Hard Difficulty Questions

Site-to-Site VPN

Why it fails: A Site-to-Site VPN traverses the public internet, failing the private-connectivity requirement. It tempts because it is quick to deploy and encrypts traffic, but encryption does not make the path private; AWS Direct Connect provides a dedicated private circuit instead.

Client VPN

Why it fails: A Client VPN tunnels a single remote device to a VPC over the public internet, so it cannot provide the private, dedicated link between an on-premises data centre and a VPC that the scenario demands. It is tempting because it does grant remote users access to VPC resources, which is its actual purpose.

Public IP peering

Why it fails: Public IP peering routes traffic over public internet exchange points, breaching the private-connectivity requirement. It tempts because peering can reduce latency and cost for public workloads, but it offers no dedicated private path; AWS Direct Connect is the private option.

Employee training manuals

Why it fails: Employee training manuals are awareness material, not incident-specific procedures such as roles, escalation paths, containment steps and communication plans. They are tempting because training documentation is a real part of a security programme, and would be correct when addressing ongoing security awareness rather than response planning.

Budget approval workflows

Why it fails: Budget approval workflows govern financial authorisation, not detection, containment, eradication, recovery or post-incident review, so they contribute nothing during an active incident. They are tempting because they belong in financial governance and change-management documentation, where spend sign-off genuinely matters.

Client-side encryption with a key stored in AWS Secrets Manager and S3 access logging enabled.

Why it fails: Client-side encryption places key management burden on the application and Secrets Manager stores secrets but is not a hardware security module-backed key management service with rotation schedules for data keys. S3 access logging records object requests, not cryptographic key usage. This approach complicates operations and still lacks the required key-usage audit trail.

S3 default encryption with SSE-S3 and S3 server access logging enabled on the bucket.

Why it fails: SSE-S3 uses AWS-managed keys that the customer does not control and cannot rotate on a customer-defined schedule. S3 server access logging records bucket requests but does not log key usage events. This combination provides encryption at rest but fails the control, rotation, and key-usage logging requirements the auditor specified.

S3 default encryption with SSE-KMS using an AWS managed key and S3 Object Lock in compliance mode.

Why it fails: An AWS managed key is created and rotated by AWS, and the customer cannot define a custom rotation schedule or key policy, so it fails the control requirement. S3 Object Lock prevents deletion or modification for a retention period, which is a data immutability control, not key usage logging. This combination does not meet the auditor's key governance expectations.

Use a content delivery network to cache dynamic API responses at edge locations.

Why it fails: Content delivery networks excel at caching static assets, but caching dynamic API responses for a trading application risks serving stale prices and can violate consistency requirements. While edge presence reduces latency for cacheable content, it does not address the need for real-time, consistent transaction processing across regions.

Increase the size of the database instance to handle more concurrent connections.

Why it fails: Vertical scaling improves throughput and connection capacity but does not reduce network round-trip time between distributed users and the application. A larger database in one location still forces remote users to traverse long network paths, so this does not address the latency requirement or provide regional fault tolerance.

Consolidate all application instances into a single region with the lowest average latency to all users.

Why it fails: A single region cannot be closest to users spread across multiple continents, so many users would experience higher latency. It also creates a single point of failure, undermining the high availability requirement. Consolidation reduces operational complexity but directly conflicts with the latency and resilience goals of this scenario.

A physical server monitoring camera

Why it fails: A physical server monitoring camera captures video of hardware; it produces no billing, usage or tagging data, so it cannot attribute or constrain cloud spend. It tempts because on-premises monitoring feels like governance, but cost control requires tools such as Microsoft Cost Management, budgets and tagging policies that read resource consumption.

The company's external marketing agency

Why it fails: An external marketing agency is a third-party service provider, not a management tool, and holds no access to cloud billing or resource metadata. It tempts because agencies often manage cloud-hosted campaigns, but cost control needs native instruments like Microsoft Cost Management, budgets, alerts and resource tagging that query actual consumption data.

To connect two VPCs

Why it fails: Connecting two VPCs is performed by VPC peering or a Transit Gateway, which route traffic between CIDR ranges. A VPC endpoint instead attaches privately to a supported AWS service such as S3 or DynamoDB, so it cannot join two VPC networks.

To encrypt data transit

Why it fails: Encryption in transit is handled by TLS at the application or load-balancer layer, not by a VPC endpoint. Endpoints give private connectivity to AWS services without traversing the internet, so they are chosen when the requirement is avoiding public routing, not confidentiality of packets.

To provide public access

Why it fails: A VPC endpoint keeps traffic within the AWS private network, so it cannot provide public access; it removes the need for an internet gateway, NAT device or public IP. Public exposure is instead achieved through an internet-facing load balancer or API Gateway, which is what this option describes.

Canary release

Why it fails: Canary releases expose a subset of live production users to the update, so verification occurs in production rather than a controlled environment. They are tempting for limiting blast radius, but a staging or blue-green environment is required for pre-production validation.

In-place upgrade

Why it fails: In-place upgrades modify the existing production resource directly, so the downtime-causing update is applied without prior verification. They are tempting for avoiding duplicate infrastructure, but a blue-green deployment validates changes in a separate environment first.

Rolling update

Why it fails: Rolling updates replace instances incrementally in production, so they still expose live users to the faulty change. They are tempting for maintaining availability during deployment, but a blue-green or staging environment is needed to verify updates before production.

Internet Gateway

Why it fails: An internet gateway attaches to the VPC and enables public subnets to reach the internet, but a private subnet requires a NAT gateway for outbound traffic instead. It is tempting because the gateway is genuinely the egress component, and would be correct if the subnet were public and hosted the instance directly.

VPC Endpoint

Why it fails: A VPC endpoint connects privately to specific AWS services, not the public internet, so it cannot serve the general update download described. It is tempting because endpoints do provide private-subnet connectivity, and would be correct if the application needed to reach S3 or DynamoDB without traversing the internet.

Route Table

Why it fails: A route table already exists in every subnet; the missing element is the route entry directing 0.0.0.0/0 traffic to a NAT gateway or internet gateway. It is tempting because routing is genuinely required for egress, and a misconfigured route table would be the correct diagnosis if routes were absent.

Create an IAM user for them

Why it fails: A permanent IAM user with long-lived credentials grants ongoing access, not temporary, and violates least privilege for a one-off third-party share. It is tempting because IAM identities are the standard way to grant bucket access to known principals. A presigned URL instead issues time-limited, scoped access without creating an identity.

Email the file

Why it fails: Emailing the file removes it from bucket controls entirely, leaving copies in mail servers and the recipient's inbox with no expiry or revocation. It is tempting because it is quick and needs no cloud configuration. A presigned URL keeps the object private while granting time-limited, revocable access to the specific object.

Make the bucket public

Why it fails: Making the bucket public exposes every object to anonymous internet access indefinitely, far exceeding the single-file, temporary requirement. It is tempting because it is a one-click change that guarantees the third party can download. A presigned URL grants scoped, expiring access to one object while the bucket stays private.

Use a cloud access security broker to inspect data in transit between regions.

Why it fails: A cloud access security broker provides visibility and policy enforcement for cloud service usage, often focusing on data in motion and shadow IT. It does not prevent a database from storing records in a disallowed region. Inspecting traffic does not change the physical storage location, so it cannot satisfy the residency mandate.

Enable geo-restriction at the content delivery network edge for all customer traffic.

Why it fails: CDN geo-restriction controls where content is served or blocks requests by geography; it does not control where data is stored. Customer records could still be written to a database in another region. This control addresses access and delivery, not the physical location of stored records, so it fails the residency requirement.

Apply resource tags indicating the customer's country and use them in cost allocation reports.

Why it fails: Tags are metadata used for organization, automation, and billing; they do not constrain where resources are created or where data is stored. A tagged resource can still reside in any region. Tagging therefore documents intent but provides no technical enforcement of data residency, making it unsuitable as the primary control.

S3 Versioning

Why it fails: S3 versioning preserves prior object versions to aid recovery from overwrites or deletions; it does not acquire or release a lock during apply, so concurrent CI/CD runs still collide. Versioning suits durability and rollback requirements, not preventing simultaneous state modifications.

Terraform Cloud Workspaces

Why it fails: Terraform Cloud workspaces provide remote state storage and run coordination, but locking is enforced by the workspace's own execution model rather than a configurable backend lock mechanism for arbitrary multi-cloud backends. It suits teams wanting managed remote runs, not explicit backend-level locking.

IAM Policy

Why it fails: An IAM policy grants or denies API actions on resources; it cannot acquire a state lock or block a concurrent Terraform apply mid-run. IAM policies suit access control and least-privilege enforcement, not serialising state writes across pipeline executions.

Access Logs

Why it fails: Access logs record who accessed a resource and when; they are an auditing output, not a retention control, so they cannot make stored audit logs immutable or block deletion. Tempting because audit trails and access logs are both logging artefacts, and access logging would be the right answer if the requirement were visibility into data-plane reads rather than write-once retention.

Versioning

Why it fails: Versioning retains prior object versions after overwrite or delete, but a user with delete permissions can still remove versions or the bucket lifecycle can expire them, so retention is not enforced. Tempting because versioning is often paired with immutability, and it would be correct if the requirement were recovering accidentally overwritten logs rather than guaranteeing non-deletion.

Encryption

Why it fails: Encryption protects confidentiality of log contents but does not prevent a privileged user or lifecycle rule from deleting the object, so immutability and retention are unmet. Tempting because encryption is a common compliance control for audit data, and it would be correct if the requirement were protecting logs from unauthorised disclosure rather than deletion.

Public cloud multi-tenant

Why it fails: Multi-tenant public cloud places the database on infrastructure shared with unrelated tenants, which cannot satisfy strict regulatory mandates for dedicated, audited hosting. It is tempting because it offers rapid provisioning and low cost, and would be correct for non-regulated workloads with no data-residency or isolation obligations.

Community cloud

Why it fails: A community cloud is shared by organisations with common concerns, so the database still resides on infrastructure governed by other members rather than the company alone. It is tempting because members share compliance burdens, and would be correct where several agencies with identical regulatory frameworks jointly need the same controls.

Serverless functions

Why it fails: Serverless functions are a compute execution model, not a deployment model, so they cannot define where a regulated database resides or who controls its isolation. It is tempting because it removes server management, and would be correct for event-driven, stateless processing tasks rather than persistent regulated data stores.

Re-hosting (Lift and Shift)

Why it fails: Re-hosting moves the unsupported OS unchanged to cloud infrastructure, so the provider still cannot patch or support it. It tempts because lift and shift is the fastest, lowest-effort migration, and would suit a scenario where the OS remains vendor-supported and minimal change is required.

Retaining

Why it fails: Retaining keeps the legacy OS running on-premises, which fails the requirement to migrate the application to the cloud. It suits workloads that cannot be moved due to regulatory, latency or licensing constraints, where decommissioning is impossible. Here, the unsupported OS is precisely what migration should eliminate.

Retiring

Why it fails: Retiring decommissions the application entirely, which contradicts a migration where the workload must keep running on a supported OS. It is tempting because retiring is the right strategy when an application is redundant or obsolete with no business need; here the legacy application is still required, so it must be rehosted or replatformed instead.

The provider's quarterly stock earnings report

Why it fails: Earnings reports disclose revenue, margins and shareholder returns, not control environments or uptime commitments. They are tempting because they are public and quantify financial stability, which matters when assessing vendor viability, but reliability and security posture are evidenced by audit reports such as SOC 2 and ISO 27001 certifications.

Employee payroll records

Why it fails: Payroll records expose employee compensation, not the controls protecting customer data or service availability. They are tempting because staff vetting and personnel screening support physical and operational security, but that evidence appears in audit attestations and certification reports, not in individual remuneration data.

Internal office floor plans

Why it fails: Floor plans show physical layout, not logical access controls, encryption or availability guarantees. They are tempting because physical security is a genuine component of a CSP assessment, and building layouts would inform a data centre site inspection, but the question asks for business-focused documentation evidencing reliability and security posture.

Auto-scaling groups

Why it fails: Auto-scaling groups adjust compute capacity in response to demand; they neither record processing purposes nor restrict where personal data resides, so they satisfy no GDPR accountability or residency obligation. They are tempting because elasticity is a core cloud benefit, and would be correct when the requirement is handling variable workload without manual provisioning.

Multi-region replication

Why it fails: Multi-region replication copies data across jurisdictions, which can itself create unlawful transfers of EU personal data unless a lawful transfer mechanism and residency controls are in place. It is tempting because durability and availability sound like governance, and would be correct when the requirement is disaster recovery or low-latency read access across regions.

Public IP addresses

Why it fails: Public IP addresses expose resources to the internet and provide no mechanism for controlling where personal data is stored, processed or transferred, which is what GDPR obligations require. They are tempting because network reachability feels like control, and would be correct when the requirement is inbound connectivity to a publicly accessible service.

Configure a horizontal pod autoscaler to increase the replica count based on CPU utilization

Why it fails: A horizontal pod autoscaler adds more pod replicas, but the scenario already states that new pods cannot be scheduled because nodes are under resource pressure. Adding replicas without additional node capacity leaves pods pending. The immediate constraint is cluster capacity, so scaling the workload alone will not relieve the scheduling failures described.

Increase the CPU request and limit values on the existing application deployment

Why it fails: Raising requests and limits changes how much resource each pod reserves, but it does not create new node capacity. In fact, larger requests make scheduling harder because fewer pods fit on each node. This would worsen the pending-pod condition rather than relieve the node pressure observed during the flash sale.

Create a pod disruption budget to guarantee minimum availability during scaling events

Why it fails: A pod disruption budget constrains voluntary evictions so that a minimum number of replicas stays running during maintenance or node drains. It protects availability but does not add compute capacity or respond to rising demand. It cannot resolve unschedulable pods caused by insufficient node resources, so it does not meet the stated requirement.

Static hardware provisioning

Why it fails: Cloud computing requires rapid elasticity and on-demand self-service, so capacity is provisioned dynamically in response to demand; static hardware provisioning describes traditional on-premises infrastructure. It is tempting because reserved instances and dedicated hosts involve committed capacity, yet even those remain software-provisioned and elastically adjustable rather than fixed hardware.

Physical media access

Why it fails: Cloud characteristics are on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service; physical media access contradicts broad network access, since consumers reach services over the network rather than handling media. It is tempting because providers do use physical media internally for backup and transport, but that is invisible to consumers.

AWS Config

Why it fails: AWS Config records resource configuration changes and evaluates them against rules, but it does not natively run CIS Benchmark checks; that requires AWS Security Hub with the CIS standard enabled. Config is tempting because it does perform compliance evaluation, and it would be correct for custom configuration rules you author yourself.

AWS Systems Manager

Why it fails: Systems Manager provides operational tooling such as patching, Run Command and State Manager, and its compliance view only reflects those patch and association states, not CIS Benchmark controls. It is tempting because it displays a compliance dashboard, but that is correct only for reporting on Systems Manager-managed patch and association baselines.

AWS CloudTrail

Why it fails: CloudTrail logs API activity for auditing who did what and when, recording events rather than evaluating resource configuration against CIS controls. It is tempting because compliance reporting often draws on audit trails, but CloudTrail is correct when you need an immutable record of account API calls, not benchmark posture findings.

Patching the hypervisor that hosts virtual machines

Why it fails: Patching the hypervisor is typically the cloud provider's responsibility in a public cloud IaaS model. The provider manages the physical infrastructure and virtualization layer, while the customer is responsible for the guest operating system and applications. Therefore, this is not a customer responsibility.

Managing the lifecycle of encryption keys stored in a hardware security module (HSM)

Why it fails: While customers can manage their own keys, the responsibility depends on the service model. In many cloud services, the provider manages the HSM and key lifecycle if using provider-managed keys. However, even with customer-managed keys, the provider secures the HSM hardware. This is not a universal customer responsibility under the shared responsibility model, and the question asks for customer responsibilities in a public cloud context.

Ensuring physical security of data center facilities

Why it fails: Physical security of data centers is always the cloud provider's responsibility. The provider controls access, surveillance, and environmental controls. Customers do not have physical access to these facilities, so they cannot be responsible for this aspect of security.