Soft multitenancy is a model where multiple tenants share the same Kubernetes cluster and its control plane, with logical separation enforced by native Kubernetes objects like Namespaces, RBAC, ResourceQuotas, and NetworkPolicies. The primary advantage and reason for choosing this model is to maximize resource utilization and operational efficiency. By allowing tenants to share the underlying infrastructure (nodes, control plane, etc.), organizations can reduce overhead and costs. This approach is suitable when tenants are trusted, such as different teams within the same enterprise, and the main goal is resource management and sharing, rather than strict, security-focused isolation.

B. When the priority is enabling complete isolation between tenants.

This describes the primary goal of hard multitenancy, which uses physically or virtually separate infrastructure (e.g., dedicated clusters, nodes, or virtual control planes) to achieve strong isolation.

C. When the priority is enabling fine-grained control over tenant resources.

While soft multitenancy uses tools like ResourceQuotas for control, this is not its unique differentiator. Hard multitenancy can also offer fine-grained control, making this statement less precise.

D. When the priority is enabling strict security boundaries between tenants.

This is the main objective of hard multitenancy. Soft multitenancy provides logical boundaries that are not considered as secure or strict against malicious or compromised tenants.

1. Kubernetes Official Documentation

"Multi-tenancy": The documentation distinguishes between soft and hard multitenancy. It implicitly supports that soft multitenancy is for shared environments

stating

"In a soft multi-tenancy model

tenants are aware of each other

but are prevented from interfering with each other by policies... This is often used by different teams within an enterprise." This context of internal teams highlights the focus on shared

efficient resource usage over absolute isolation.

Source: Kubernetes Authors. (n.d.). Multi-tenancy. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/security/multi-tenancy/

2. CNCF Kubernetes Policy Working Group

"Multi-Tenancy in Kubernetes Whitepaper": This paper discusses the spectrum of multitenancy. It frames soft multitenancy (referred to as "Namespace as a Service") as a model that "provides a good balance between isolation and resource sharing

" emphasizing that the sharing aspect is a key characteristic.

Source: CNCF Kubernetes Policy Working Group. (2021). Kubernetes Policy Management White Paper. Section: "Multi-Tenancy". Available at https://github.com/cncf/tag-security/blob/main/whit epapers/policy/CNCF-Policy-WhitePaper-v1.pdf

3. Red Hat OpenShift Documentation (Official Vendor Documentation)

"About multitenancy": The documentation explains that multitenancy allows an administrator to "use the cluster for multiple applications

teams

and departments

which saves money on infrastructure and administration." This directly links the multitenancy concept

particularly the shared-cluster (soft) model

to efficiency and resource sharing.

Source: Red Hat. (n.d.). About multitenancy. OpenShift Container Platform 4.14 Documentation. Retrieved from https://docs.openshift.com/container-platform/4.14/multitenancy/about-multitenancy.html

On a client machine, the kubectl command-line tool, by default, stores its configuration in the $HOME/.kube directory. This directory contains the config file, which holds sensitive information required to connect to one or more Kubernetes clusters. This information includes cluster API server endpoints, user credentials (such as client certificates and keys or authentication tokens), and context definitions. Access to this directory should be restricted as it grants cluster access.

A. /etc/kubernetes/ is the default directory on control-plane and worker nodes for Kubernetes component configuration files and static Pod manifests, not for client credentials.

C. /opt/kubernetes/secrets/ is not a standard or default directory used by Kubernetes for storing any type of configuration or credential information.

D. $HOME/.config/kubernetes/ is not the default location for kubectl configuration. While some applications follow the XDG Base Directory Specification, kubectl uses $HOME/.kube by default.

1. Kubernetes Documentation

"Organizing Cluster Access Using kubeconfig Files": This official documentation explicitly states

"By default

kubectl looks for a file named config in the $HOME/.kube directory." This file contains the credentials.

Source: Kubernetes Authors

"Organizing Cluster Access Using kubeconfig Files

" Kubernetes Documentation

tasks/access-application-cluster/configure-access-multiple-clusters.html.

2. Kubernetes Documentation

"kubectl Cheat Sheet": The cheat sheet reinforces this by showing commands that interact with the default configuration path. It notes that the KUBECONFIG environment variable can override this default path.

Source: Kubernetes Authors

"kubectl Cheat Sheet

" Kubernetes Documentation

reference/kubectl/cheatsheet.html

Section: "Config & Context".

Pod Security Policy (PSP) was a built-in admission controller in Kubernetes used to enforce security policies on pods at the cluster level. It was deprecated in Kubernetes v1.21 and completely removed in v1.25. The functionality provided by PSPs has been replaced by the built-in Pod Security Admission (PSA) controller, which enforces the Pod Security Standards (PSS). Therefore, Pod Security Policy is the direct precursor to the current Pod Security Standards model.

A. Container Runtime Security: This is a broad security domain concerning the container runtime (e.g., containerd, CRI-O), not a specific, deprecated Kubernetes API object that preceded Pod Security Standards.

B. Kubernetes Security Context: A securityContext is a current and valid field in the Pod and Container specifications used to define privilege and access controls. PSS uses these settings for validation, but it is not the predecessor.

C. Container Security Standards: This is a generic phrase and not the official name of the specific Kubernetes feature that was deprecated and replaced by the Pod Security Standards.

1. Kubernetes Documentation

"Pod Security Policy Deprecation": This official blog post explicitly details the deprecation timeline and states

"PodSecurityPolicy is being deprecated in Kubernetes v1.21

and will be removed in v1.25." It discusses the transition to the new built-in solution. (Source: Kubernetes Blog

April 6

2021).

2. Kubernetes Documentation

"Pod Security Admission": The official documentation for the replacement mechanism states

"Pod Security Admission is a built-in admission controller that implements the security controls outlined in the Pod Security Standards. This admission controller is enabled by default... As a replacement for PodSecurityPolicy

it offers a more ergonomic and maintainable approach to enforcing Pod security." (Source: Kubernetes Concepts

Security

Pod Security Admission

Section: "Pod Security Admission").

3. Kubernetes Documentation

"Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller": This guide provides direct instructions for the migration

reinforcing that Pod Security Admission (which enforces PSS) is the successor to Pod Security Policy. (Source: Kubernetes Tasks

Security

"Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller").

The PodSecurity admission controller is the built-in, native Kubernetes mechanism for enforcing the Pod Security Standards (PSS). This controller is enabled by default in modern Kubernetes versions. Administrators can enforce specific PSS levels (Privileged, Baseline, or Restricted) on a per-namespace basis by applying labels to the namespace metadata. For example, labeling a namespace with pod-security.kubernetes.io/enforce=restricted will cause the admission controller to reject any new pods in that namespace that do not conform to the Restricted policy. This method does not require any third-party software.

A. Kyverno and OPA are powerful third-party policy engines, not native Kubernetes components. The question specifically asks for a method without third-party tools.

C. This is false. The PodSecurity admission controller is a native, built-in feature of Kubernetes that can enforce the Pod Security Standard without external tools.

D. This is incorrect. Enforcement is not automatic. An administrator must explicitly configure which policy to apply to each namespace by setting the appropriate labels.

1. Kubernetes Documentation

"Pod Security Admission": This official document states

"Pod Security Admission is a built-in admission controller that implements the security controls outlined in the Pod Security Standards." It further explains the enforcement mechanism: "The desired policy is configured on a per-namespace basis by adding labels to a namespace." (See sections: "Pod Security Admission" and "Configuring Pod Security Admission").

2. Kubernetes Documentation

"Pod Security Standards": This page defines the standards themselves and notes their enforcement via the built-in PodSecurity admission controller. (See section: "What's next?").

3. Kubernetes Documentation

"Admission Controllers Reference": The PodSecurity controller is listed as a recommended

enabled-by-default admission controller. (See section: "PodSecurity").

A container breakout, also known as a container escape, is a security exploit where a process running within a container successfully bypasses the isolation boundaries enforced by the host kernel's namespaces and cgroups. The primary objective of such an attack is to gain unauthorized access and code execution capabilities on the underlying host operating system. This is considered a critical security failure, as it nullifies the main purpose of containerization—process isolation. A successful breakout often results from exploiting a kernel vulnerability, a misconfigured container runtime, or excessive permissions granted to the container (e.g., running in privileged mode).

A. Accessing a Pod's network traffic is a form of network attack within the Pod's scope, not the definition of escaping the container's process isolation to the host.

B. Reaching resource limits is a function of cgroups that results in process throttling or termination (e.g., OOMKilled), not a security escape.

C. Accessing the cloud provider's infrastructure is a potential, more severe consequence of a container breakout, but the breakout itself is the act of compromising the immediate host.

1. National Institute of Standards and Technology (NIST) Special Publication 800-190

"Application Container Security Guide":

Section 3.2.2

Kernel Exploits: "The kernel provides the core isolation and resource management for containers. If a container has a kernel exploit

it can break out of the container and gain control of the host. This is the most damaging type of container compromise." This directly defines a breakout as gaining control of the host.

2. Kubernetes Official Documentation

"Pod Security Standards":

Section: Privileged: The documentation for the privileged control states

"Privileged containers have access to host devices and can perform nearly any action on the host that the root user can... The primary risk of privileged containers is the ease of container breakout and host compromise." This links the concept of breakout directly to host compromise.

3. Red Hat Official Documentation

"What is a container breakout vulnerability?":

Article: "A container breakout is a situation where a malicious actor is able to escape the confines of a container and access the underlying host system. This can happen if there is a vulnerability in the container runtime

the host operating system

or the application running in the container." This source explicitly defines a breakout as accessing the host system.

Defining security policies using a declarative, "as-code" approach is the most effective method for achieving consistency, minimizing toil, and reducing misconfigurations. This methodology allows security rules to be written in a high-level, human-readable language, stored in version control systems (like Git), and applied automatically across the environment. This process enables peer reviews, automated testing, and consistent enforcement, which significantly lowers the risk of human error inherent in manual configurations. It treats policy management like software development, bringing rigor and repeatability to security operations, thereby reducing the manual, repetitive work known as toil.

B. Relying on manual audits and inspections for security policy enforcement.

This is a reactive, not preventative, approach. It is labor-intensive (high toil) and prone to human error, failing to ensure consistent enforcement.

C. Manually configuring security controls for each individual resource, regularly.

This method is not scalable, is highly susceptible to human error, and leads to configuration drift, directly contradicting the goal of consistency.

D. Implementing security policies through manual scripting on an ad-hoc basis.

"Ad-hoc" implies a lack of a systematic, version-controlled process, leading to inconsistent application and a higher probability of misconfiguration than a formal "as-code" framework.

1. Kubernetes Official Documentation

"Declarative Management of Kubernetes Objects Using Configuration Files." This document outlines the advantages of the declarative approach

stating

"The declarative approach is supported by kubectl apply... The written configuration is maintained in a source control system... This allows for more robust change management." This principle of robust

version-controlled management directly applies to security policies.

Source: Kubernetes Documentation > Concepts > Overview > Working with Kubernetes Objects > Declarative Management.

2. Open Policy Agent (OPA) Official Documentation

"Introduction." OPA is a CNCF graduated project for policy enforcement in cloud-native environments. The documentation states

"OPA uses a high-level declarative language called Rego to codify policies... By decoupling policy from service code

you can release

analyze

and review policies (which are written as code) independently." This highlights the "policy-as-code" benefit of consistency and reduced operational burden.

Source: OPA Documentation > Introduction > What is OPA?

3. University of Virginia

CS 6501: Cloud Computing Courseware

"Lecture 03: Cloud Infrastructure & IaC." The course materials explain the principles of Infrastructure as Code (IaC)

the parent concept of Policy-as-Code. It emphasizes that declarative IaC models "reduce the risk of manual errors and ensure consistency."

Source: University of Virginia

Department of Computer Science

CS 6501: Cloud Computing

Lecture 03 slides on Infrastructure as Code.

The MITRE ATT&CK® framework is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. Its specific purpose is to categorize and describe the actions an attacker might take within a network, which are commonly referred to as Tactics, Techniques, and Procedures (TTPs). This model is unique among the options as it is structured entirely from the adversary's (offensive) perspective to help defenders understand and counter specific threats. The other frameworks focus on defensive controls, risk management, or vulnerability awareness rather than offensive procedures.

B. OWASP Top 10: This is a standard awareness document focusing on the most critical security risks to web applications, not a comprehensive knowledge base of offensive TTPs.

C. CIS Controls: This is a prescriptive, prioritized set of defensive cybersecurity best practices and safeguards that organizations can implement to improve their security posture.

D. NIST Cybersecurity Framework: This provides a high-level policy framework of standards and guidelines to help organizations manage cybersecurity risk; it is fundamentally a defensive and risk management tool.

1. MITRE. (2023). About ATT&CK. The MITRE Corporation. Retrieved from https://attack.mitre.org/about/. The homepage and "About" section state

"MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations."

2. NIST. (2018). Framework for Improving Critical Infrastructure Cybersecurity

Version 1.1. National Institute of Standards and Technology. p. 1

Section 1.1. DOI: https://doi.org/10.6028/NIST.CSWP.04162018. The document introduces the framework as a tool for "managing cybersecurity risk."

3. Center for Internet Security (CIS). (2023). CIS Critical Security Controls. Retrieved from https://www.cisecurity.org/controls/. The introduction describes the controls as "a prioritized set of Safeguards to mitigate the most prevalent cyber-attacks."

4. OWASP Foundation. (2021). OWASP Top 10 - 2021. Retrieved from https://owasp.org/Top10/. The introduction states

"The OWASP Top 10 is a standard awareness document for developers and web application security."

The Kubernetes project has officially migrated its container image registry from k8s.gcr.io to registry.k8s.io. As of April 3, 2023, the k8s.gcr.io registry was frozen, meaning no new images or updates are published to it. Consequently, any attempt to pull image versions released after this date from the old k8s.gcr.io address will fail because they do not exist there. The cluster must be updated to pull images from the new registry.k8s.io endpoint to access the latest versions.

A. A network issue would likely cause all image pulls from the registry to fail, not just those for more recent versions.

B. While a bug is possible, the announced and implemented deprecation of the registry is a far more direct and certain cause for this specific issue.

C. Images on k8s.gcr.io are public, and pulling them does not typically require authentication credentials, making this an unlikely cause.

1. Kubernetes Blog. (2023

March 20). k8s.gcr.io Redirect to registry.k8s.io - What You Need to Know. Kubernetes.io. Retrieved from https://kubernetes.io/blog/2023/03/10/image-registry-redirect/. In the "What is changing?" section

it states

"On Monday

April 3

2023

we will redirect traffic from k8s.gcr.io to registry.k8s.io."

2. Kubernetes Documentation. Registry k8s.io: replacing k8s.gcr.io. Retrieved from https://kubernetes.io/docs/reference/k8s-api/workload-resources/pod-v1/#registry-k8s-io. The documentation explicitly states

"The Kubernetes project runs a container image registry at registry.k8s.io to host the container images it manages. This replaces the legacy registry

k8s.gcr.io."

3. Kubernetes Blog. (2022

November 28). k8s.gcr.io is going away

what you need to know. Kubernetes.io. Retrieved from https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/. The "Timeline" section details the plan to freeze the k8s.gcr.io registry in April 2023.

A RoleBinding must list the subject (bob) in the subjects array with exactly

kind: User, name: bob, apiGroup: rbac.authorization.k8s.io, and must point to the existing Role by setting roleRef.kind: Role, roleRef.name: pod-reader, roleRef.apiGroup: rbac.authorization.k8s.io.

Option B is the only snippet that contains all these mandatory, case-sensitive fields and values, thereby correctly binding user bob to the Role pod-reader in the namespace.

Option A – subjects.kind is ServiceAccount, not User; therefore does not bind the user bob.

Option C – roleRef.kind is ClusterRole; binds to a ClusterRole, not the namespace-scoped Role requested.

Option D – apiGroup is omitted in subjects/roleRef; absent apiGroup defaults are not allowed, rendering the binding invalid.

1. Kubernetes Documentation

“RBAC › RoleBinding and ClusterRoleBinding

” examples 1–3

lines showing “kind: User … roleRef: kind: Role”

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding

2. Kubernetes API Reference v1.29

rbac.authorization.k8s.io/v1 RoleBinding schema

fields subjects[] and roleRef

Section “Required Fields”

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#rolebinding-v1-rbac-authorization-k8s-io

3. The Linux Foundation (LFD459) “Kubernetes Security Fundamentals

” Chapter 3

Slide 27

“Binding a User to a Role” (shows identical YAML).

Implementing Pod Security Standards (PSS) is a critical action for minimizing security issues in Kubernetes. This is achieved by defining security policies within the Pod's YAML configuration, specifically using the securityContext field. This allows administrators to enforce the principle of least privilege by restricting a Pod's capabilities, such as preventing it from running as the root user (runAsNonRoot: true), disallowing privilege escalation (allowPrivilegeEscalation: false), and applying specific seccomp or AppArmor profiles. These controls directly harden the Pod's runtime environment, reducing its attack surface and mitigating potential vulnerabilities.

A. Sharing sensitive data broadly increases the risk of exposure and violates the principle of need-to-know, directly contradicting security best practices.

B. Running Pods with elevated privileges is a major security anti-pattern that breaks container isolation and can lead to host compromise.

D. Obfuscating Pod names through randomization is not a security control; an attacker with cluster access can easily list and identify all Pods.

1. Kubernetes Documentation

"Pod Security Standards": This document outlines the three standard policies (Privileged

Baseline

and Restricted) designed to cover a broad spectrum of security requirements. The 'Restricted' policy

for example

enforces current Pod hardening best practices. (Source: kubernetes.io/docs/concepts/security/pod-security-standards/)

2. Kubernetes Documentation

"Configure a Security Context for a Pod or Container": This guide provides specific examples of how to use the securityContext field in a Pod's specification to set security parameters like runAsUser

runAsNonRoot

and allowPrivilegeEscalation. (Source: kubernetes.io/docs/tasks/configure-pod-container/security-context/

Section: "Set the security context for a Pod")

3. The Linux Foundation

"Introduction to Kubernetes (LFS158x)" Courseware: This official course

often used as a basis for KCSA

emphasizes the principle of least privilege. Module 11

"Security

" discusses using Security Contexts to limit container permissions as a fundamental security measure. (Source: edX

LFS158x

Module 11: Security)