Cloud-Native Fundamentals
Fast recall
Quick revision
Core answer
Whether you understand cloud-native as a set of design principles (12-Factor, stateless, disposable, observable) not just 'runs on a cloud', and can name what each principle buys you.
Equating cloud-native with 'uses Kubernetes' — the platform is a means; the principles (statelessness, disposability, externalized config) are what actually make an app cloud-native.
Name the 12-Factor principles and what each buys — config externalized so the same build runs anywhere, disposability so instances can be killed and replaced, logs as streams so the platform owns aggregation — and note that cloud-native is design, Kubernetes is one runtime for it.
Interview-ready guide
Interview answer
Cloud-native is a way of building apps that actually exploits what the cloud offers — elasticity, resilience, managed services — instead of just running an old server app on a VM.
It exists because apps designed for one long-lived server can't scale per component or survive instance loss, which wastes the cloud entirely.
The checklist I anchor on is 12-Factor: config lives in the environment, not the jar; backing services are attached by URL; processes are stateless and disposable so the platform can kill or scale any instance anytime; logs go out as streams that the platform aggregates, never to local files.
The part people miss is that cloud-native is design — statelessness, disposability, externalized config — and Kubernetes is just one runtime that runs that design. The state doesn't disappear either; if your problem is stateful, you move it to a backing service like Redis or Kafka.
Cloud-Native Fundamentals
Direct Answer
Cloud-native is an approach to building and running applications that exploits the cloud's elasticity, distributed nature, and managed services — containers, microservices, declarative config, and observability — rather than lifting a fixed-size server app onto a VM. It exists because apps designed for a single long-lived server fail in the cloud: they can't scale per component, can't heal on failure, and can't deploy without downtime, while cloud-native apps scale horizontally, self-heal, and ship continuously.
Common Mistakes & Pitfalls
Equating cloud-native with 'uses Kubernetes' — the platform is a means; the principles (statelessness, disposability, externalized config) are what actually make an app cloud-native.
Check your understanding
Answer these without looking back at the article.
- Why must a cloud-native process be stateless, and where does its state go instead?
- How does Factor III (config in the environment) let the same jar run in dev, staging, and prod?
- What does 'disposability' require of a Spring Boot service on SIGTERM, and what breaks if you ignore it?
- Why are logs emitted as streams rather than written to local files in a cloud-native app?
- How does moving to containers change the blast radius of an instance failure compared to a monolith on a VM?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.