KCNA study materials
KCNA study resources

KCNA: Cloud Native Architecture

KCNA · Work through your exam, one topic at a time.

All guide sections

Cloud Native Architecture

Architectural style

Cloud native architecture combines containers, microservices, declarative APIs, immutable infrastructure, and automated operations to build resilient, observable distributed systems. The CNCF landscape organizes projects across orchestration, networking, observability, security, and storage. Microservices favor loose coupling, independent deployment, and bounded contexts, but introduce network failure, latency, and operational complexity.

Resilience and observability

Design for failure: assume networks are unreliable, use timeouts, retries with backoff, circuit breakers, health checks, and graceful degradation. Stateless services scale horizontally; state is pushed to managed or persistent stores. Observability rests on metrics, logs, and traces, with alerting on symptoms rather than every cause. Service meshes add mTLS, traffic policy, and telemetry through sidecars or ambient dataplanes. Serverless abstracts servers but still runs code on infrastructure and imposes cold-start and execution-limit tradeoffs.

Traps

Microservices are not automatically better than a modular monolith; distributed systems add failure modes. A service mesh does not replace application-level resilience. Observability is broader than monitoring: it supports asking new questions from telemetry. Serverless means no server management, not no servers. Stateless does not mean no data; it means no per-instance session state.

Worked example

An API calling a flaky payment provider should use a timeout, bounded retries with exponential backoff, a circuit breaker, and idempotency keys. Instrument latency and error-rate metrics, trace the request path, and alert on user-visible error budget burn. Rule of thumb: every remote call can fail, be slow, or be duplicated-design for all three.