Cloud Native Patterns Flashcards
7 cards from real KCNA practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.
Read the first 7 Cloud Native Patterns flashcards as text
What is the Ambassador pattern in cloud native architectures?
Answer: A sidecar that proxies network traffic on behalf of the main container
The Ambassador pattern uses a sidecar proxy to handle outbound network concerns like retries, TLS, and service discovery on behalf of the main container.
Which pattern involves running a container that completes setup tasks before the main application container starts?
Answer: Init Container
Init Containers run to completion before the main containers start, making them ideal for setup tasks like schema migrations or config fetching.
In a service mesh, what component typically handles communication between services at the data plane level?
Answer: Sidecar proxy (e.g., Envoy)
Service meshes use sidecar proxies like Envoy injected alongside each service to intercept and manage all inter-service communication.
What is eventual consistency in the context of distributed cloud native systems?
Answer: Data will become consistent across nodes given enough time without new updates
Eventual consistency guarantees that, if no new updates occur, all replicas will converge to the same value over time.
Which cloud native pattern helps external clients communicate with services that use incompatible internal protocols?
Answer: Adapter
The Adapter pattern wraps a service to translate its interface so external clients can communicate with it using a compatible protocol.
What is the purpose of a health endpoint in cloud native applications?
Answer: Allows orchestrators to check if the application is ready or alive
Health endpoints (liveness and readiness probes) let orchestrators like Kubernetes determine whether a container should receive traffic or be restarted.
In cloud native design, what does 'design for failure' mean?
Answer: Assume components will fail and build systems that handle failure gracefully
Designing for failure means building systems that expect and tolerate component failures through patterns like retries, circuit breakers, and graceful degradation.