1. Cloud Native — CNCF Definition
According to the CNCF (Cloud Native Computing Foundation), cloud native is an approach to building and running scalable applications in dynamic environments such as public, private, and hybrid clouds, using: containers, microservices, declarative APIs, and immutable infrastructure.
| Principle | Meaning | Example |
|---|---|---|
| Containerized | Package app + dependencies together | Docker image |
| Dynamically orchestrated | Automated scheduling, scaling, healing | Kubernetes |
| Microservices | Loose coupling, single responsibility | Auth service, Payment service |
| Declarative APIs | Describe desired state, not steps | kubectl apply -f deployment.yaml |
| Immutable infrastructure | Never modify running; replace instead | New image version → rolling update |
2. Microservices vs Monolith
MONOLITH MICROSERVICES
───────────────────── ──────────────────────────────
┌──────────────────┐ ┌────────┐ ┌────────┐ ┌─────┐
│ Auth │ UI │ │ Auth │ │ Cart │ │ UI │
│ Cart │ API │ │Service │ │Service │ │Svc │
│ Payment │ DB │ └────────┘ └────────┘ └─────┘
└──────────────────┘ │ │ │
Deploy as 1 unit └─── API Gateway ───┘
│
Client/Browser| Aspect | Monolith | Microservices |
|---|---|---|
| Deployment | All-or-nothing | Independent per service |
| Scaling | Scale entire app | Scale only bottleneck service |
| Complexity | Low (single codebase) | High (distributed) |
| Fault isolation | One bug crashes all | Failure contained in service |
| Technology | Single stack | Polyglot (best tool per service) |
3. 12-Factor App
The 12-factor app methodology defines best practices for cloud native applications:
| # | Factor | Cloud Native Practice |
|---|---|---|
| 1 | Codebase | 1 repo per app, many deploys |
| 2 | Dependencies | Declare explicitly (package.json, go.mod) |
| 3 | Config | Store in environment (ConfigMap, Secrets) |
| 4 | Backing services | DB, cache = attached resources via URL |
| 5 | Build/Release/Run | Strict separation (CI builds, CD deploys) |
| 6 | Processes | Stateless processes, store state externally |
| 7 | Port binding | Export service via port (no web server layer) |
| 8 | Concurrency | Scale via process model (HPA) |
| 9 | Disposability | Fast startup, graceful shutdown |
| 10 | Dev/Prod parity | Same tools/services across environments |
| 11 | Logs | Treat as event streams (stdout, not files) |
| 12 | Admin processes | Run one-off admin tasks as Jobs |
Exam tip: Factors 3, 6, 9, and 11 frequently appear in KCNA questions. Factor 3 (config in env) → ConfigMap/Secret. Factor 6 (stateless) → the reason for using external storage. Factor 11 (logs as streams) → stdout → log aggregator.
4. Service Mesh
As microservices grow, you need to manage: mTLS, retry, circuit breaker, and observability. A Service Mesh solves this by injecting a sidecar proxy into each Pod.
Without Service Mesh: With Service Mesh (Istio):
App A ──────────────► App B App A ──► [Envoy] ──► [Envoy] ──► App B
(manual TLS, retry code) sidecar sidecar
(auto mTLS, metrics, retry, tracing)| Feature | Provided by Service Mesh |
|---|---|
| mTLS mutual authentication | Automatically encrypts traffic between services |
| Traffic management | Canary, A/B, weighted routing |
| Observability | Auto metrics, tracing, access logs |
| Resilience | Retry, timeout, circuit breaker |
5. Cheat Sheet
| Exam question | Answer |
|---|---|
| What does the CNCF definition of cloud native include? | Containers, microservices, declarative APIs, immutable infra |
| Where should config be stored according to 12-factor? | Environment variables (not hardcoded) |
| Logs according to 12-factor? | Treat as streams (stdout/stderr) |
| What does a service mesh inject into Pods? | Sidecar proxy (Envoy) |
| What part of microservices is scaled? | Only the service with the bottleneck |
6. Practice Questions
Q1: According to the 12-factor app methodology, how should an application store its database connection string?
- A) Hardcoded in the source code
- B) In a configuration file committed to the repository
- C) As an environment variable (Kubernetes ConfigMap or Secret) ✓
- D) In the container image as a build argument
Explanation: Factor 3 (Config) states: "Store config in the environment." In Kubernetes, this means using ConfigMaps for non-sensitive config and Secrets for sensitive values, injected as environment variables.
Q2: What is the primary benefit of using a Service Mesh in a microservices architecture?
- A) Replace Kubernetes for container orchestration
- B) Provide infrastructure-level networking features (mTLS, retry, observability) without changing application code ✓
- C) Store application configuration
- D) Persist application state across container restarts
Explanation: Service mesh moves cross-cutting concerns (security, observability, resilience) to the infrastructure layer via sidecar proxies. Developers don't need to implement retry logic or mTLS in each service.
Q3: Which characteristic distinguishes "immutable infrastructure" from traditional infrastructure?
- A) Servers are never rebooted
- B) Running systems are replaced rather than modified in-place ✓
- C) Configuration changes require manual approval
- D) Infrastructure is defined using only YAML files
Explanation: Immutable infrastructure means you never update/patch a running container — you build a new image, deploy it, replace old containers. This eliminates configuration drift and improves repeatability.