Cloud Native Operations

English

한국어

English

한국어

Appearance

App Mesh vs VPC Lattice Architecture Quiz ​

This quiz tests your understanding of the structural differences between the sidecar and managed data plane models, resource mapping, and feature gaps.

Multiple Choice Questions ​

  1. How should migration feature gaps be assessed?
    • A) AWS simply has not implemented them yet and will add them soon
    • B) Compare the actual App Mesh and Lattice APIs; proxy placement alone does not prove feature impossibility
    • C) Those features do not work over HTTP/2
    • D) They are unnecessary because IAM policies can replace them
Show Answer

Answer: B) Compare the actual App Mesh and Lattice APIs; proxy placement alone does not prove feature impossibility

Explanation: Generic Envoy/Istio features are not automatically App Mesh features. Inventory the configured controls and choose application/proxy replacements for gaps in the current product API.

  1. Why is App Mesh's VirtualNode said not to map one-to-one onto a VPC Lattice Target Group?
    • A) You can create many VirtualNodes but only one Target Group
    • B) The identity, backend, connection pool, and outlier detection attributes VirtualNode carried either scatter to several places or disappear
    • C) Target Groups do not support Lambda
    • D) VirtualNode depends on Cloud Map, making conversion impossible
Show Answer

Answer: B) The identity, backend, connection pool, and outlier detection attributes VirtualNode carried either scatter to several places or disappear

Explanation: A VirtualNode packed "who this workload is (identity), where it goes (backends), and where it receives (listeners, health checks, connection pools, outlier detection)" into a single resource. In Lattice only the target set and health checks become a Target Group; "where it goes" becomes a matter of auth policies and IAM permissions; "who it is" becomes an IAM Role; and connection pools and outlier detection have no corresponding resource at all. The mapping table maps resource names, not capabilities.

  1. What is an appropriate observability migration task?
    • A) Circuit breaking — it is the hardest to implement
    • B) Preserve application tracing and replace the telemetry actually supplied by the old proxy
    • C) Traffic mirroring — there is no alternative at all
    • D) Fault injection — it is essential for production incident response
Show Answer

Answer: B) Preserve application tracing and replace the telemetry actually supplied by the old proxy

Explanation: Lattice has no native trace span, but application spans remain possible. Correlate them with Lattice request IDs, access-log timing and client/server observations.

  1. What happens if the AWS Gateway API Controller stops?
    • A) All traffic is blocked immediately
    • B) Traffic keeps flowing, but newly started Pods are not registered as Targets and dead Pods are not deregistered
    • C) Lattice Services are automatically deleted
    • D) IAM authentication is disabled
Show Answer

Answer: B) Traffic keeps flowing, but newly started Pods are not registered as Targets and dead Pods are not deregistered

Explanation: The controller's core job is keeping Kubernetes' declared state and Lattice's actual target list in sync — it watches endpoint changes on the Services referenced by backendRefs and registers/deregisters Targets. If it stops, Lattice keeps forwarding traffic using the last known target list, but that list goes stale. This is why the availability and IAM permissions of the controller Deployment are directly tied to data path reliability.

  1. In an environment that also runs ingress-nginx, which statement about the migration scope is correct?
    • A) ingress-nginx must also be replaced by Lattice
    • B) The AWS Gateway API Controller currently focuses only on East-West traffic through Lattice, so the North-South traffic ingress-nginx handles is out of scope and the two paths coexisting is the normal outcome
    • C) ingress-nginx and Lattice cannot be used at the same time
    • D) The Gateway API Controller handles North-South traffic too, so ingress-nginx should be removed immediately
Show Answer

Answer: B) The AWS Gateway API Controller currently focuses only on East-West traffic through Lattice, so the North-South traffic ingress-nginx handles is out of scope and the two paths coexisting is the normal outcome

Explanation: The Kubernetes Gateway API was designed to cover both North-South (Ingress) and East-West (Mesh) traffic, but the AWS Gateway API Controller currently focuses only on East-West. ALB/NLB-style North-South features belong to the AWS Load Balancer Controller. So the ingress path ingress-nginx serves is not in scope for this migration; only East-West traffic moves to Lattice, and a configuration where both paths coexist is the expected result.

  1. Why use a Pod readiness gate in a Lattice environment?
    • A) To cap a Pod's CPU usage
    • B) So a Pod is not marked Ready until its Lattice Target Group health is Healthy, preventing a rolling update from terminating old Pods before new ones are healthy
    • C) To block traffic until IAM credentials are ready
    • D) To wait for Envoy sidecar injection
Show Answer

Answer: B) So a Pod is not marked Ready until its Lattice Target Group health is Healthy, preventing a rolling update from terminating old Pods before new ones are healthy

Explanation: Kubernetes may consider a Pod Ready while the Lattice Target Group does not yet see it as Healthy. If a rolling update terminates old Pods in that state, there is a window with no healthy Target. A Pod readiness gate ties Lattice's view of health to the Pod's Ready condition, preventing this — an important mechanism for zero-downtime during migration.