Category Archives: DevOps & Automation

ConfigMaps and Secrets are both Kubernetes API objects used to supply data to workloads, and both can appear as mounted files or environment values. Their similar consumption patterns can hide the most important distinction: ConfigMaps are intended for non-confidential configuration, while Secrets are intended for sensitive data and require stronger protection. The current KCNA exam […]

Kubernetes NetworkPolicy defines allowed traffic for selected Pods at the IP-address and port layers. It is a workload segmentation primitive, not a firewall product by itself: enforcement depends on a network plugin that supports the NetworkPolicy API. KCNA includes Kubernetes networking and security fundamentals, while production NetworkPolicy authoring requires precise knowledge of selector scope and […]

Kubernetes probes look simple in YAML, but at scale they are part of a distributed failure-control system. A liveness failure can restart a container, a readiness failure can remove a Pod from Service traffic, and a startup probe can suppress the other two checks while a slow process initializes. Treating all three as a generic […]

Resource requests and limits shape two different control loops in Kubernetes. Requests tell the scheduler how much capacity a workload needs for placement, while limits constrain how much the container may consume after it starts. The distinction is central to the Linux Foundation KCNA because scheduling, node pressure, and container isolation all depend on it. […]

Linux capabilities divide root privileges into narrow kernel permissions, but which permissions remain usable depends on process credentials, exec transitions, namespaces, and runtime configuration. Linux Foundation KCNA establishes the Kubernetes and container-isolation foundations; detailed capability reduction is a more specialized operating-system and cloud-native security skill. A container running as non-root can still have a dangerous […]

Containers depend on Linux kernel primitives rather than a single “container” feature. Namespaces change what a process can see and identify, while control groups—cgroups—account for and constrain resources. Understanding those two mechanisms helps connect KCNA container fundamentals to the behavior operators observe in Kubernetes. In Kubernetes operations, namespaces explain why two processes can have different […]

Container image signing adds cryptographic evidence to an artifact so a deployment system can verify who signed it and whether the referenced image matches the signed content. It addresses a supply-chain question that vulnerability scanning alone cannot answer: is this the artifact the trusted build or release process actually approved? Image signing is a specialized […]

eBPF makes it possible to run verified programs at selected points in the Linux kernel and collect high-value runtime data without modifying every application. In cloud-native environments, that can expose network flows, system-call behavior, process execution, latency, and other kernel-level signals that are difficult to obtain from application instrumentation alone. The KCNA exam includes foundational […]

Kubernetes admission control is the policy layer that evaluates API requests after authentication and authorization but before an accepted object is persisted. That position makes admission a powerful preventative boundary: the cluster can reject or mutate an unsafe workload definition before controllers schedule it. KCNA introduces Kubernetes security and API administration at a conceptual level; […]

Terraform drift is the gap between the infrastructure Terraform expects and the infrastructure that actually exists. It commonly appears after manual console changes, emergency fixes, automated systems that modify managed resources, provider-side defaults, or organizational processes that allow changes outside the Terraform workflow. The current Terraform Associate 004 exam gives candidates the state and planning […]

Terraform import is how an existing infrastructure object becomes bound to a Terraform resource address so the object can be managed through configuration and state. The operation sounds like a migration shortcut, but the difficult work is not the import command itself. The difficult work is creating configuration that accurately describes the existing object without […]

Terraform modules are one of the main mechanisms for turning infrastructure code into a reusable engineering system, but reuse alone does not make a module architecture scalable. A module can remove duplicated HCL while still creating tight coupling, hidden dependencies, slow releases, and a blast radius that grows with every consumer. The current Terraform Associate […]

Terraform frequently handles values that deserve stronger protection than ordinary configuration: database passwords, API tokens, private keys, connection strings, and credentials returned by managed services. The critical distinction is that hiding a value in terminal output is not the same as preventing Terraform from storing it. The current Terraform Associate 004 exam includes the configuration […]

Terraform Stacks introduce a higher-level way to organize repeated infrastructure across environments, regions, accounts, or other deployment dimensions. A Stack is not simply a large root module and it is not a renamed HCP Terraform workspace; it has its own component and deployment model. Terraform Associate 004 includes fundamental state, dependency, lifecycle, and HCP Terraform […]

Terraform state is an ownership database. It records which configuration manages which real objects and stores enough resource data for Terraform to plan future changes. When too much infrastructure shares one state, a routine change can acquire an unnecessarily large blast radius; when state is split without a clear architecture, dependencies become fragile and duplicated. […]