Hard Difficulty Questions

Using a content delivery network (CDN) to cache data globally.

Why it fails: A CDN caches content at edge locations worldwide, which could violate data residency requirements by storing data outside the specified country. While CDNs improve performance, they are not suitable for strict data residency because they replicate data across global points of presence, potentially breaching legal constraints.

Using a global load balancer to distribute traffic across continents.

Why it fails: A global load balancer distributes traffic across continents, which would route data to servers outside the required country, violating data residency. While it enhances global availability, it directly conflicts with the need to keep data within a specific country. This approach is inappropriate for the scenario.

Implementing a multi-region active-active architecture.

Why it fails: A multi-region active-active architecture would replicate data across regions, which likely violates data residency if regions are in different countries. Even if both regions are within the same country, it increases complexity and cost without necessarily improving availability beyond what multiple availability zones provide. It is not the most critical consideration for strict residency.

Network throughput (bytes in/out)

Why it fails: Network throughput is not a required metric for the given requirements.

Memory utilization

Why it fails: Memory is not mentioned as a scaling metric in the scenario.

Remove the firewall rule entirely and rely on database IAM authentication.

Why it fails: Removing the rule blocks the remote developers the stem requires to keep working, since IAM authentication governs identity, not network reachability. Removing public exposure entirely is correct only when no external access is needed, such as an internal-only database.

Enable encryption in transit using TLS and keep the rule as is.

Why it fails: TLS encrypts traffic but leaves port 3306 reachable from every internet address, so the exposure the audit flagged persists. Encryption suits protecting data crossing untrusted networks, yet the requirement is restricting who can connect; the rule must be scoped to developer source addresses or a VPN/bastion instead.

Move the database to a private subnet without a NAT gateway.

Why it fails: A private subnet without a NAT gateway has no outbound path, so remote developers cannot reach the database at all, breaking the stated requirement. This isolation suits databases with no external connectivity needs, such as backend-only stores accessed from within the VPC.

Encrypt the data on-premises before uploading to the cloud

Why it fails: Client-side encryption before upload bypasses the provider's native encryption service and leaves key custody outside it, failing the stated requirement. It is tempting because pre-upload encryption genuinely protects data in transit and at rest, which would be correct where provider-managed keys are prohibited.

Use the cloud provider's default encryption with provider-managed keys

Why it fails: Provider-managed keys leave the cloud provider holding and controlling the key material, so the company loses the custody the regulation demands. It is tempting because default encryption is native, free and instant, and would satisfy the requirement where the regulation mandates encryption at rest but imposes no key-ownership condition.

Use a third-party hardware security module (HSM) hosted on-premises

Why it fails: A third-party on-premises HSM provides customer-controlled keys but not the cloud provider's native encryption service, so it breaches the regulation's explicit requirement. It is tempting because external HSMs genuinely deliver key custody and FIPS 140-2 separation, and would be right where the mandate demands keys never reside with the provider.

Modify the policy file to accept t2.large and t2.xlarge.

Why it fails: Modifying the policy defeats the purpose of compliance.

Ignore the compliance check because it is advisory.

Why it fails: Compliance checks are typically mandatory; ignoring them could lead to violations.

Delete the non-compliant VMs.

Why it fails: Deleting non-compliant VMs would remove the offending resources, but the scenario requires remediation of a configuration drift detected by Azure Policy, not resource elimination; the correct action is to apply a policy remediation task to reapply the compliant configuration. This option is tempting because deleting non-compliant objects is a valid approach in scenarios where the resource itself is the violation, such as removing an unauthorised VM in a locked-down subscription, rather than correcting a policy-defined setting.

Horizontal Pod Autoscaler

Why it fails: HPA scales pods based on CPU/memory, not for canary rollout automation.

Kubernetes Service with label selectors

Why it fails: A Service alone does not provide traffic splitting by percentage.

A security information and event management (SIEM) system.

Why it fails: A SIEM correlates security events and generates threat alerts, but it does not aggregate application logs or service metrics for operational monitoring across microservices. It is tempting because SIEM genuinely centralises and correlates data, and would be correct if the requirement were security incident detection rather than operational observability.

An application performance monitoring (APM) tool.

Why it fails: APM tools trace application transactions and latency within instrumented services, but they do not provide the centralised log aggregation or cross-service log correlation the solution demands. They are tempting because APM genuinely covers metrics and alerting for service performance, and would be correct if distributed tracing alone were required.

Refactor

Why it fails: Refactor requires significant code changes to use cloud-native database features.

Rehost

Why it fails: Rehost would retain the HSM dependency, which is not supported in the cloud.

Rebuild

Why it fails: Rebuild involves completely rewriting the application, which is more effort.

AWS Snowball

Why it fails: Snowball is an offline device, not over the internet.

S3 Transfer Acceleration

Why it fails: S3TA uses edge locations but may not achieve the required speed for 200 TB in 5 days at 1 Gbps (max ~54 TB).

AWS Direct Connect

Why it fails: Direct Connect is a dedicated network connection, not a data transfer service.

terraform plan

Why it fails: Plan shows changes but does not update state.

terraform import

Why it fails: `terraform import` attaches existing cloud resources to a Terraform state, but it does not remove state entries for resources that no longer exist. The team’s problem is stale state records for deleted resources, requiring `terraform refresh` (or `terraform apply -refresh-only`) to update the state against current cloud inventory. `terraform import` is tempting because it is the standard command for adding unmanaged resources into state, which would be correct if the team needed to adopt orphaned cloud objects rather than purge defunct ones.

terraform state rm

Why it fails: Remove removes resources from state but does not reconcile missing resources.

Disable TLS for internal VPC traffic

Why it fails: Disabling TLS removes transport encryption entirely, directly contradicting the in-transit requirement, and internal VPC traffic is not external communication anyway. TLS termination with strong cipher suites is what secures transit. Disabling it would only be contemplated for isolated, already-encrypted tunnels where overhead is deliberately traded away.

Enable AES-256 encryption at rest

Why it fails: AES-256 at rest protects stored data on disks and buckets, which is the wrong axis: the requirement is encryption in transit for external communications. At-rest encryption would be correct if the scenario asked about protecting data on persistent disks, Cloud Storage objects, or BigQuery datasets.

Azure Monitor with Log Analytics

Why it fails: Azure Monitor is Azure-specific, not suitable for AWS.

AWS CloudWatch with cross-account monitoring

Why it fails: CloudWatch is AWS-specific and cannot monitor Azure resources natively.

Custom scripts that log to a central syslog server

Why it fails: Custom scripts are error-prone and not a standard solution for multi-cloud monitoring.

Rate limiting

Why it fails: Rate limiting caps request frequency per client, so distributed traffic from many source addresses in those regions still passes. It is tempting because it mitigates volumetric abuse, but it is correct against floods or brute force, not for denying traffic based on geographic origin.

OWASP rule set

Why it fails: OWASP rules inspect request payloads for injection and similar application-layer attacks; they do not evaluate source geography. They are tempting because they form the WAF's core protection, but they would be correct against application exploits, whereas blocking regions requires geo-filtering by source IP.

IP reputation lists

Why it fails: IP reputation lists block addresses with known malicious history, not entire regions; the traffic here is legitimate but unwanted, so geolocation filtering is required. Reputation lists would be the right choice when blocking traffic from sources flagged for spam, malware or prior attacks.

Increase the size of the existing virtual machines (vertical scaling)

Why it fails: Vertical scaling does not enable horizontal scaling; it increases capacity of a single instance.

Use sticky sessions (session affinity) on the load balancer

Why it fails: Sticky sessions tie a user to a specific instance, making horizontal scaling less effective.

Disable scale-in for the first 10 minutes using a scheduled action

Why it fails: Not a native feature; lifecycle hooks are the correct approach.

Set the health check grace period to 600 seconds

Why it fails: Health check grace period delays health checks, but does not prevent scale-in termination.

Increase the cooldown period to 600 seconds

Why it fails: Cooldown prevents new scaling activities, but does not protect instances from being terminated during scale-in.

AWS App Runner

Why it fails: AWS App Runner is a fully managed service for containerized web applications, where AWS manages all underlying infrastructure. You have no access to the host OS or kernel, and the environment is shared. It does not provide the required isolation and management capabilities.

Amazon ECS with Fargate launch type

Why it fails: Fargate is a serverless compute engine for containers, where AWS manages the host infrastructure. You cannot access or manage the host OS or kernel, and the underlying host may be shared with other customers. This does not meet the isolation and management requirements.

Amazon EKS with managed node groups

Why it fails: Amazon EKS managed node groups use EC2 instances that are managed by AWS, but the nodes are not dedicated hosts by default. You can manage the node OS, but the underlying physical host may be shared. To get dedicated hosts, you need to configure self-managed nodes on Dedicated Hosts.

AWS CloudFormation and SSM

Why it fails: CloudFormation provisions infrastructure and SSM stores parameters or runs commands, but neither shifts live traffic weights between ECS task sets nor reacts to CloudWatch error-rate alarms within five minutes. CloudFormation suits declarative stack deployment, not runtime canary traffic control.

AWS Lambda and Step Functions

Why it fails: Lambda and Step Functions cannot intercept Application Load Balancer traffic destined for ECS tasks, so no 10% split or error-rate-triggered rollback is possible. Step Functions suits orchestrating serverless workflows, not managing ECS task-set traffic weights.

AWS Elastic Beanstalk and Route 53

Why it fails: Elastic Beanstalk orchestrates EC2/ECS deployments but cannot split traffic 10/90 between two ECS task sets; Route 53 weighted records shift at DNS level without CloudWatch alarm-driven rollback. It suits whole-environment blue/green releases, not per-request canary weighting on ECS.

Increase the VM's vCPU count to 8 to improve processing capacity.

Why it fails: Adding vCPUs addresses compute contention, but CPU utilisation stays below 50 percent during peaks, so processing capacity is not the bottleneck. Extra vCPUs would be correct when sustained CPU saturation, not network spikes, causes the latency.

Configure the firewall to allow all traffic to reduce processing overhead.

Why it fails: Allowing all traffic does not raise the 1 Gbps interface cap or address the 500 Mbps outbound spikes causing latency; firewall rule processing is not the bottleneck here. It is tempting because permissive rules genuinely reduce stateful inspection overhead in firewall-bound workloads, but the stem points to network throttling, not filtering.

Enable DDoS protection on the public IP to filter malicious traffic.

Why it fails: DDoS protection scrubs volumetric attack traffic, yet the stem shows legitimate outbound spikes to 500 Mbps against a 1 Gbps cap with no attack signature. It would be right when malicious floods saturate the public IP, not for this throughput pattern.

GCP Cloud Audit Logs

Why it fails: GCP Cloud Audit Logs record activity in Google Cloud projects, not Azure subscriptions. It is correct when auditing GCP resources. The option tempts because it is a native cloud audit service, yet it cannot collect Azure management operations; Azure Activity Log is the platform-specific source for those events.

AWS CloudTrail

Why it fails: AWS CloudTrail records API activity within AWS accounts, so it captures nothing from Azure subscriptions. It is the correct tool for auditing AWS management operations. The option tempts because both are cloud audit services, but the platform boundary means CloudTrail cannot see Azure control-plane events.

Azure Security Center

Why it fails: Azure Security Center (now Defender for Cloud) provides security posture and threat protection, not centralised collection of management-operation audit logs. Azure Activity Log holds subscription control-plane events. The option tempts because it is Azure-native and security-focused, but auditing management operations requires Activity Log exported to a Log Analytics workspace.

Increase the volume size to gain higher baseline IOPS.

Why it fails: Increasing size increases baseline IOPS but still uses burst credits which can deplete.

Move the logs to an object storage service.

Why it fails: Object storage is not block-level and may require application changes.

Enable write caching on the volume.

Why it fails: Write caching can cause data loss and is not recommended for data volumes.