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.