Application Environments and Infrastructure Concepts: CNPA practice questions

An application environment is a place where a version of a service runs for a purpose: a developer's sandbox, a shared test or staging environment, production. A platform's job is to make environments cheap to create, consistent with each other and safely separated. The CNCF Platforms White Paper lists provisioning complete environments from templates, combining run-time and development-time services for scenarios such as web development or MLOps, among the use cases a maturing platform should meet. The maturity model shows the opposite case: a team that needed an isolated performance-test environment waited days, because the colleague who had built the last one had moved on and nobody knew how to recreate it.

Consistency comes from treating environment differences as configuration, not as different processes. DORA's deployment automation guidance lists three inputs to a deployment: the packages created by CI, which should be deployable to any environment including production; scripts to configure the environment, deploy the packages and run a smoke test; and environment-specific configuration. It recommends keeping scripts and configuration in version control, using the same deployment process for every environment and using the same packages for every environment. In Kubernetes, the environment-specific part is often a Kustomize overlay on a shared base, or one set of Helm values per environment.

Separation inside a cluster starts with namespaces. Object names only need to be unique within a namespace, and many security controls are namespace-scoped: RBAC Roles and NetworkPolicies apply within a namespace, so users and service accounts can be restricted to one. A ResourceQuota caps the aggregate resource consumption in a namespace and can limit how many objects of each kind are created there. The Kubernetes multi-tenancy documentation stresses that Kubernetes has no first-class tenant concept. A tenant may be a team or a customer, and isolation can range from namespaces in a shared cluster to a dedicated cluster per tenant; sharing saves cost and administration, and the benefit of stronger isolation has to be weighed against its cost and complexity.

Infrastructure concepts an associate should be comfortable with include the difference between compute, networking and storage services; ephemeral environments created on demand and deleted after use; and infrastructure as code, where infrastructure is described in versioned files just like application configuration. The white paper's infrastructure services domain names compute runtimes, programmable networks, and block and volume storage, with projects such as Kubernetes, KubeVirt, Knative, Cilium, Istio, Rook and Longhorn as examples.

Typical misconceptions are that a namespace is a security boundary on its own (it scopes policies but isolates nothing without RBAC, network policies and quotas), that staging must be a hand-maintained copy of production, and that each environment needs its own build. Building once and promoting the same artifact is what makes earlier test results meaningful.

Expect questions that ask how to isolate teams or environments, what belongs in environment-specific configuration, or why the same artifact and the same deployment process should move through every environment.