Skip to main content

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.

6
modules
24
topics
50
min to assess

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 question

No options to guess from: you write, the AI grades against the topic's rubric and tells you what level your answer reads at.

0 / 600

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.