Learning path
Cloud Native Patterns learning path: everything to study, topic by topic
Cloud-native application design assessment covering the principles of cloud-native, the 12-factor app, externalized state and configuration, request/response and event-driven interaction, application-level resilience, the application platform, and operability — based on Cornelia Davis's Cloud Native Patterns and CNCF principles. App design focus, not infrastructure operations.
Short answer
To learn Cloud Native Patterns, work through 6 modules and 24 topics in the order they build on each other. It starts with Cloud Native Foundations, then moves on to State & Configuration and Interaction Patterns. Use the map as a checklist, or measure your level and study only what is missing.
What you will study
Topics are grouped by module. Open one to see its objectives and key concepts.
1 · Cloud Native Foundations4 topics
What Cloud Native Means
Understanding cloud native as software designed for a highly dynamic, redundant, and constantly changing environment where failure is normal — and why apps must adapt rather than depend on stable infrastructure
Objectives
- Explain why cloud-native apps assume a changing, failure-prone environment
- Distinguish cloud-native design from traditional lift-and-shift
Key concepts
- highly dynamic environment
- redundancy
- failure is normal
- elasticity
- self-healing
The 12-Factor App
The twelve factors for building portable, scalable, cloud-native applications: codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes
Objectives
- List and explain the twelve factors of a cloud-native app
- Identify which factor a given anti-pattern violates
Key concepts
- 12-factor
- config in environment
- backing services
- stateless processes
- dev/prod parity
Disposability
Designing processes that start fast and shut down gracefully so instances can be created or destroyed at any moment — a precondition for elasticity, fast deploys, and resilience
Objectives
- Explain why disposable processes enable elasticity
- Design an app that tolerates being killed at any moment
Key concepts
- fast startup
- graceful shutdown
- ephemeral instances
- crash-only design
- cattle not pets
Containerization Patterns
Packaging an application and its dependencies into an immutable container image: single-process containers, minimal base images, build vs runtime separation, and image layering for cloud-native deployment
Objectives
- Package an application into a lean, immutable container image
- Explain why one process per container aids cloud-native design
Key concepts
- container image
- immutable artifact
- single process
- minimal base image
- build vs runtime
2 · State & Configuration4 topics
Statelessness
Building stateless application processes so any instance can serve any request, enabling horizontal scaling, rolling deploys, and instance replacement without sticky sessions or in-memory state
Objectives
- Refactor a stateful handler into a stateless design
- Explain how statelessness enables instance replacement
Key concepts
- stateless processes
- share-nothing
- horizontal scaling
- no sticky sessions
- request affinity
Externalized State
Pushing all durable state out of the application process into backing services — databases, caches, object stores, and message brokers — treated as attached resources bound at runtime
Objectives
- Externalize session and durable state to backing services
- Treat a database as a swappable attached resource
Key concepts
- backing services
- attached resources
- externalized session
- stateful backing store
- bound at runtime
Configuration in the Environment
Separating config from code: injecting environment-specific configuration via environment variables and config maps so the same immutable artifact runs unchanged across environments
Objectives
- Externalize configuration so one artifact runs in all environments
- Distinguish config from code per the 12-factor model
Key concepts
- config in environment
- environment variables
- config maps
- code/config separation
- build once
Secrets Handling
Managing sensitive configuration — credentials, tokens, keys — separately from regular config: injection at runtime, never baking secrets into images, rotation, and least-privilege access
Objectives
- Inject secrets safely at runtime without baking them into images
- Design a rotation-friendly secrets strategy
Key concepts
- secret injection
- never in image
- rotation
- least privilege
- secret store
3 · Interaction Patterns5 topics
Request/Response Interaction
Synchronous request/response communication between cloud-native services: blocking dependencies, latency coupling, timeouts, and when synchronous calls are appropriate versus harmful
Objectives
- Identify the coupling risks of synchronous request/response chains
- Choose appropriate timeouts for downstream calls
Key concepts
- synchronous calls
- latency coupling
- timeouts
- blocking dependency
- request chains
Event-Driven Design
Decoupling services through asynchronous events and messaging: publish/subscribe, event notification versus event-carried state transfer, and how events reduce temporal coupling in cloud-native apps
Objectives
- Decouple two services using asynchronous events
- Choose between event notification and event-carried state transfer
Key concepts
- asynchronous events
- publish/subscribe
- temporal decoupling
- event notification
- message broker
Eventual Consistency in Apps
Designing applications that embrace eventual consistency: accepting temporary divergence, reconciling state asynchronously, and shaping UX and APIs around non-immediate consistency
Objectives
- Design an app feature that tolerates eventual consistency
- Communicate non-immediate consistency to clients gracefully
Key concepts
- eventual consistency
- state reconciliation
- compensating actions
- read-your-writes
- convergence
Service Discovery
Locating service instances dynamically in an environment where instances come and go: service registries, DNS-based discovery, and why hardcoded endpoints break in cloud-native systems
Objectives
- Locate service instances dynamically via discovery
- Explain why static endpoints fail under instance churn
Key concepts
- service registry
- dynamic endpoints
- DNS discovery
- instance churn
- no hardcoded hosts
Client-Side Load Balancing
Distributing requests across discovered instances from the client side: load-balancing strategies, health-aware instance selection, and the trade-offs versus server-side/proxy load balancing
Objectives
- Distribute requests across instances from the client
- Compare client-side and server-side load balancing trade-offs
Key concepts
- client-side load balancing
- instance selection
- round-robin
- health-aware routing
- proxy trade-offs
4 · Application Resilience3 topics
Retries & Idempotency
Recovering from transient failures safely: retry with backoff and jitter, idempotency keys, and ensuring retried operations do not produce duplicate side effects
Objectives
- Design a safe retry policy with backoff and jitter
- Make a write operation idempotent under retries
Key concepts
- retry with backoff
- jitter
- idempotency key
- transient failure
- exactly-once effect
Application Circuit Breaker
Preventing cascading failure at the application level: tripping a circuit when a dependency fails repeatedly, fast-failing during the open state, and recovering through a half-open probe
Objectives
- Apply a circuit breaker to protect against a failing dependency
- Explain the open/half-open/closed state transitions
Key concepts
- circuit breaker
- open/half-open/closed
- fast fail
- cascade prevention
- fallback
Application-Level Resilience
Combining resilience patterns — timeouts, bulkheads, fallbacks, rate limiting, and graceful degradation — so the application stays responsive when dependencies are slow or down
Objectives
- Compose multiple resilience patterns into a robust service
- Degrade gracefully when a non-critical dependency fails
Key concepts
- bulkhead
- timeout
- graceful degradation
- fallback
- rate limiting
5 · The Application Platform4 topics
The Application Platform
How a cloud-native platform provides the runtime contract — scheduling, restarts, scaling, service discovery, and config injection — and how applications should cooperate with platform-provided capabilities
Objectives
- Describe the runtime contract between app and platform
- Delegate cross-cutting concerns to the platform appropriately
Key concepts
- platform contract
- scheduler
- self-healing
- platform-provided services
- separation of concerns
Routing & Release Strategies
Shipping changes safely through traffic shaping at the application/platform layer: blue-green deployment, canary releases, and progressive rollout with rollback
Objectives
- Design a canary release with automated rollback
- Compare blue-green and canary deployment trade-offs
Key concepts
- blue-green
- canary release
- traffic shaping
- progressive rollout
- rollback
Autoscaling-Friendly Design
Designing applications so the platform can scale them horizontally on demand: fast startup, stateless instances, meaningful scaling signals, and avoiding startup/teardown side effects that block scaling
Objectives
- Design an app that scales horizontally without manual intervention
- Pick scaling signals that reflect real load
Key concepts
- horizontal autoscaling
- scaling signals
- fast warm-up
- no startup side effects
- scale to zero
Sidecar, Ambassador & Adapter
Composing functionality alongside the application via co-located helper containers: the sidecar pattern, the ambassador proxy for outbound connectivity, and the adapter for normalizing interfaces
Objectives
- Apply the sidecar pattern to offload a cross-cutting concern
- Distinguish ambassador and adapter use cases
Key concepts
- sidecar
- ambassador
- adapter
- co-located helper
- cross-cutting concern offload
6 · Operability & Lifecycle4 topics
Health & Readiness Probes
Exposing the application's own view of its health: liveness versus readiness, what each probe should check, and how probes drive restarts and traffic routing in the platform
Objectives
- Differentiate liveness and readiness checks for an app
- Decide what a readiness probe should and should not verify
Key concepts
- liveness probe
- readiness probe
- health endpoint
- startup probe
- self-reported health
Observability
Making a cloud-native app debuggable in production through the three pillars — structured logs to stdout, metrics, and distributed traces with correlation/context propagation
Objectives
- Instrument an app with logs, metrics, and traces
- Propagate trace context across service boundaries
Key concepts
- structured logging
- metrics
- distributed tracing
- context propagation
- correlation id
Graceful Startup & Shutdown
Handling the application lifecycle cleanly: draining in-flight work on SIGTERM, deregistering from discovery, honoring termination grace periods, and signaling readiness only when truly ready
Objectives
- Implement graceful shutdown that drains in-flight requests
- Coordinate readiness signaling with startup work
Key concepts
- SIGTERM handling
- connection draining
- grace period
- deregistration
- readiness gating
Immutable Infrastructure
Treating deployed artifacts as immutable and replaceable: no in-place mutation, rebuild-and-redeploy over patching, and how immutability underpins reproducibility and reliable rollback
Objectives
- Apply immutable infrastructure to a deployment pipeline
- Explain how immutability enables reliable rollback
Key concepts
- immutable artifact
- no in-place mutation
- rebuild over patch
- reproducibility
- reliable rollback
Levels: Junior, Mid, Senior, and Expert
Explain it in your own words
Graded by AI · no account · 1 questionNo options to guess from: you write, the AI grades against the topic's rubric and tells you what level your answer reads at.
Already studying Cloud Native Patterns?
The assessment measures topic by topic, and your plan skips what you already know.
Open to read. An account is only needed to be measured.
Frequently asked questions
Where should I start studying Cloud Native Patterns?
Start with Cloud Native Foundations: What Cloud Native Means, The 12-Factor App, and Disposability. The map orders topics by what they depend on, so each one prepares the next.
How long does a full Cloud Native Patterns assessment take?
A full assessment of this path takes about 50 minutes. Study time depends on where you start; a diagnostic shows which topics you can skip.
Do I need an account to use this page?
No. The map, objectives and key concepts are open. You only need an account to be measured, get your gap by topic and receive a plan.