Two engineers run `terraform apply` against the same S3-backed state at nearly the same time, but the team disabled DynamoDB state locking to 'speed things up.' Engineer A's apply reads the state, then Engineer B's apply reads the same state, both plan against it, and both write. What is the most likely concrete failure?
- A. Terraform automatically serializes the two applies because S3 is strongly consistent, so no corruption occurs
- B. The second apply to finish overwrites the state file with a version that omits resources the first apply created, so those resources become orphaned/untracked ✓
- C. Both applies fail immediately with a 409 Conflict from S3 before any resources change
- D. The state file is fine, but the AWS provider rate-limits and one apply retries transparently
Correct answer: B. Without a lock, the last writer wins and clobbers the other's state, leaving real resources that Terraform no longer tracks (drift/orphans).
A pod is stuck in `CrashLoopBackOff`. `kubectl describe pod` shows `Last State: Terminated, Reason: OOMKilled, Exit Code: 137`, and the container has `resources.limits.memory: 256Mi` with no `requests` set. Which action most directly addresses the root cause?
- A. Add a liveness probe with a longer `initialDelaySeconds` so the kubelet stops restarting it
- B. Raise the memory limit (and set a matching request) to fit the app's real working set, or fix the leak causing it to exceed 256Mi ✓
- C. Set `restartPolicy: Never` so the pod stops crash-looping
- D. Increase the node's `--max-pods` so the scheduler places it on a larger node
Correct answer: B. Exit code 137 with OOMKilled means the cgroup memory limit was hit; the fix is sizing the limit to the real footprint or fixing excessive memory use, not probe or restart tweaks.
You have VPC-A peered to VPC-B, and VPC-B peered to VPC-C. An instance in VPC-A cannot reach an instance in VPC-C, even though routes and security groups look correct for each individual peering. Why?
- A. VPC peering requires overlapping CIDR blocks to route transitively, which A and C lack
- B. VPC peering is non-transitive; traffic cannot hop A→B→C through B, so you need a direct A↔C peering or a Transit Gateway hub ✓
- C. Security groups cannot reference peer VPCs, so the packets are dropped at B
- D. Peering only supports IPv6 transit, so the IPv4 path through B is blocked
Correct answer: B. VPC peering is non-transitive by design; the hub VPC won't forward between two peers, so you need a direct peering or a Transit Gateway.
In AWS, an IAM role has an identity policy granting `s3:*` on all buckets, but a permissions boundary attached to the role only allows `s3:GetObject` and `s3:ListBucket`. A user assumes the role and calls `s3:PutObject`. What happens, and why?
- A. Allowed, because identity policies override permissions boundaries
- B. Denied, because the effective permissions are the intersection of the identity policy and the boundary, and PutObject isn't in the boundary ✓
- C. Allowed, because permissions boundaries only apply to the entity that created the role
- D. Denied, but only if an SCP also denies PutObject; otherwise allowed
Correct answer: B. A permissions boundary caps maximum permissions; the effective set is the intersection with the identity policy, so an action absent from the boundary is denied even if the identity policy allows it.
A Lambda function behind API Gateway starts returning 429s under a traffic spike, and CloudWatch shows `Throttles` climbing while `ConcurrentExecutions` sits flat at 100. Reserved concurrency for the function is set to 100. What is happening?
- A. The function hit its reserved-concurrency ceiling of 100, so additional simultaneous invocations are throttled ✓
- B. Cold starts are exceeding the 15-minute timeout, causing 429 responses
- C. The account ran out of ephemeral /tmp storage, which surfaces as throttling
- D. API Gateway's default 10,000 RPS burst was exceeded, unrelated to Lambda concurrency
Correct answer: A. Reserved concurrency of 100 caps the function at 100 simultaneous executions; beyond that, Lambda throttles, which is exactly the flat-at-100 concurrency with rising throttles.
You want engineers in Account A to access an S3 bucket in Account B using short-lived credentials, with no long-lived keys stored anywhere. Which mechanism is correct?
- A. Create an IAM user in Account B, generate access keys, and share them with Account A engineers
- B. Create a role in Account B whose trust policy allows Account A's principals to `sts:AssumeRole`, and attach the S3 permissions to that role ✓
- C. Add Account A's account ID to the bucket ACL and rely on ACL-based cross-account access
- D. Enable S3 public access and restrict by referer header from Account A
Correct answer: B. Cross-account access with temporary credentials is done via a role in the target account with a trust policy permitting the source account to AssumeRole, yielding short-lived STS credentials.
A Terraform module `network` is referenced as `source = "...//modules/network"` with `version = "~> 2.0"`. Someone tags a new `2.4.0` that renamed an output and changed a subnet's `map_public_ip_on_launch` default. On the next `apply` in prod, what's the realistic risk?
- A. Nothing changes, because `~> 2.0` pins to exactly 2.0.0 and ignores 2.4.0
- B. The version constraint silently pulls 2.4.0, and the changed default plus renamed output can force subnet replacement / break downstream references ✓
- C. Terraform refuses to run because minor upgrades always require `-upgrade` and manual approval per resource
- D. The state lock prevents the module upgrade from taking effect until unlocked
Correct answer: B. `~> 2.0` allows any 2.x, so `terraform init -upgrade` (or a fresh init) can resolve 2.4.0, whose changed defaults/renamed outputs can trigger destructive plans in prod.
A service mesh is configured for strict mTLS between services, but one legacy pod without a sidecar suddenly can't reach a meshed service that it previously could. Which explanation is most consistent?
- A. The mesh's strict mTLS mode now requires a client certificate the sidecar-less pod can't present, so its plaintext connections are rejected ✓
- B. mTLS only affects egress, so ingress to the meshed service is unaffected and the problem must be DNS
- C. Strict mTLS disables all NetworkPolicies, so the traffic is dropped at the CNI layer
- D. mTLS encrypts payloads but never rejects connections, so the failure must be a resource limit
Correct answer: A. STRICT mTLS makes the server reject plaintext; a pod with no sidecar can't complete the mutual-TLS handshake, so its connections are refused (PERMISSIVE mode would have allowed them).
A client retries a non-idempotent 'create payment' POST after a network timeout, and the server had actually processed the first request. To prevent a duplicate charge while still allowing safe retries, the most robust design is:
- A. Switch the endpoint to HTTP PUT, since PUT is always idempotent regardless of body
- B. Have the client send a unique idempotency key; the server records it and returns the original result on any retry with the same key ✓
- C. Add exponential backoff with jitter, which by itself guarantees no duplicate processing
- D. Wrap the handler in a database transaction, which makes any repeated request a no-op automatically
Correct answer: B. A client-supplied idempotency key lets the server deduplicate retries at the application layer; backoff, PUT semantics, or a plain transaction alone don't stop a second distinct request from creating a second charge.
You run a stateless web tier behind an L7 load balancer with autoscaling. During scale-in, users report dropped in-flight requests and truncated downloads. Which fix targets the cause?
- A. Switch from L7 to L4 load balancing so connections are faster to close
- B. Enable connection draining / deregistration delay so terminating instances finish in-flight requests before removal ✓
- C. Increase the health-check interval so instances are marked healthy longer
- D. Set the autoscaling cooldown to zero so scale-in happens instantly
Correct answer: B. Connection draining (deregistration delay) lets a terminating target complete in-flight requests before the LB stops routing to it, preventing mid-request cutoffs.
Two teams manage the same Terraform state file and occasionally overwrite each other's changes. What mechanism prevents this?
- A. Enabling verbose logging
- B. Using a remote backend with state locking ✓
- C. Increasing the parallelism flag
- D. Running terraform refresh more often
Correct answer: B. A remote backend (e.g., S3 with DynamoDB or Terraform Cloud) provides state locking so concurrent applies cannot corrupt shared state.
A latency-sensitive service uses spot instances for cost savings but suffers occasional interruptions. What is the best resilience pattern?
- A. Run 100% on spot with no fallback
- B. Mix spot with on-demand baseline capacity and handle interruption notices gracefully ✓
- C. Increase instance size to avoid interruptions
- D. Disable auto scaling entirely
Correct answer: B. Blending an on-demand baseline with spot capacity and draining workloads on the interruption warning balances cost savings with reliability.
In Kubernetes, a pod stays in 'Pending' state indefinitely with no events about image pulls. What is the most likely root cause?
- A. The container command exited with code 0
- B. No node has sufficient resources or matching scheduling constraints ✓
- C. The liveness probe is failing
- D. The service has no endpoints
Correct answer: B. A persistently Pending pod usually means the scheduler cannot place it because no node satisfies its resource requests, taints/tolerations, or affinity rules.
You must guarantee that objects written to object storage are never deleted or altered for a compliance retention period, even by admins. What feature achieves this?
- A. Server-side encryption
- B. Versioning alone
- C. Object Lock in compliance/WORM mode ✓
- D. Lifecycle transition to cold storage
Correct answer: C. Object Lock in compliance (WORM) mode enforces immutability for a retention period that not even the root account can override.
A multi-region active-active application needs a globally consistent view of a small critical counter. What is the fundamental trade-off you face?
- A. Storage cost versus compute cost
- B. The CAP theorem: strong consistency across regions sacrifices availability during partitions ✓
- C. IAM complexity versus tagging
- D. Encryption at rest versus in transit
Correct answer: B. Per the CAP theorem, a partition between regions forces a choice between consistency and availability, so global strong consistency reduces availability.
A VPC peering connection is established between VPC-A (10.0.0.0/16) and VPC-B (10.0.0.0/16) but traffic fails. What is the cause?
- A. Peering requires a NAT gateway
- B. Overlapping CIDR ranges are not routable across a peering connection ✓
- C. Peering only works within one AZ
- D. Security groups cannot reference peered VPCs
Correct answer: B. VPC peering does not support overlapping CIDR blocks because routing tables cannot unambiguously direct traffic between identical ranges.
Your CI/CD pipeline uses long-lived cloud access keys stored as secrets. What is the more secure modern alternative for GitHub Actions?
- A. Rotate the keys weekly by hand
- B. Use OIDC federation to assume a role with short-lived tokens ✓
- C. Store keys base64-encoded in the repo
- D. Grant the keys full administrator access
Correct answer: B. OIDC federation lets the pipeline exchange a signed identity token for short-lived cloud credentials, eliminating long-lived static keys.
An application behind an L7 load balancer intermittently returns 502 errors under load while backends appear healthy. What is a common root cause?
- A. The load balancer keep-alive/idle timeout is shorter than the backend's, closing connections mid-response ✓
- B. The DNS TTL is too high
- C. The subnet ran out of IP addresses
- D. The instances lack public IPs
Correct answer: A. A mismatch where the backend closes idle keep-alive connections before the load balancer expects can cause the LB to return 502 on reused connections.
You need blue-green deployment with instant rollback for a database-backed service where schema changes are involved. What is the key constraint to manage?
- A. Each color needs its own separate copy of the database to stay isolated
- B. Backward-compatible schema changes so both versions can run against the same database ✓
- C. You must delete the blue environment before green starts
- D. A shared database makes instant rollback impossible, so blue-green can't be used
Correct answer: B. For safe blue-green with a shared database, schema changes must be backward and forward compatible so both versions operate correctly during the switch.
A serverless function experiences high p99 latency due to cold starts under spiky traffic. Which mitigation directly addresses cold starts?
- A. Increasing the function timeout
- B. Configuring provisioned/pre-warmed concurrency ✓
- C. Increasing the function's ephemeral /tmp storage
- D. Reducing the memory allocation
Correct answer: B. Provisioned (pre-warmed) concurrency keeps a pool of initialized execution environments ready, eliminating cold-start latency for that capacity.
For a multi-region active-active design on AWS, which option natively supports multi-region, multi-master writes?
- A. RDS Multi-AZ
- B. DynamoDB Global Tables ✓
- C. A single Aurora instance
- D. ElastiCache Redis
Correct answer: B. DynamoDB Global Tables provide fully managed multi-region, multi-active replication with writes in every region.
What problem does Terraform remote state locking (e.g., S3 + DynamoDB) solve?
- A. Prevents concurrent applies from corrupting the state file ✓
- B. Encrypts secrets stored in variables
- C. Speeds up the plan phase
- D. Versions Terraform modules
Correct answer: A. State locking serializes concurrent operations so two applies cannot corrupt the shared state.
A Lambda function's cold starts are hurting p99 latency. Which is the most effective mitigation?
- A. Increasing the function timeout
- B. Provisioned concurrency ✓
- C. Reducing reserved concurrency
- D. Disabling logging
Correct answer: B. Provisioned concurrency keeps execution environments pre-initialized, eliminating cold-start latency.
In Kubernetes, if a pod's CPU usage exceeds its CPU limit, what happens?
- A. The pod is OOMKilled
- B. CPU is throttled above the limit while scheduling uses the request value ✓
- C. The pod fails to schedule entirely
- D. The CPU limit is silently ignored
Correct answer: B. Exceeding a CPU limit causes throttling (not termination); scheduling is based on the request, not the limit.
What is the key advantage of a blue-green deployment over a rolling deployment?
- A. Instant rollback by switching traffic back to the old environment ✓
- B. It requires no additional infrastructure
- C. It updates pods one at a time gradually
- D. It eliminates all deployment cost
Correct answer: A. Blue-green keeps the old environment intact, enabling near-instant rollback by redirecting traffic.
Which construct gives an EC2 instance private connectivity to S3 without traversing the public internet?
- A. A NAT gateway
- B. An internet gateway
- C. A VPC endpoint ✓
- D. An Elastic IP
Correct answer: C. A VPC endpoint enables private access to AWS services over the AWS network, bypassing the public internet.
When is eventual consistency preferable to strong consistency in a distributed system?
- A. When availability and partition tolerance are prioritized over immediate consistency ✓
- B. When every read must return the most recent write
- C. For financial ledgers needing strict atomicity
- D. When network latency is irrelevant
Correct answer: A. Under CAP trade-offs, eventual consistency favors availability and partition tolerance over immediate consistency.
A pod is stuck in Pending with the event 'Insufficient cpu'. What is the root cause?
- A. The container image failed to pull
- B. No node has enough allocatable CPU to meet the pod's requests ✓
- C. The liveness probe is failing
- D. The container keeps crashing (CrashLoopBackOff)
Correct answer: B. 'Insufficient cpu' means the scheduler cannot find a node whose free CPU satisfies the pod's requests.
What does the 'noisy neighbor' problem refer to in multi-tenant cloud environments?
- A. One tenant's resource usage degrading performance for others on shared hardware ✓
- B. A misconfigured DNS resolver
- C. Cross-region replication latency
- D. An IAM privilege-escalation attack
Correct answer: A. A noisy neighbor consumes disproportionate shared resources, degrading performance for co-located tenants.
For a steady-state, predictable workload with a long-term commitment, which purchasing option gives the deepest discount?
- A. On-Demand Instances
- B. Spot Instances
- C. Standard Reserved Instances (3-year commitment) ✓
- D. Dedicated Hosts billed hourly
Correct answer: C. For predictable workloads, a 3-year Standard Reserved Instance offers the deepest committed discount; Spot is cheaper but can be interrupted.