Free Sample Questions to Practice KCSA Certification Test Engine [Jun-2026]
2026 Valid KCSA Real Exam Questions, practice Kubernetes and Cloud Native
NEW QUESTION # 17
How can a user enforce thePod Security Standardwithout third-party tools?
- A. It is only possible to enforce the Pod Security Standard with additional tools within the cloud native ecosystem.
- B. No additional measures have to be taken to enforce the Pod Security Standard.
- C. Through implementing Kyverno or OPA Policies.
- D. Use the PodSecurity admission controller.
Answer: D
Explanation:
* ThePodSecurity admission controller(built-in as of Kubernetes v1.23+) enforces the Pod Security Standards (Privileged, Baseline, Restricted).
* Enforcement is namespace-scoped and configured throughnamespace labels.
* Incorrect options:
* (A) Kyverno/OPA are external policy tools (useful but not required).
* (C) Not true, PodSecurity admission provides native enforcement.
* (D) Enforcement requires explicit configuration, not automatic.
References:
Kubernetes Documentation - Pod Security Admission
CNCF Security Whitepaper - Policy enforcement and admission control.
NEW QUESTION # 18
What is the reasoning behind considering the Cloud as the trusted computing base of a Kubernetes cluster?
- A. A Kubernetes cluster can only be trusted if the underlying Cloud provider is certified against international standards.
- B. The Cloud enforces security controls at the Kubernetes cluster level, so application developers can focus on applications only.
- C. A vulnerability in the Cloud layer has a negligible impact on containers due to Linux isolation mechanisms.
- D. A Kubernetes cluster can only be as secure as the security posture of its Cloud hosting.
Answer: D
Explanation:
* The4C's of Cloud Native Security(Cloud, Cluster, Container, Code) model starts withCloudas the base layer.
* If the Cloud (infrastructure layer) is compromised, every higher layer (Cluster, Container, Code) inherits that compromise.
* Exact extract (Kubernetes Security Overview):
* "The 4C's of Cloud Native security are Cloud, Clusters, Containers, and Code. You can think of the 4C's as a layered approach. A Kubernetes cluster can only be as secure as the cloud infrastructure it is deployed on."
* This means the cloud is part of thetrusted computing baseof a Kubernetes cluster.
References:
Kubernetes Docs - Security Overview (4C's): https://kubernetes.io/docs/concepts/security/overview/#the-
4cs-of-cloud-native-security
NEW QUESTION # 19
Which of the following represents a baseline security measure for containers?
- A. Configuring persistent storage for containers.
- B. Configuring a static IP for each container.
- C. Implementing access control to restrict container access.
- D. Run containers as the root user.
Answer: C
Explanation:
* Access control (RBAC, least privilege, user restrictions)is abaseline container security best practice.
* Exact extract (Kubernetes Pod Security Standards - Baseline):
* "The baseline profile is designed to prevent known privilege escalations. It prohibits running privileged containers or containers as root."
* Other options clarified:
* B: Static IPs not a security measure.
* C: Persistent storage is functionality, not security.
* D: Running as root is explicitlyinsecure.
References:
Kubernetes Docs - Pod Security Standards (Baseline): https://kubernetes.io/docs/concepts/security/pod- security-standards/
NEW QUESTION # 20
What is the main reason an organization would use a Cloud Workload Protection Platform (CWPP) solution?
- A. To manage networking between containerized workloads in the Kubernetes cluster.
- B. To optimize resource utilization and scalability of containerized workloads.
- C. To protect containerized workloads from known vulnerabilities and malware threats.
- D. To automate the deployment and management of containerized workloads.
Answer: C
Explanation:
* CWPP (Cloud Workload Protection Platform):As defined by Gartner and adopted across cloud security practices, CWPPs are designed tosecure workloads(VMs, containers, serverless functions) in hybrid and cloud environments.
* They providevulnerability scanning, runtime protection, compliance checks, and malware detection.
* Exact extract (Gartner CWPP definition):"Cloud workload protection platforms protect workloads regardless of location, including physical machines, VMs, containers, and serverless workloads. They provide vulnerability management, system integrity protection, intrusion detection and prevention, and malware protection." References:
Gartner: Cloud Workload Protection Platforms Market Guide (summary): https://www.gartner.com/reviews
/market/cloud-workload-protection-platforms
CNCF Security Whitepaper:https://github.com/cncf/tag-security
NEW QUESTION # 21
Which of the following statements on static Pods is true?
- A. The kubelet only deploys static Pods when the kube-scheduler is unresponsive.
- B. The kubelet schedules static Pods local to its node without going through the kube-scheduler, making tracking and managing them difficult.
- C. The kubelet can run a maximum of 5 static Pods on each node.
- D. The kubelet can run static Pods that span multiple nodes, provided that it has the necessary privileges from the API server.
Answer: B
Explanation:
* Static Podsare managed directly by thekubeleton each node.
* They arenot scheduled by the kube-schedulerand always remain bound to the node where they are defined.
* Exact extract (Kubernetes Docs - Static Pods):
* "Static Pods are managed directly by the kubelet daemon on a specific node, without the API server. They do not go through the Kubernetes scheduler."
* Clarifications:
* A: Static Pods do not span multiple nodes.
* B: No hard limit of 5 Pods per node.
* D: They are not a fallback mechanism; kubelet always manages them regardless of scheduler state.
References:
Kubernetes Docs - Static Pods: https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/
NEW QUESTION # 22
What information is stored in etcd?
- A. Pod data contained in Persistent Volume Claims (e.g. hostPath).
- B. Application logs and monitoring data for auditing and troubleshooting purposes.
- C. Sensitive user data such as usernames and passwords.
- D. Etcd manages the configuration data, state data, and metadata for Kubernetes.
Answer: D
Explanation:
* etcdis Kubernetes'key-value storeforcluster state.
* Stores: ConfigMaps, Secrets, Pod definitions, Deployments, RBAC policies, and metadata.
* Exact extract (Kubernetes Docs - etcd):
* "etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data."
* Clarifications:
* B: Logs/metrics are handled by logging/monitoring solutions, not etcd.
* C: Secrets may be stored here but encoded in base64, not specifically "usernames/passwords" as primary use.
* D: Persistent Volumes are external storage, not stored in etcd.
References:
Kubernetes Docs - etcd: https://kubernetes.io/docs/concepts/overview/components/#etcd
NEW QUESTION # 23
By default, in a Kubeadm cluster, which authentication methods are enabled?
- A. OIDC, Bootstrap tokens, and Service Account Tokens
- B. X509 Client Certs, Bootstrap Tokens, and Service Account Tokens
- C. X509 Client Certs, Webhook Authentication, and Service Account Tokens
- D. X509 Client Certs, OIDC, and Service Account Tokens
Answer: B
Explanation:
* In akubeadm cluster, by default the API server enables several authentication mechanisms:
* X509 Client Certs: Used for authenticating kubelets, admins, and control-plane components.
* Bootstrap Tokens: Temporary credentials used for node bootstrap/joining clusters.
* Service Account Tokens: Used by workloads in pods to authenticate with the API server.
* Exact extract (Kubernetes Docs - Authentication):
* "Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests."
* "Bootstrap tokens are a simple bearer token that is meant to be used when creating new clusters or joining new nodes to an existing cluster."
* "Service accounts are special accounts that provide an identity for processes that run in a Pod." References:
Kubernetes Docs - Authentication: https://kubernetes.io/docs/reference/access-authn-authz/authentication/ Kubeadm - TLS Bootstrapping: https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/
NEW QUESTION # 24
Which standard approach to security is augmented by the 4C's of Cloud Native security?
- A. Defense-in-Depth
- B. Secure-by-Design
- C. Zero Trust
- D. Least Privilege
Answer: A
Explanation:
* The 4C's model (Cloud, Cluster, Container, Code) is presented in the official Kubernetes documentation as alayeredmodel that explicitly maps todefense-in-depth.
* Exact extracts from Kubernetes docs(security overview):
* "The 4C's of Cloud Native Security are Cloud, Clusters, Containers, and Code."
* "You can think of the 4C's asa layered approach to security; applying security measures at each layer reduces risk."
* "This layered approach is commonly known asdefense in depth."
References:
Kubernetes Docs - Security overview #The 4C's of Cloud Native Security: https://kubernetes.io/docs
/concepts/security/overview/#the-4cs-of-cloud-native-security
NEW QUESTION # 25
What is the difference between gVisor and Firecracker?
- A. gVisor and Firecracker are both container runtimes that can be used interchangeably.
- B. gVisor is a user-space kernel that provides isolation and security for containers. At the same time, Firecracker is a lightweight virtualization technology for creating and managing secure, multi-tenant container and function-as-a-service (FaaS) workloads.
- C. gVisor and Firecracker are two names for the same technology, which provides isolation and security for containers.
- D. gVisor is a lightweight virtualization technology for creating and managing secure, multi-tenant container and function-as-a-service (FaaS) workloads. At the same time, Firecracker is a user-space kernel that provides isolation and security for containers.
Answer: B
Explanation:
* gVisor:
* Google-developed, implemented as auser-space kernelthat intercepts and emulates syscalls made by containers.
* Providesstrong isolationwithout requiring a full VM.
* Official docs: "gVisor is a user-space kernel, written in Go, that implements a substantial portion of the Linux system call interface."
* Source: https://gvisor.dev/docs/
* Firecracker:
* AWS-developed,lightweight virtualization technologybuilt on KVM, used in AWS Lambda and Fargate.
* Optimized for running secure, multi-tenant microVMs (MicroVMs) for containers and FaaS.
* Official docs: "Firecracker is an open-source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services."
* Source: https://firecracker-microvm.github.io/
* Key difference:gVisor # syscall interception in userspace kernel (container isolation). Firecracker # lightweight virtualization with microVMs (multi-tenant security).
* Therefore, optionAis correct.
References:
gVisor Docs: https://gvisor.dev/docs/
Firecracker Docs: https://firecracker-microvm.github.io/
NEW QUESTION # 26
Which technology can be used to apply security policy for internal cluster traffic at the application layer of the network?
- A. Container Runtime
- B. Network Policy
- C. Service Mesh
- D. Ingress Controller
Answer: C
Explanation:
* Service Mesh (e.g., Istio, Linkerd, Consul):operates atLayer 7 (application layer), enforcing policies like mTLS, authorization, and routing between services.
* NetworkPolicy:works atLayer 3/4 (IP/port), not Layer 7.
* Ingress Controller:handles external traffic ingress, not internal service-to-service traffic.
* Container Runtime:responsible for running containers, not enforcing application-layer security.
Exact extract (Istio docs):
* "Istio provides security by enforcing authentication, authorization, and encryption of service-to- service communication." References:
Kubernetes Docs - Network Policies: https://kubernetes.io/docs/concepts/services-networking/network- policies/ Istio Security Docs: https://istio.io/latest/docs/concepts/security/
NEW QUESTION # 27
What kind of organization would need to be compliant with PCI DSS?
- A. Merchants that process credit card payments.
- B. Non-profit organizations that handle sensitive customer data.
- C. Retail stores that only accept cash payments.
- D. Government agencies that collect personally identifiable information.
Answer: A
Explanation:
* PCI DSS (Payment Card Industry Data Security Standard):applies to any entity thatstores, processes, or transmits cardholder data.
* Exact extract (PCI DSS official summary):
* "PCI DSS applies to all entities that store, process or transmit cardholder data (CHD) and
/or sensitive authentication data (SAD)."
* Therefore,merchants who process credit card paymentsmust comply.
* Why others are wrong:
* A: No card payments, so no PCI scope.
* B: This falls underFISMA / NIST 800-53, not PCI DSS.
* C: Non-profits may handle sensitive data, but PCI only applies if they processcredit cards.
References:
PCI Security Standards Council - PCI DSS Summary: https://www.pcisecuritystandards.org/pci_security/
NEW QUESTION # 28
Given a standard Kubernetes cluster architecture comprising a single control plane node (hosting bothetcdand the control plane as Pods) and three worker nodes, which of the following data flows crosses atrust boundary
?
- A. From API Server to Container Runtime
- B. From kubelet to API Server
- C. From kubelet to Controller Manager
- D. From kubelet to Container Runtime
Answer: B
Explanation:
* Trust boundariesexist where data flows between different security domains.
* In Kubernetes:
* Communication between thekubelet (node agent)and theAPI Server (control plane)crosses the node-to-control-plane trust boundary.
* (A) Kubelet to container runtime is local, no boundary crossing.
* (C) Kubelet does not communicate directly with the controller manager.
* (D) API server does not talk directly to the container runtime; it delegates to kubelet.
* Therefore, (B) is the correct trust boundary crossing flow.
References:
CNCF Security Whitepaper - Kubernetes Threat Model: identifies node-to-control-plane communications (kubelet # API Server) as crossing trust boundaries.
Kubernetes Documentation - Cluster Architecture
NEW QUESTION # 29
Which of the following statements regarding a container run with privileged: true is correct?
- A. A container run with privileged: true within a Namespace can access all Secrets used within that Namespace.
- B. A container run with privileged: true has no additional access to Secrets than if it were run with privileged: false.
- C. A container run with privileged: true on a node can access all Secrets used on that node.
- D. A container run with privileged: true within a cluster can access all Secrets used within that cluster.
Answer: B
Explanation:
* Setting privileged: true grants a containerelevated access to the host node, including access to host devices, kernel capabilities, and the ability to modify the host.
* However, Secrets in Kubernetes are not automatically exposedto privileged containers. Secrets are mounted into Pods only if explicitly referenced.
* Thus, being privilegeddoes not grant additional access to Kubernetes Secretscompared to a non- privileged Pod.
* The risk lies in node compromise: if a privileged container can take over the node, it could then indirectly gain access to Secrets (e.g., by reading kubelet credentials).
References:
Kubernetes Documentation - Security Context
CNCF Security Whitepaper - Pod security context and privileged container risks.
NEW QUESTION # 30
When should soft multitenancy be used over hard multitenancy?
- A. When the priority is enabling fine-grained control over tenant resources.
- B. When the priority is enabling strict security boundaries between tenants.
- C. When the priority is enabling resource sharing and efficiency between tenants.
- D. When the priority is enabling complete isolation between tenants.
Answer: C
Explanation:
* Soft multitenancy(Namespaces, RBAC, Network Policies) # assumes some level of trust between tenants, focuses onresource sharing and efficiency.
* Hard multitenancy(separate clusters or strong virtualization) # strict isolation, used when tenants are untrusted.
* Exact extract (CNCF TAG Security Multi-Tenancy Whitepaper):
* "Soft multi-tenancy refers to multiple workloads running in the same cluster with some trust assumptions. It provides resource sharing and operational efficiency. Hard multi- tenancy requires stronger isolation guarantees, typically separate clusters." References:
CNCF Security TAG - Multi-Tenancy Whitepaper:https://github.com/cncf/tag-security/tree/main/multi- tenancy
NEW QUESTION # 31
Which of the following statements best describe container image signing and verification in the cloud environment?
- A. Container image signatures affect the performance of containerized applications, as they increase the size of images with additional metadata.
- B. Container image signatures and their verification ensure their authenticity and integrity against tampering.
- C. Container image signatures are mandatory in cloud environments, as cloud providers would deny the execution of unsigned container images.
- D. Container image signatures are concerned with defining developer ownership of applications within multi-tenant environments.
Answer: B
Explanation:
* Image signing (withNotary, cosign, or similar tools) ensures that images are from a trusted source and have not been modified.
* Exact extract (Sigstore cosign docs):"Cosign allows you to sign and verify container images to ensure authenticity and integrity."
* Why others are wrong:
* B:Ownership can be inferred but it's aboutauthenticity & integritynot tenancy.
* C:Not mandatory; enforcement requiresadmission controllers.
* D:Metadata size is negligible and has no runtime performance impact.
References:
Sigstore Project: https://docs.sigstore.dev/cosign/overview
CNCF Security Whitepaper
NEW QUESTION # 32
Which step would give an attacker a foothold in a cluster butno long-term persistence?
- A. Modify Kubernetes objects stored within etcd.
- B. Create restarting container on host using Docker.
- C. Starting a process in a running container.
- D. Modify file on host filesystem.
Answer: C
Explanation:
* Starting a process in a running containerprovides an attacker withtemporary execution (foothold) inside the cluster, but once the container is stopped or restarted, that malicious process is lost. This means the attacker has nolong-term persistence.
* Incorrect options:
* (A) Modifying objects inetcdgrants persistent access since cluster state is stored in etcd.
* (B) Modifying files on thehost filesystemcan create persistence across reboots or container restarts.
* (D) Creating a restarting container directly on the host via Docker bypasses Kubernetes but persists across pod restarts if Docker restarts it.
References:
CNCF Security Whitepaper - Threat Modeling section: Describes howephemeral processes inside containersprovide attackers short-term control but not durable persistence.
Kubernetes Documentation - Cluster Threat Model emphasizes ephemeral vs. persistent attacker footholds.
NEW QUESTION # 33
What is Grafana?
- A. A cloud-native security tool for scanning and detecting vulnerabilities in Kubernetes clusters.
- B. A platform for monitoring and visualizing time-series data.
- C. A cloud-native distributed tracing system for monitoring microservices architectures.
- D. A container orchestration platform for managing and scaling applications.
Answer: B
Explanation:
* Grafana:An open-source analytics and visualization platform widely used with Prometheus, Loki, etc.
* Exact extract (Grafana Docs):"Grafana is the open-source analytics and monitoring solution for every database. It allows you to query, visualize, alert on, and understand your metrics no matter where they are stored."
* A is wrong:That describesJaeger(distributed tracing).
* B is wrong:That'sKubernetesitself.
* D is wrong:That'sTrivy/Aqua/Prismatype tools.
References:
Grafana Docs: https://grafana.com/docs/grafana/latest/
NEW QUESTION # 34
Which of the following statements correctly describes a container breakout?
- A. A container breakout is the process of escaping the container and gaining access to the host operating system.
- B. A container breakout is the process of escaping the container and gaining access to the Pod's network traffic.
- C. A container breakout is the process of escaping the container and gaining access to the cloud provider's infrastructure.
- D. A container breakout is the process of escaping a container when it reaches its resource limits.
Answer: A
Explanation:
* Container breakoutrefers to an attacker escaping container isolation and reaching thehost OS.
* Once the host is compromised, the attacker can accessother containers, Kubernetes nodes, or escalate further.
* Exact extract (Kubernetes Security Docs):
* "If an attacker gains access to a container, they may attempt a container breakout to gain access to the host system."
* Other options clarified:
* A: Network access inside a Pod # breakout.
* B: Resource exhaustion is aDoS, not a breakout.
* C: Cloud infrastructure compromise is possibleafterhost compromise, but not the definition of breakout.
References:
Kubernetes Security Concepts: https://kubernetes.io/docs/concepts/security/ CNCF Security Whitepaper (Threats section):https://github.com/cncf/tag-security
NEW QUESTION # 35
In a Kubernetes cluster, what are the security risks associated with using ConfigMaps for storing secrets?
- A. ConfigMaps store sensitive information in etcd encoded in base64 format automatically, which does not ensure confidentiality of data.
- B. Using ConfigMaps for storing secrets might make applications incompatible with the Kubernetes cluster.
- C. Storing secrets in ConfigMaps can expose sensitive information as they are stored in plaintext and can be accessed by unauthorized users.
- D. Storing secrets in ConfigMaps does not allow for fine-grained access control via RBAC.
Answer: C
Explanation:
* ConfigMaps are explicitly not for confidential data.
* Exact extract (ConfigMap concept):"A ConfigMap is an API object used to store non- confidential data in key-value pairs."
* Exact extract (ConfigMap concept):"ConfigMaps are not intended to hold confidential data. Use a Secret for confidential data."
* Why this is risky:data placed into a ConfigMap is stored as regular (plaintext) string values in the API and etcd (unless you deliberately use binaryData for base64 content you supply). That means if someone has read access to the namespace or to etcd/APIServer storage, they can view the values.
* Secrets vs ConfigMaps (to clarify distractor D):
* Exact extract (Secret concept):"By default, secret data is stored as unencrypted base64- encoded strings.You canenable encryption at restto protect Secrets stored in etcd."
* This base64 behavior applies toSecrets, not to ConfigMap data. Thus optionDis incorrect for ConfigMaps.
* About RBAC (to clarify distractor A):Kubernetesdoessupport fine-grained RBAC forboth ConfigMaps and Secrets; the issue isn't lack of RBAC but that ConfigMaps arenotdesigned for confidential material.
* About compatibility (to clarify distractor C):Using ConfigMaps for secrets doesn't make apps
"incompatible"; it's simplyinsecureand against guidance.
References:
Kubernetes Docs -ConfigMaps: https://kubernetes.io/docs/concepts/configuration/configmap/ Kubernetes Docs -Secrets: https://kubernetes.io/docs/concepts/configuration/secret/ Kubernetes Docs -Encrypting Secret Data at Rest: https://kubernetes.io/docs/tasks/administer-cluster
/encrypt-data/
Note: The citations above are from the official Kubernetes documentation and reflect the stated guidance that ConfigMaps are fornon-confidentialdata, while Secrets (with encryption at rest enabled) are forconfidential data, and that the 4C's map todefense in depth.
NEW QUESTION # 36
A cluster is failing to pull more recent versions of images from k8s.gcr.io. Why may this be?
- A. There is a bug in the container runtime or the image pull process.
- B. There is a network connectivity issue between the cluster and k8s.gcr.io.
- C. The container image registry k8s.gcr.io has been deprecated.
- D. The authentication credentials for accessing k8s.gcr.io are incorrectly scoped.
Answer: C
Explanation:
* k8s.gcr.iowas the historic Kubernetes image registry.
* It has beendeprecatedand replaced withregistry.k8s.io.
* Exact extract (Kubernetes Blog):
* "The k8s.gcr.io image registry will be frozen from April 3, 2023 and fully deprecated. All Kubernetes project images are now served from registry.k8s.io."
* Pulling newer versions from k8s.gcr.io fails because the registry no longer receives updates.
References:
Kubernetes Blog - Image Registry Update: https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze- announcement/
NEW QUESTION # 37
You are responsible for securing thekubeletcomponent in a Kubernetes cluster.
Which of the following statements about kubelet security is correct?
- A. Kubelet supports TLS authentication and encryption for secure communication with the API server.
- B. Kubelet runs as a privileged container by default.
- C. Kubelet requires root access to interact with the host system.
- D. Kubelet does not have any built-in security features.
Answer: A
Explanation:
* Thekubeletis the primary agent that runs on each node in a Kubernetes cluster and communicates with the control plane.
* Kubeletsupports TLS (Transport Layer Security)for both authentication and encryption when interacting with the API server. This is a core security feature that ensures secure node-to-control-plane communication.
* Incorrect options:
* (A) Kubelet does not run as a privileged container by default; it runs as a system process (typically systemd-managed) on the host.
* (B) Kubelet does include built-in security features such asTLS authentication, authorization modes, and read-only vs secured ports.
* (D) While kubelet interacts with the host system (e.g., cgroups, container runtimes), it does not inherently require root access for communication security; RBAC and TLS handle authentication.
References:
Kubernetes Documentation - Kubelet authentication/authorization
CNCF Security Whitepaper - Cluster Component Security (discusses TLS and mutual authentication between kubelet and API server).
NEW QUESTION # 38
What is a multi-stage build?
- A. A build process that involves multiple developers collaborating on building an image.
- B. A build process that involves multiple containers running simultaneously to speed up the image creation.
- C. A build process that involves multiple repositories for storing container images.
- D. A build process that involves multiple stages of image creation, allowing for smaller, optimized images.
Answer: D
Explanation:
* Multi-stage buildsare a Docker/Kaniko feature that allows building images in multiple stages # final image contains only runtime artifacts, not build tools.
* This reducesimage size, attack surface, and security risks.
* Exact extract (Docker Docs):
* "Multi-stage builds allow you to use multiple FROM statements in a Dockerfile. You can copy artifacts from one stage to another, resulting in smaller, optimized images."
* Clarifications:
* A: Collaboration is not the definition.
* B: Multiple repositories # multi-stage builds.
* C: Build concurrency # multi-stage builds.
References:
Docker Docs - Multi-Stage Builds: https://docs.docker.com/develop/develop-images/multistage-build/
NEW QUESTION # 39
In a cluster that contains Nodes withmultiple container runtimesinstalled, how can a Pod be configured to be created on a specific runtime?
- A. By setting the container runtime as an environment variable in the Pod.
- B. By specifying the container runtime in the Pod's YAML file.
- C. By using a command-line flag when creating the Pod.
- D. By modifying the Docker daemon configuration.
Answer: B
Explanation:
* Kubernetes supportsmultiple container runtimeson a node via theRuntimeClassresource.
* To select a runtime, you specify the runtimeClassName field in thePod's YAML manifest. Example:
* apiVersion: v1
* kind: Pod
* metadata:
* name: example
* spec:
* runtimeClassName: gvisor
* containers:
* - name: app
* image: nginx
* Incorrect options:
* (A) You cannot specify container runtime through a kubectl command-line flag.
* (B) Modifying the Docker daemon config does not direct Kubernetes Pods to a runtime.
* (C) Environment variables inside a Pod spec do not control container runtimes.
References:
Kubernetes Documentation - RuntimeClass
CNCF Security Whitepaper - Workload isolation via different runtimes (e.g., gVisor, Kata) for enhanced security.
NEW QUESTION # 40
Which of the following statements best describes the role of the Scheduler in Kubernetes?
- A. The Scheduler is responsible for assigning Pods to nodes based on resource availability and other constraints.
- B. The Scheduler is responsible for ensuring the security of the Kubernetes cluster and its components.
- C. The Scheduler is responsible for managing the deployment and scaling of applications in the Kubernetes cluster.
- D. The Scheduler is responsible for monitoring and managing the health of the Kubernetes cluster.
Answer: A
Explanation:
* TheKubernetes Schedulerassigns Pods to nodes based on:
* Resource requests & availability (CPU, memory, GPU, etc.)
* Constraints (affinity, taints, tolerations, topology, policies)
* Exact extract (Kubernetes Docs - Scheduler):
* "The scheduler is a control plane process that assigns Pods to Nodes. Scheduling decisions take into account resource requirements, affinity/anti-affinity, constraints, and policies."
* Other options clarified:
* A: Monitoring cluster health is theController Manager's/kubelet's job.
* B: Security is enforced throughRBAC, admission controllers, PSP/PSA, not the scheduler.
* C: Deployment scaling is handled by theController Manager(Deployment/ReplicaSet controller).
References:
Kubernetes Docs - Scheduler: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
NEW QUESTION # 41
......
Genuine KCSA Exam Dumps Free Demo Valid QA's: https://www.validvce.com/KCSA-exam-collection.html
Latest Success Metrics For Actual KCSA Exam (Updated 62 Questions): https://drive.google.com/open?id=1DnsQKrcOrlhNKTPJtMT1_GNYf19vV3CA
