Exam Domain
A major subject area covered by the certification exam.
Getting Started with KCNA
Free knowledge base
Kubernetes and Cloud Native Associate (KCNA) — key terms, tricks & tips
Everything from the course in one searchable place: 256 entries. Use it to review before a practice test or look up a word you forgot.
256 results
Weighting
The percentage of exam questions dedicated to a specific domain.
Getting Started with KCNA
Proctored Exam
An exam monitored by a supervisor to ensure fairness and integrity.
Getting Started with KCNA
Multiple-Choice Question
A question format where you select one best answer from several options.
Getting Started with KCNA
Passing Score
The minimum score required to successfully pass the certification exam.
Getting Started with KCNA
Retake Policy
Rules governing how and when an exam can be re-attempted after a failure.
Getting Started with KCNA
Certification Validity
The period for which a certification remains active and recognized.
Getting Started with KCNA
Understanding the KCNA Exam Structure
To remember the domain weightings, think 'Kube Arch Obs App Sec' (Kubernetes, Architecture, Observability, Application, Security) and then the numbers '40, 20, 16, 16, 8'.
Getting Started with KCNA
Understanding the KCNA Exam Structure
The KCNA exam is a multiple-choice, online proctored exam with 60 questions and a 90-minute time limit. The passing score is 75%. Memorize the five domains and their approximate weightings.
Getting Started with KCNA
Understanding the KCNA Exam Structure
Underestimating the importance of lower-weighted domains; even 8% can be the difference between passing and failing.
Getting Started with KCNA
Understanding the KCNA Exam Structure
Not practicing time management; 90 minutes for 60 questions means you have about 90 seconds per question.
Getting Started with KCNA
Understanding the KCNA Exam Structure
Ignoring the free retake policy and not taking advantage of it if needed; it's a valuable second chance.
Getting Started with KCNA
kubectl
The primary command-line tool for interacting with Kubernetes clusters.
Getting Started with KCNA
Minikube
A tool that runs a single-node Kubernetes cluster locally on your machine.
Getting Started with KCNA
Kind
Kubernetes in Docker; runs local multi-node clusters using Docker containers.
Getting Started with KCNA
Cloud Sandbox
Temporary, browser-based environments for practicing Kubernetes skills.
Getting Started with KCNA
YAML
Human-readable data serialization format, widely used for Kubernetes configuration.
Getting Started with KCNA
Docker Desktop
Application for macOS, Windows, Linux that includes a Kubernetes option.
Getting Started with KCNA
CLI
Command-Line Interface; a text-based way to interact with a computer.
Getting Started with KCNA
Setting Up Your Learning Environment
To remember the local tools: 'My Kind Docker' (Minikube, Kind, Docker Desktop).
Getting Started with KCNA
Setting Up Your Learning Environment
The KCNA exam expects you to know the purpose of tools like kubectl, Minikube, and Kind, and understand the difference between local and cloud-based environments. Focus on their primary use cases.
Getting Started with KCNA
Setting Up Your Learning Environment
Trying to learn Kubernetes solely through theory without hands-on practice.
Getting Started with KCNA
Setting Up Your Learning Environment
Not understanding the difference between a local development environment and a production cluster.
Getting Started with KCNA
Setting Up Your Learning Environment
Neglecting to learn basic command-line operations, which are fundamental for Kubernetes interaction.
Getting Started with KCNA
Control Plane
The set of components that make global decisions about the cluster.
Kubernetes Core Concepts
Worker Node
A machine where containerized applications (pods) run.
Kubernetes Core Concepts
API Server
Exposes the Kubernetes API; central communication hub.
Kubernetes Core Concepts
etcd
Consistent, highly available key-value store for all cluster data.
Kubernetes Core Concepts
Scheduler
Watches for new pods and assigns them to worker nodes.
Kubernetes Core Concepts
Controller Manager
Runs controllers that maintain the desired cluster state.
Kubernetes Core Concepts
Kubelet
Agent on a worker node that ensures containers run in a pod.
Kubernetes Core Concepts
Kube-proxy
Network proxy that maintains network rules on worker nodes.
Kubernetes Core Concepts
Kubernetes Architecture & Core Components
Think of Kubernetes like a KIngdom: The API Server is the Royal Gate, etcd is the Royal Records, the Scheduler is the Royal Matchmaker, the Controller Manager is the Royal Steward, and the Kubelets are the Loyal Subjects.
Kubernetes Core Concepts
Kubernetes Architecture & Core Components
The KCNA exam frequently tests your ability to identify the function of each core component. Pay close attention to which components reside on the control plane versus worker nodes, and memorise the primary role of API Server, etcd, Scheduler, and Kubelet.
Kubernetes Core Concepts
Kubernetes Architecture & Core Components
Confusing the roles of the Scheduler and the Controller Manager. The Scheduler places pods; controllers ensure the desired state of various resources.
Kubernetes Core Concepts
Kubernetes Architecture & Core Components
Underestimating the importance of etcd. It's not just a database; it's the single source of truth for the entire cluster's state.
Kubernetes Core Concepts
Kubernetes Architecture & Core Components
Forgetting that the API Server is the *only* component that directly communicates with etcd.
Kubernetes Core Concepts
Kubernetes Architecture & Core Components
Misidentifying which components run on the control plane versus the worker nodes.
Kubernetes Core Concepts
Container
Isolated package of software with all dependencies.
Kubernetes Core Concepts
Container Runtime
Software that runs and manages containers on a host.
Kubernetes Core Concepts
Pod
Smallest deployable unit in Kubernetes; encapsulates containers.
Kubernetes Core Concepts
Deployment
Kubernetes object that manages Pods and ReplicaSets declaratively.
Kubernetes Core Concepts
ReplicaSet
Ensures a specified number of Pod replicas are running.
Kubernetes Core Concepts
Declarative
Describes desired state; Kubernetes works to achieve it.
Kubernetes Core Concepts
Imperative
Direct commands telling Kubernetes what to do.
Kubernetes Core Concepts
Sidecar Container
Secondary container in a Pod, supporting the main app.
Kubernetes Core Concepts
Containers, Pods, and Deployments
CPD: Containers are the building blocks, Pods are the smallest deployable unit, and Deployments manage the Pods.
Kubernetes Core Concepts
Containers, Pods, and Deployments
The exam will test your understanding of the hierarchy: a Deployment manages ReplicaSets, which manage Pods, which contain containers. Know that Pods are the smallest deployable unit and that a container runtime is essential for executing containers.
Kubernetes Core Concepts
Containers, Pods, and Deployments
Confusing a container with a Pod; a Pod can contain multiple containers but is the smallest unit Kubernetes directly manages.
Kubernetes Core Concepts
Containers, Pods, and Deployments
Trying to manage individual Pods directly for stateless applications; Deployments are designed for this purpose.
Kubernetes Core Concepts
Containers, Pods, and Deployments
Not understanding that a container runtime (like containerd) is distinct from Kubernetes itself, but necessary for it to function.
Kubernetes Core Concepts
Service
Abstracts Pods, provides stable network access and load balancing.
Kubernetes Core Concepts
ClusterIP
Default Service type, internal IP, only accessible within cluster.
Kubernetes Core Concepts
NodePort
Exposes Service on a static port on each Node's IP.
Kubernetes Core Concepts
LoadBalancer
External IP provided by cloud for public access.
Kubernetes Core Concepts
Namespace
Logical isolation mechanism for cluster resources.
Kubernetes Core Concepts
Pod IP
Unique IP address assigned to each Pod for direct communication.
Kubernetes Core Concepts
CNI
Container Network Interface, plugin for Kubernetes networking.
Kubernetes Core Concepts
Services, Namespaces, and Basic Networking
Imagine a 'Service' is like a receptionist: no matter which employee (Pod) is currently at the desk, the receptionist (Service) always has the same phone number (IP/DNS) and directs calls (traffic) to the right person.
Kubernetes Core Concepts
Services, Namespaces, and Basic Networking
The KCNA exam frequently tests the differences between Service types. Memorize the primary use case for ClusterIP (internal), NodePort (Node-level external), and LoadBalancer (cloud external). Also, know that Namespaces provide logical isolation, not network isolation by default.
Kubernetes Core Concepts
Services, Namespaces, and Basic Networking
Confusing Namespaces with network isolation; they are logical, not network, boundaries.
Kubernetes Core Concepts
Services, Namespaces, and Basic Networking
Expecting a ClusterIP Service to be directly accessible from outside the cluster.
Kubernetes Core Concepts
Services, Namespaces, and Basic Networking
Not understanding that Pods are ephemeral and their IPs change, necessitating Services for stable access.
Kubernetes Core Concepts
Persistent Storage
Data that survives beyond the life of a container or pod.
Kubernetes Core Concepts
PersistentVolume (PV)
Cluster resource representing a piece of storage provisioned by an admin.
Kubernetes Core Concepts
PersistentVolumeClaim (PVC)
A user's request for storage, consuming PV resources.
Kubernetes Core Concepts
Ephemeral
Temporary; data is lost when a container or pod is terminated.
Kubernetes Core Concepts
Desired State
The target configuration defined in Kubernetes object manifests.
Kubernetes Core Concepts
kubectl, YAML, and Persistent Storage
PV is 'Provided Volume' (by admin), PVC is 'Pod's Volume Claim' (by user).
Kubernetes Core Concepts
kubectl, YAML, and Persistent Storage
The KCNA exam frequently tests your understanding of the relationship between PVs and PVCs. Remember that a PV is a cluster resource, and a PVC is a request for that resource. Look for keywords like 'provisioned storage' for PV and 'request for storage' for PVC.
Kubernetes Core Concepts
kubectl, YAML, and Persistent Storage
Confusing the roles of PersistentVolume (PV) and PersistentVolumeClaim (PVC). PV is the actual storage resource, PVC is the request for it.
Kubernetes Core Concepts
kubectl, YAML, and Persistent Storage
Forgetting that container data is ephemeral by default; persistent storage is required for data durability.
Kubernetes Core Concepts
kubectl, YAML, and Persistent Storage
Trying to modify a running Kubernetes resource directly without using kubectl apply or edit commands, which can lead to configuration drift.
Kubernetes Core Concepts
Microservice
Small, independent service focused on a business capability.
Cloud Native Principles
Monolithic Application
Single, tightly coupled application where all components are combined.
Cloud Native Principles
Loose Coupling
Services can change without affecting others significantly.
Cloud Native Principles
Independent Deployment
Services can be deployed without redeploying the entire app.
Cloud Native Principles
API Gateway
Single entry point for client requests to multiple services.
Cloud Native Principles
Decentralized Data
Each microservice manages its own dedicated data store.
Cloud Native Principles
Cloud Native
Applications built to leverage cloud computing benefits.
Cloud Native Principles
Microservices and Cloud Native Design
Think 'MICRO' for Microservices: M-odular, I-ndependent, C-ommunicate via API, R-esilient, O-wns its data.
Cloud Native Principles
Microservices and Cloud Native Design
The exam often tests your understanding of the core characteristics and benefits of microservices. Look for keywords like 'independently deployable,' 'loosely coupled,' 'business capabilities,' and 'scalable.' Be prepared to differentiate them from monolithic architectures.
Cloud Native Principles
Microservices and Cloud Native Design
Treating microservices as simply splitting a monolith without addressing independent data stores or communication patterns.
Cloud Native Principles
Microservices and Cloud Native Design
Over-engineering by breaking down services too granularly, leading to excessive inter-service communication overhead.
Cloud Native Principles
Microservices and Cloud Native Design
Neglecting robust monitoring and logging, which are crucial for debugging and managing distributed systems.
Cloud Native Principles
Continuous Integration (CI)
Developers frequently merge code, triggering automated builds and tests.
Cloud Native Principles
Continuous Delivery (CD)
Code changes are always ready for release, awaiting manual approval.
Cloud Native Principles
Continuous Deployment (CD)
Code changes automatically deploy to production after passing tests.
Cloud Native Principles
GitOps
Operational framework using Git as the single source of truth for declarative infrastructure.
Cloud Native Principles
Immutable Infrastructure
Servers are never modified after deployment; changes require new instances.
Cloud Native Principles
Configuration Drift
When system configurations diverge from their intended or documented state.
Cloud Native Principles
CI/CD, GitOps, and Immutable Infrastructure
Imagine a 'GIt' with 'OpS' (GitOps) like a meticulous librarian. Every book (your infrastructure config) has a perfect, version-controlled copy. If you want to change a book, you don't scribble in it (mutable), you get a NEW, updated copy (immutable) and replace the old one!
Cloud Native Principles
CI/CD, GitOps, and Immutable Infrastructure
The KCNA exam will test your understanding of these concepts as fundamental cloud-native practices. Look for questions about automating deployments, managing infrastructure through Git, and ensuring consistent environments. Keywords like 'single source of truth for infrastructure' point to GitOps. 'Never modify in place' points to immutable infrastructure.
Cloud Native Principles
CI/CD, GitOps, and Immutable Infrastructure
Confusing Continuous Delivery (ready for deployment) with Continuous Deployment (automatically deployed).
Cloud Native Principles
CI/CD, GitOps, and Immutable Infrastructure
Believing immutable infrastructure means no changes; it means no *in-place* changes, always replacing.
Cloud Native Principles
CI/CD, GitOps, and Immutable Infrastructure
Thinking GitOps is just about using Git; it's specifically about using Git as the *declarative single source of truth* for desired state and automated reconciliation.
Cloud Native Principles
Observability
Ability to understand system's internal state from external outputs.
Cloud Native Principles
Logs
Timestamped records of discrete events in a system.
Cloud Native Principles
Metrics
Numerical measurements collected over time for system health.
Cloud Native Principles
Traces
End-to-end view of a request's journey through distributed services.
Cloud Native Principles
Serverless Computing
Cloud execution model where provider manages servers; pay-per-use.
Cloud Native Principles
FaaS (Functions as a Service)
Individual, stateless functions executed on demand in serverless.
Cloud Native Principles
Event-Driven
Architecture where components react to events, common in serverless.
Cloud Native Principles
Cold Start
Initial delay when a serverless function is invoked after inactivity.
Cloud Native Principles
Observability and Serverless Concepts
To remember the three pillars of observability, think 'LMT': Logs, Metrics, Traces. Like a 'Limit' to what you can see without them!
Cloud Native Principles
Observability and Serverless Concepts
The exam often tests your understanding of the three pillars of observability (logs, metrics, traces) and the core benefits of serverless computing, such as auto-scaling and reduced operational overhead. Look for keywords like 'infer internal state' for observability and 'event-driven, no server management' for serverless.
Cloud Native Principles
Observability and Serverless Concepts
Confusing monitoring with observability; monitoring tells you 'what', observability tells you 'why'.
Cloud Native Principles
Observability and Serverless Concepts
Assuming 'serverless' means no servers at all; it means you don't manage them.
Cloud Native Principles
Observability and Serverless Concepts
Underestimating the importance of distributed tracing in microservice environments.
Cloud Native Principles
Service Mesh
Dedicated infrastructure layer for service-to-service communication.
Cloud Native Principles
Sidecar Proxy
Proxy running alongside a service, intercepting its network traffic.
Cloud Native Principles
Data Plane
Collection of sidecar proxies that manage network traffic.
Cloud Native Principles
North-South Traffic
Traffic between external clients and internal services.
Cloud Native Principles
East-West Traffic
Traffic between services within a microservices architecture.
Cloud Native Principles
mTLS
Mutual TLS; two-way authentication and encryption for network connections.
Cloud Native Principles
Service Mesh and API Gateways
Think of an 'API Gateway' as a bouncer at a club's entrance (external access), and a 'Service Mesh' as the club's internal security team managing interactions between different rooms (internal services).
Cloud Native Principles
Service Mesh and API Gateways
The exam often tests the distinction between an API Gateway and a Service Mesh. Remember: API Gateway = 'North-South' (external clients), Service Mesh = 'East-West' (internal services). Both can provide traffic management and security, but for different traffic flows.
Cloud Native Principles
Service Mesh and API Gateways
Confusing the roles: Assuming an API Gateway can fully replace a service mesh for internal communication, or vice-versa.
Cloud Native Principles
Service Mesh and API Gateways
Over-engineering: Implementing a service mesh for a simple application with only a few services, where the overhead outweighs the benefits.
Cloud Native Principles
Service Mesh and API Gateways
Neglecting observability: Not configuring the service mesh's telemetry features, missing out on crucial insights into service health.
Cloud Native Principles
Software Supply Chain
All components and processes involved in software creation and delivery.
Securing Cloud Native Applications
Supply Chain Attack
Malicious tampering at any stage of the software development lifecycle.
Securing Cloud Native Applications
Container Image Signing
Cryptographically verifying the authenticity and integrity of container images.
Securing Cloud Native Applications
Vulnerability Scanning
Automated tools to detect known security flaws in code or dependencies.
Securing Cloud Native Applications
Network Policy
Kubernetes resource defining how pods communicate with each other and endpoints.
Securing Cloud Native Applications
Ingress Traffic
Network traffic entering a pod or network boundary.
Securing Cloud Native Applications
Egress Traffic
Network traffic leaving a pod or network boundary.
Securing Cloud Native Applications
Least Privilege
Granting only the minimum necessary permissions to perform a task.
Securing Cloud Native Applications
Supply Chain and Network Security
For 'Supply Chain Security,' think 'SCAN': Scan dependencies, Control access, Authenticate artifacts, Network policies.
Securing Cloud Native Applications
Supply Chain and Network Security
The KCNA exam expects you to know that Network Policies are used for controlling pod-to-pod communication and that they are namespace-scoped. Understand that by default, pods are non-isolated. Also, be aware of the general concept of supply chain security, including image scanning and trusted registries.
Securing Cloud Native Applications
Supply Chain and Network Security
Assuming all open-source components are inherently safe without scanning them for vulnerabilities.
Securing Cloud Native Applications
Supply Chain and Network Security
Forgetting to implement Network Policies, leaving pods open to unrestricted internal communication.
Securing Cloud Native Applications
Supply Chain and Network Security
Not signing container images, making it impossible to verify their origin and integrity.
Securing Cloud Native Applications
Runtime Security
Protecting applications and infrastructure during active execution.
Securing Cloud Native Applications
Container Escape
Breaking out of a container to gain access to the host system.
Securing Cloud Native Applications
Behavioral Monitoring
Observing and analyzing normal application behavior to detect anomalies.
Securing Cloud Native Applications
Anomaly Detection
Identifying deviations from expected patterns of behavior.
Securing Cloud Native Applications
Micro-segmentation
Isolating workloads via fine-grained network policies.
Securing Cloud Native Applications
Falco
An open-source container runtime security tool for threat detection.
Securing Cloud Native Applications
Runtime Security Best Practices
RUN-TIME: **R**eal-time **U**nderstanding, **N**otice **T**hreats, **I**solate **M**alware, **E**nforce policies.
Securing Cloud Native Applications
Runtime Security Best Practices
The KCNA exam will test your understanding of *when* different security measures apply. Runtime security is distinct from build-time (e.g., image scanning) and deploy-time (e.g., admission controllers) security. Look for keywords like 'during execution,' 'active threats,' or 'monitoring live applications.'
Securing Cloud Native Applications
Runtime Security Best Practices
Assuming security ends after deployment; runtime threats are very real.
Securing Cloud Native Applications
Runtime Security Best Practices
Relying solely on static analysis; dynamic threats require dynamic monitoring.
Securing Cloud Native Applications
Runtime Security Best Practices
Overlooking the importance of least privilege for running processes.
Securing Cloud Native Applications
Secret
Kubernetes object for storing small amounts of sensitive data.
Securing Cloud Native Applications
Base64 Encoding
An encoding scheme, not encryption, used by Kubernetes Secrets.
Securing Cloud Native Applications
Secret Rotation
Periodically changing sensitive credentials to enhance security.
Securing Cloud Native Applications
External Secrets Manager
Third-party tools for advanced secret storage and lifecycle.
Securing Cloud Native Applications
Secrets Management in Kubernetes
Remember 'BASE64 is NOT encryption!' – it's just a way to represent binary data as text, not a security measure.
Securing Cloud Native Applications
Secrets Management in Kubernetes
The KCNA exam will test your understanding that Kubernetes Secrets are base64 encoded, not encrypted by default, and the importance of external solutions for robust security. Keywords to spot: 'base64', 'encryption at rest', 'external secret store'.
Securing Cloud Native Applications
Secrets Management in Kubernetes
Assuming Kubernetes Secrets are encrypted at rest by default (they are base64 encoded, not encrypted).
Securing Cloud Native Applications
Secrets Management in Kubernetes
Exposing secrets as environment variables, which can be easily leaked.
Securing Cloud Native Applications
Secrets Management in Kubernetes
Hardcoding secrets directly into application code or committing them to version control.
Securing Cloud Native Applications
Authentication
Verifying the identity of a user or service.
Securing Cloud Native Applications
Authorization
Determining what an authenticated identity can do.
Securing Cloud Native Applications
RBAC
Role-Based Access Control; Kubernetes authorization method.
Securing Cloud Native Applications
Role
Namespace-scoped set of permissions in Kubernetes.
Securing Cloud Native Applications
ClusterRole
Cluster-wide set of permissions in Kubernetes.
Securing Cloud Native Applications
RoleBinding
Links a Role to a subject within a namespace.
Securing Cloud Native Applications
ClusterRoleBinding
Links a ClusterRole to a subject across the cluster.
Securing Cloud Native Applications
Service Account
Identity for processes running inside Kubernetes pods.
Securing Cloud Native Applications
Identity and Access Management (IAM)
For RBAC, remember 'RAC': Roles define Actions, Bindings Connect them to Subjects. 'R' is for 'Role', 'A' for 'Actions', 'C' for 'Connect'.
Securing Cloud Native Applications
Identity and Access Management (IAM)
The KCNA exam will test your understanding of Kubernetes RBAC components: Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. Know their scope (namespace vs. cluster) and purpose. Also, differentiate between authentication (who are you?) and authorization (what can you do?).
Securing Cloud Native Applications
Identity and Access Management (IAM)
Granting `cluster-admin` ClusterRole to users or service accounts unnecessarily, leading to over-privileged access.
Securing Cloud Native Applications
Identity and Access Management (IAM)
Confusing the purpose of a Role (namespace-specific) with a ClusterRole (cluster-wide).
Securing Cloud Native Applications
Identity and Access Management (IAM)
Hardcoding sensitive credentials or tokens directly into application code or container images instead of using Kubernetes Secrets and Service Accounts with appropriate RBAC.
Securing Cloud Native Applications
Monitoring
Continuous collection and analysis of system data.
Monitoring and Troubleshooting
Alerting
Notifying individuals when predefined conditions are met.
Monitoring and Troubleshooting
Latency
The time delay between a request and a response.
Monitoring and Troubleshooting
Throughput
The rate at which a system processes requests or data.
Monitoring and Troubleshooting
Threshold
A predefined value that triggers an alert when crossed.
Monitoring and Troubleshooting
MTTD
Mean Time To Detect, the average time to identify an issue.
Monitoring and Troubleshooting
MTTR
Mean Time To Resolve, the average time to fix an issue.
Monitoring and Troubleshooting
Monitoring and Alerting Fundamentals
To remember the purpose of monitoring and alerting: 'M'onitoring 'A'lways 'K'eeps 'E'verything 'S'afe – 'MAKE S'ure to get 'A'lerts 'F'or 'E'verything.
Monitoring and Troubleshooting
Monitoring and Alerting Fundamentals
The KCNA exam will test your understanding of why monitoring and alerting are important, and the types of data they involve (metrics, logs, traces). Be ready to distinguish between different metric types and the purpose of an alert.
Monitoring and Troubleshooting
Monitoring and Alerting Fundamentals
Ignoring alerts or suffering from 'alert fatigue' due to too many non-critical notifications.
Monitoring and Troubleshooting
Monitoring and Alerting Fundamentals
Monitoring only infrastructure (CPU, memory) and neglecting application-specific or business metrics.
Monitoring and Troubleshooting
Monitoring and Alerting Fundamentals
Setting static thresholds for metrics that have dynamic or seasonal patterns, leading to false positives or missed issues.
Monitoring and Troubleshooting
Log
A time-stamped record of an event.
Monitoring and Troubleshooting
Structured Logging
Logs in a machine-readable format like JSON.
Monitoring and Troubleshooting
Trace
The end-to-end journey of a request.
Monitoring and Troubleshooting
Span
A single operation within a trace.
Monitoring and Troubleshooting
Distributed Tracing
Tracking requests across multiple services.
Monitoring and Troubleshooting
Log Collector
Gathers logs from various sources.
Monitoring and Troubleshooting
Trace Collector
Aggregates span data from services.
Monitoring and Troubleshooting
Logging and Tracing Concepts
Logs are like a diary entry (a single event). Traces are like following a detective's trail (the whole story).
Monitoring and Troubleshooting
Logging and Tracing Concepts
The exam often tests the fundamental difference between logs and traces. Remember: logs are discrete events, traces are connected sequences of events for a single request. Keywords to watch for include 'request flow', 'end-to-end latency', 'specific event', 'system state'.
Monitoring and Troubleshooting
Logging and Tracing Concepts
Confusing logs (discrete events) with traces (end-to-end request flow).
Monitoring and Troubleshooting
Logging and Tracing Concepts
Not implementing structured logging, making analysis difficult.
Monitoring and Troubleshooting
Logging and Tracing Concepts
Failing to propagate trace context across service boundaries, breaking distributed traces.
Monitoring and Troubleshooting
Prometheus
Open-source monitoring system for time-series metrics.
Monitoring and Troubleshooting
Grafana
Open-source web application for data visualization and dashboards.
Monitoring and Troubleshooting
Scraping
Prometheus's pull mechanism to collect metrics from targets.
Monitoring and Troubleshooting
Exporter
Tool that exposes existing metrics in Prometheus format.
Monitoring and Troubleshooting
Time Series
Sequence of data points indexed by time, with labels.
Monitoring and Troubleshooting
PromQL
Prometheus Query Language for querying and aggregating metrics.
Monitoring and Troubleshooting
Alertmanager
Handles alerts sent by Prometheus, grouping and routing them.
Monitoring and Troubleshooting
Dashboard
A collection of visualizations in Grafana for monitoring.
Monitoring and Troubleshooting
Prometheus and Grafana Basics
P-G-V: Prometheus Gathers, Grafana Visualizes! Remember, Prometheus is the strong 'P'ull-er, and Grafana is the 'G'reat 'V'isualizer.
Monitoring and Troubleshooting
Prometheus and Grafana Basics
The exam often tests the distinct roles of Prometheus (data collection, storage, alerting rules) and Grafana (visualization, dashboards). Keywords to watch for include 'scrape', 'time series', 'PromQL', 'dashboard', and 'data source'.
Monitoring and Troubleshooting
Prometheus and Grafana Basics
Confusing Prometheus's role (collection/storage) with Grafana's (visualization).
Monitoring and Troubleshooting
Prometheus and Grafana Basics
Forgetting that Prometheus uses a 'pull' model for scraping metrics.
Monitoring and Troubleshooting
Prometheus and Grafana Basics
Not understanding the purpose of Exporters in the Prometheus ecosystem.
Monitoring and Troubleshooting
Elasticsearch
Distributed search and analytics engine for data storage.
Monitoring and Troubleshooting
Logstash
Server-side data processing pipeline for ingestion and transformation.
Monitoring and Troubleshooting
Kibana
Web interface for visualizing and analyzing Elasticsearch data.
Monitoring and Troubleshooting
Beats
Lightweight data shippers for collecting various types of data.
Monitoring and Troubleshooting
Centralized Logging
Aggregating logs from multiple sources into a single location.
Monitoring and Troubleshooting
Indexing
Process of structuring data for fast searching in Elasticsearch.
Monitoring and Troubleshooting
Introduction to the ELK Stack
Remember 'ELK' as 'Every Log Knows' where 'E' is for Elasticsearch (storage), 'L' for Logstash (processing), and 'K' for Kibana (seeing).
Monitoring and Troubleshooting
Introduction to the ELK Stack
The KCNA exam expects you to know the primary function of each component: Elasticsearch (store/search), Logstash (process/transform), Kibana (visualize). Also, recognize Beats as lightweight data shippers.
Monitoring and Troubleshooting
Introduction to the ELK Stack
Confusing the roles of Logstash and Beats: Beats are for lightweight collection, Logstash for heavy processing.
Monitoring and Troubleshooting
Introduction to the ELK Stack
Thinking ELK is only for logs; it can handle metrics and other data types too.
Monitoring and Troubleshooting
Introduction to the ELK Stack
Underestimating the resource requirements for Elasticsearch, especially for large-scale deployments.
Monitoring and Troubleshooting
Container Registry
A centralized service for storing and distributing container images.
Delivering Cloud Native Applications
Container Image
A lightweight, standalone, executable package of software.
Delivering Cloud Native Applications
Dockerfile
A text file containing instructions to build a Docker image.
Delivering Cloud Native Applications
Image Tag
A label used to identify different versions or variants of an image.
Delivering Cloud Native Applications
Docker Hub
A popular public registry for Docker images.
Delivering Cloud Native Applications
Private Registry
A registry used by organizations to securely store proprietary images.
Delivering Cloud Native Applications
Container Registries and Image Management
Registry: R for Repository, E for Easy access, G for Global distribution, I for Image storage, S for Secure, T for Tagging, R for Reliable, Y for Your images.
Delivering Cloud Native Applications
Container Registries and Image Management
The KCNA exam will test your understanding of what a container registry is, its purpose, and the difference between public and private registries. Pay attention to image tagging best practices and the overall image lifecycle.
Delivering Cloud Native Applications
Container Registries and Image Management
Using only the 'latest' tag for production deployments, leading to unpredictable behavior.
Delivering Cloud Native Applications
Container Registries and Image Management
Not scanning images for vulnerabilities before pushing them to a registry.
Delivering Cloud Native Applications
Container Registries and Image Management
Storing sensitive information directly within a Docker image instead of using secrets management.
Delivering Cloud Native Applications
Helm
The package manager for Kubernetes, simplifying application deployment and management.
Delivering Cloud Native Applications
Chart
A Helm package that contains all the resource definitions necessary to run an application.
Delivering Cloud Native Applications
Release
An instance of a Chart deployed into a Kubernetes cluster by Helm.
Delivering Cloud Native Applications
values.yaml
A file within a Helm Chart that defines default configuration values for the Chart.
Delivering Cloud Native Applications
templates/
A directory in a Chart containing Kubernetes manifest templates rendered by Helm.
Delivering Cloud Native Applications
Helm Repository
A collection of Helm Charts that can be searched and installed.
Delivering Cloud Native Applications
rollback
The process of reverting a Helm release to a previous, stable version.
Delivering Cloud Native Applications
Helm for Kubernetes Package Management
Imagine a HELM-et for your K8s apps: it PACKAGES them safely, protects them from CONFIGURATION issues, and lets you ROLLBACK if there's a crash!
Delivering Cloud Native Applications
Helm for Kubernetes Package Management
The KCNA exam expects you to know Helm's purpose, its core components (Charts, values.yaml, templates), and basic commands like install, upgrade, and rollback. Pay attention to the concept of a 'release'.
Delivering Cloud Native Applications
Helm for Kubernetes Package Management
Confusing Helm Charts with raw Kubernetes YAML files; Charts are templates that generate YAML.
Delivering Cloud Native Applications
Helm for Kubernetes Package Management
Forgetting to update Helm repositories before searching for new charts.
Delivering Cloud Native Applications
Helm for Kubernetes Package Management
Not understanding that `helm install` creates a new release, while `helm upgrade` modifies an existing one.
Delivering Cloud Native Applications
Operator
Software extension for Kubernetes that automates application management.
Delivering Cloud Native Applications
Custom Resource
Extension of the Kubernetes API, defined by an Operator to manage applications.
Delivering Cloud Native Applications
Controller Pattern
Software design pattern where a controller observes and reconciles state.
Delivering Cloud Native Applications
Git
Distributed version control system for tracking changes in files.
Delivering Cloud Native Applications
Reconciliation
Process of bringing the current state of a system to its desired state.
Delivering Cloud Native Applications
Operators and Git for Cloud Native Automation
Imagine an 'Opera-tor' (Operator) conducting an orchestra (your application) in Kubernetes, while 'Git' (like a diligent librarian) keeps a perfect, version-controlled score (your config) for the entire performance!
Delivering Cloud Native Applications
Operators and Git for Cloud Native Automation
The KCNA exam will test your understanding of Operators as extending Kubernetes capabilities to manage complex applications, and GitOps as an operational model using Git for declarative infrastructure management. Look for keywords like 'automate application lifecycle' for Operators and 'Git as single source of truth' for GitOps.
Delivering Cloud Native Applications
Operators and Git for Cloud Native Automation
Confusing an Operator with a simple Helm chart; Operators provide ongoing lifecycle management, not just initial deployment.
Delivering Cloud Native Applications
Operators and Git for Cloud Native Automation
Thinking GitOps replaces CI/CD; GitOps is an operational model that often leverages CI/CD pipelines.
Delivering Cloud Native Applications
Operators and Git for Cloud Native Automation
Underestimating the importance of declarative configuration in both Operators and GitOps; both rely heavily on defining desired states.
Delivering Cloud Native Applications
CI/CD Pipeline
Automated workflow for building, testing, and deploying software.
Delivering Cloud Native Applications
Continuous Deployment
Automated release to production after passing tests.
Delivering Cloud Native Applications
Infrastructure as Code (IaC)
Managing and provisioning infrastructure through code.
Delivering Cloud Native Applications
Deployment Manifest
YAML file describing a desired state of an application in Kubernetes.
Delivering Cloud Native Applications
CI/CD Pipelines and Infrastructure as Code
CI/CD: 'Code In, Code Done!' – It's all about getting your code from commit to completion automatically.
Delivering Cloud Native Applications
CI/CD Pipelines and Infrastructure as Code
The KCNA exam will test your understanding of how CI/CD pipelines integrate with Kubernetes for automated deployments. Look for keywords like 'automated builds', 'container image management', 'declarative configuration', and 'version control for infrastructure'. Be familiar with the concepts of continuous delivery vs. continuous deployment.
Delivering Cloud Native Applications
CI/CD Pipelines and Infrastructure as Code
Confusing Continuous Delivery with Continuous Deployment: Delivery means ready to deploy, Deployment means automatically deployed.
Delivering Cloud Native Applications
CI/CD Pipelines and Infrastructure as Code
Ignoring the importance of testing within CI/CD: Without robust automated tests, automation can deploy bugs faster.
Delivering Cloud Native Applications
CI/CD Pipelines and Infrastructure as Code
Treating infrastructure manually while automating code: This creates inconsistencies and bottlenecks, defeating the purpose of IaC.
Delivering Cloud Native Applications