CCNA Minimize Microservice Vulnerabilities Questions — Page 2 of 3

MCQhard

You are deploying a ValidatingWebhookConfiguration. The webhook server is running in the 'webhook' namespace, service name 'svc', port 443. Which clientConfig should you specify?

A.clientConfig: service: namespace: webhook name: svc path: /validate

B.clientConfig: url: https://webhook.svc.cluster.local:443/validate

C.clientConfig: service: namespace: webhook name: webhook path: /validate

D.clientConfig: service: namespace: default name: svc path: /validate

AnswerA

Correctly specifies the service reference.

Why this answer

The clientConfig for a service-based webhook must reference the namespace, service name, and path. Option A uses the service reference correctly.

Practice this question →

MCQeasy

Which kubectl command creates a valid webhook configuration that validates pods against a policy?

A.kubectl apply -f webhookconfiguration.yaml

B.kubectl apply -f podpreset.yaml

C.kubectl apply -f mutatingwebhookconfiguration.yaml

D.kubectl apply -f validatingwebhookconfiguration.yaml

AnswerD

ValidatingWebhookConfiguration is the correct resource for validation webhooks.

Why this answer

ValidatingWebhookConfiguration is the correct resource for admission webhooks that validate requests. PodPreset is deprecated, and other options are not valid resources.

Practice this question →

Multi-Selecthard

Which THREE of the following are required to configure encryption of secrets at rest in Kubernetes?

Select 3 answers

A.Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration

B.An EncryptionConfiguration YAML file defining encryption providers and resources to encrypt

C.Running `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` to rewrite existing secrets

D.Passing the `--encryption-provider-config` flag to the kube-apiserver

E.Modifying the etcd configuration to enable encryption at rest

AnswersA, B, D

The provider defines the encryption algorithm and keys.

Why this answer

Options A, C, and D are required. A: An EncryptionConfiguration YAML file is needed. C: The kube-apiserver must be started with the `--encryption-provider-config` flag pointing to that file.

D: The encryption provider must be specified (e.g., `aescbc`, `secretbox`). Option B is not required because the etcd cluster itself does not need modification for Kubernetes encryption; it just stores encrypted data. Option E is not required because rewriting secrets after encryption is optional; the encryption applies to new writes automatically.

Practice this question →

MCQeasy

Which command creates a ResourceQuota in the 'team-a' namespace?

A.kubectl expose quota --namespace=team-a

B.kubectl apply -f quota.yaml --namespace=team-a

C.kubectl create quota team-a-quota --namespace=team-a

D.kubectl run quota --namespace=team-a --image=quota

AnswerC

The 'kubectl create quota' command creates a ResourceQuota object in the specified namespace.

Why this answer

kubectl create quota is the imperative command to create a ResourceQuota. It requires a name and optionally the --namespace flag.

Practice this question →

MCQmedium

You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?

A.PeerAuthentication

B.ServiceEntry

C.VirtualService

D.DestinationRule

AnswerA

Correct. PeerAuthentication specifies mTLS mode (STRICT, PERMISSIVE, etc.) for workloads.

Why this answer

PeerAuthentication defines the mTLS mode for workloads within a namespace.

Practice this question →

MCQhard

A pod is failing with 'CrashLoopBackOff'. The pod's securityContext includes 'allowPrivilegeEscalation: false'. The container image is built with a default user of root and attempts to change capabilities. What is the most likely cause of the crash?

A.The container is trying to write to a read-only filesystem

B.The container is trying to set capabilities using setcap

C.The container is missing the NET_ADMIN capability

D.The container is trying to bind to a privileged port (<1024) as non-root

AnswerB

Setting capabilities requires privilege escalation, which is disabled. This will cause the operation to fail and the container to crash.

Why this answer

Option C is correct. With allowPrivilegeEscalation: false, the container cannot gain additional privileges beyond its initial capabilities. If the container tries to set capabilities (e.g., via setcap), it will fail and crash.

Options A and B are possible but less likely given the symptom. Option D is unrelated.

Practice this question →

MCQmedium

You need to use gVisor as a container runtime for a set of workloads in the cluster. Which Kubernetes resource must be created to reference the runtime class?

A.Create a RuntimeClass resource with handler: runsc

B.Set the kubelet runtime flag --runtime-class=gvisor

C.Install a CRD for gVisor

D.Create a Pod with spec.runtimeClassName set to "gvisor"

AnswerA

The RuntimeClass defines the runtime handler (e.g., runsc) that corresponds to gVisor.

Why this answer

A RuntimeClass resource defines a runtime handler (e.g., runsc) and is referenced in a pod's spec.runtimeClassName to select that runtime.

Practice this question →

Multi-Selectmedium

Which TWO of the following are recommended practices for securing container images and runtime?

Select 2 answers

A.Set runAsNonRoot to true in securityContext

B.Run containers as root inside the container for easier management

C.Set readOnlyRootFilesystem to true in securityContext

D.Mount the docker socket inside the container for debugging

E.Use the latest tag for all images

AnswersA, C

Ensures the container runs as a non-root user.

Why this answer

Running as non-root and using a read-only root filesystem are key security best practices. Scanning for vulnerabilities is also important but not listed as an option here. The correct answers are B and D.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to reduce the attack surface of a container? (Select TWO)

Select 2 answers

A.Drop all capabilities with capabilities.drop: ["ALL"]

B.Add the SYS_ADMIN capability

C.Set readOnlyRootFilesystem: true

D.Set runAsUser: 0

E.Set privileged: false

AnswersA, C

Removes all capabilities, minimizing privilege.

Why this answer

Options A and D are correct. Dropping all capabilities removes unnecessary privileges. Setting readOnlyRootFilesystem prevents writes to the root filesystem.

Option B increases attack surface. Option C is not a security feature. Option E is not a field; the correct field is 'runAsNonRoot'.

Practice this question →

MCQmedium

A security admin wants to ensure all pods in a cluster drop ALL Linux capabilities. Which of the following YAML snippets should be added to a PodSecurityPolicy (assuming PSP is enabled) or a pod spec?

A.capabilities: drop: "ALL"

B.capabilities: drop: - "NET_RAW"

C.capabilities: add: ["ALL"]

D.capabilities: drop: ["ALL"]

AnswerD

This drops all capabilities, which is a security best practice.

Why this answer

Option D is correct. `capabilities.drop: ["ALL"]` drops all capabilities. Option A adds capabilities, the opposite. Option B drops some but not all.

Option C is incorrect syntax.

Practice this question →

MCQmedium

You have an existing deployment that uses environment variables for secrets. Which kubectl command can be used to update the deployment to mount secrets as volumes without recreating the pods?

A.kubectl patch deployment <deploy> -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","volumeMounts":[{"name":"secret","mountPath":"/etc/secret"}]}],"volumes":[{"name":"secret","secret":{"secretName":"mysecret"}}]}}}}'

B.kubectl set env deployment <deploy> --from=secret/mysecret

C.kubectl edit deployment <deploy>

D.kubectl set volume deployment/<deploy> --add --name=secret --mount-path=/etc/secret --secret-name=mysecret

AnswerD

This command adds a volume mount from a secret to the deployment.

Why this answer

Option D is correct. 'kubectl set volume' can add a volume and volume mount to existing pods/deployments. Option A is for general resource editing, but does not specifically handle volumes. Option B is not a real command.

Option C edits the deployment YAML, which would trigger a rolling update, but 'kubectl set volume' is more targeted.

Practice this question →

MCQeasy

Which of the following is the best practice for injecting secrets into a pod?

A.Storing secrets in container image layers

B.Using environment variables

C.Using ConfigMap for secrets

D.Injecting via volume mounts

AnswerD

Secrets as files in a volume are more secure; they are not visible in env dump.

Why this answer

Option B is correct. Mounting secrets as volumes is the recommended approach because it avoids exposing secrets in environment variables that may be visible in logs or process listings. Option A is less secure.

Option C is insecure. Option D is not a valid method.

Practice this question →

MCQeasy

Which kubectl command creates a secret named 'mysecret' from a file called 'credentials.json'?

A.kubectl create secret generic mysecret --from-file=credentials.json

B.kubectl apply -f credentials.json

C.kubectl create configmap mysecret --from-file=credentials.json

D.kubectl create secret tls mysecret --cert=credentials.json

AnswerA

The --from-file flag creates a secret from the contents of a file, using the filename as the key.

Practice this question →

Multi-Selecthard

Which THREE of the following practices help protect microservice applications against supply chain attacks? (Choose three.)

Select 3 answers

A.Use images from any public registry for flexibility

B.Use minimal base images (e.g., distroless or scratch) to reduce attack surface

C.Always use the latest tag to get the most recent patches

D.Scan images for vulnerabilities using tools like Trivy or Clair

E.Enable image verification using digital signatures (e.g., Notary or Cosign)

AnswersB, D, E

Smaller images have fewer packages that could contain vulnerabilities.

Why this answer

Option B is correct because using minimal base images like distroless or scratch significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. This aligns with the principle of least functionality, as fewer components mean fewer potential entry points for an attacker to exploit in a supply chain attack.

Exam trap

CNCF often tests the misconception that using the latest tag is a safe practice for getting patches, when in fact it undermines supply chain security by breaking image immutability and reproducibility.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Select 2 answers

A.Mount Kubernetes Secrets as volumes into the pod.

B.Use environment variables from the pod spec referencing Secret keys.

C.Use an external secrets manager like HashiCorp Vault integrated with the pod.

D.Pass secrets as command-line arguments to the container.

E.Store secrets in ConfigMaps with base64 encoded data.

AnswersA, C

Volume mounts are more secure than env vars.

Why this answer

Option A is correct: external secret managers like Vault provide secure secret management. Option D is correct: Kubernetes Secrets mounted as volumes are more secure than environment variables. Option B is not a valid mechanism; Option C is insecure; Option E is not a native Kubernetes secret.

Practice this question →

MCQhard

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

A.PodSecurityPolicy (deprecated)

B.ResourceQuota

C.ValidatingAdmissionPolicy

D.MutatingWebhookConfiguration

AnswerD

A mutating webhook can modify resources during admission, such as adding labels.

Why this answer

MutatingWebhookConfiguration defines a webhook that can mutate (modify) incoming API objects, such as adding labels. Validating webhooks only validate and reject, not modify.

Practice this question →

MCQhard

You are configuring encryption at rest for Kubernetes secrets. After creating an EncryptionConfiguration with aescbc provider, which additional step is required to enable encryption?

A.Restart the kube-apiserver with --encryption-provider-config flag

B.Apply the EncryptionConfiguration as a ConfigMap

C.Restart the kube-scheduler

D.Recreate all secrets in the cluster

AnswerA

The kube-apiserver reads the encryption configuration at startup; a restart is required.

Why this answer

The kube-apiserver must be restarted to reload the encryption configuration, and the --encryption-provider-config flag must point to the configuration file.

Practice this question →

Multi-Selectmedium

Which THREE of the following are features of container sandboxing solutions like gVisor or Kata Containers?

Select 3 answers

A.They are compatible with the OCI runtime specification

B.They improve container performance over native runc

C.They can be used with RuntimeClass to select the sandbox runtime per pod

D.They provide an additional layer of isolation between containers and the host kernel

E.They use the host kernel directly for all system calls

AnswersA, C, D

Both gVisor (runsc) and Kata Containers implement the OCI runtime spec.

Why this answer

Container sandboxing provides an additional isolation layer, supports OCI runtime, and adds a security layer. They do not use host kernel directly (that's typical containers). They do not necessarily improve performance; they often add overhead.

Practice this question →

MCQhard

A pod runs with a service mesh sidecar (Istio). The team wants to enforce mutual TLS (mTLS) for all traffic between services in the 'production' namespace. Which resource should be applied?

A.DestinationRule with trafficPolicy: tls: mode: ISTIO_MUTUAL

B.VirtualService with TLS settings

C.PeerAuthentication with mode: STRICT in the namespace

D.ServiceEntry with mTLS enabled

AnswerC

Correct. PeerAuthentication defines mTLS settings per namespace or workload. Mode STRICT requires mTLS.

Why this answer

A PeerAuthentication resource with mTLS mode set to STRICT enforces mutual TLS for all traffic within the namespace. This is an Istio security policy.

Practice this question →

MCQmedium

You want to enable mutual TLS (mTLS) between services in a namespace using Istio. Which custom resource should you configure to enforce STRICT mTLS for all workloads in the namespace?

A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

B.VirtualService with tls.mode: SIMPLE

C.PeerAuthentication with mtls.mode: STRICT

D.ServiceEntry with resolution: NONE

AnswerC

PeerAuthentication enforces mTLS on inbound traffic; STRICT mode requires mutual TLS.

Why this answer

PeerAuthentication with mTLS mode STRICT enforces that all incoming traffic to the namespace uses mutual TLS. DestinationRule is for traffic policies including TLS settings for the destination, but PeerAuthentication is the correct resource to enforce mTLS mode.

Practice this question →

MCQhard

During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?

A.Use 'privileged' PSS with Warn mode

B.Use 'baseline' PSS with Audit mode

C.Use 'restricted' PSS with Enforce mode

D.Use 'baseline' PSS with Enforce mode

AnswerC

Restricted profile requires non-root and drops all capabilities except net bind service.

Why this answer

The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.

Exam trap

CNCF often tests the misconception that 'baseline' PSS is sufficient for most security needs, but the trap here is that 'baseline' still allows root and default capabilities, which are exactly the vectors exploited in container breakout attacks, making 'restricted' the only adequate choice for this specific risk.

How to eliminate wrong answers

Option A is wrong because 'privileged' PSS is the least restrictive policy, allowing all capabilities and root access, which would not mitigate breakout risks; 'Warn' mode only alerts but does not block non-compliant pods. Option B is wrong because 'baseline' PSS allows some default capabilities and does not enforce dropping all capabilities or preventing root, and 'Audit' mode only logs violations without enforcement. Option D is wrong because while 'baseline' PSS with 'Enforce' mode blocks some obvious misconfigurations, it still permits containers to run as root and retains default capabilities, leaving significant breakout vectors unaddressed.

Practice this question →

MCQmedium

A security best practice is to avoid storing secrets in environment variables. Which is a secure alternative for injecting secrets into a pod?

A.Use the Kubernetes Secret Store CSI driver to mount from external store

B.Store secrets in ConfigMap and reference them in the pod

C.Embed the secret directly in the pod definition YAML

D.Mount the Secret as a volume

AnswerD

Mounting secrets as volumes is a secure practice recommended over environment variables.

Why this answer

Mounting secrets as volumes is more secure than environment variables because it reduces exposure in process listings and other system introspection.

Practice this question →

MCQhard

An OPA/Gatekeeper ConstraintTemplate is defined with the following Rego rule: violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.runAsNonRoot != true msg := "Container must run as non-root" } What happens when a pod is submitted with a container that has runAsNonRoot: true?

A.The pod is admitted but an audit log is generated

B.The pod is admitted

C.The pod is denied with a message

D.The pod is mutated to set runAsNonRoot

AnswerB

The violation rule evaluates to false because the condition runAsNonRoot != true is false, so the pod passes the constraint.

Why this answer

The rule produces a violation only when runAsNonRoot is not true. If it is true, the rule does not fire, and the pod is admitted.

Practice this question →

MCQmedium

An administrator wants to use gVisor to sandbox containers in a Kubernetes cluster. Which resource must be created to enable this?

A.RuntimeClass with handler: runsc

B.DaemonSet to install gVisor on nodes

C.PodSecurityPolicy with gVisor enabled

D.SecurityContext with runtime: gvisor

AnswerA

RuntimeClass allows selecting a container runtime. gVisor's runsc is specified as the handler.

Practice this question →

100

MCQmedium

A team wants to use an external secret manager (HashiCorp Vault) to inject secrets into pods. Which approach is most aligned with Kubernetes best practices?

A.Use a ConfigMap to mount secrets as files

B.Store secrets as environment variables in the pod spec

C.Use kubectl exec to copy secrets into the container at startup

D.Use a mutating webhook that injects a sidecar container to fetch secrets and mount them as volumes

AnswerD

This approach securely injects secrets without exposing them in the pod spec.

Why this answer

Using a mutating webhook to inject secrets as volumes is a common pattern (e.g., with Vault Agent Sidecar Injector). It avoids storing secrets in environment variables and integrates with native Kubernetes resources. Option A is insecure; option B is deprecated; option D exposes secrets in the command line.

Practice this question →

101

Multi-Selectmedium

Which TWO of the following are valid ways to enforce that containers cannot run as root in a Kubernetes cluster? (Select TWO.)

Select 2 answers

A.Create a Gatekeeper Constraint that requires runAsNonRoot

B.Use a NetworkPolicy to block root containers

C.Set the kubelet flag --run-non-root

D.Enable the PodSecurity admission controller with the 'restricted' profile

E.Use a ServiceAccount to restrict root

AnswersA, D

Correct. Gatekeeper can enforce arbitrary policies.

Why this answer

Pod Security Standards (restricted profile) and Pod Security Policies (deprecated but still valid in some contexts) both enforce runAsNonRoot. OPA Gatekeeper can also enforce custom policies.

Practice this question →

102

Multi-Selecthard

Which THREE of the following are valid ways to enforce mTLS in an Istio service mesh? (Select 3)

Select 3 answers

A.DestinationRule with trafficPolicy.tls.mode set to ISTIO_MUTUAL

B.PeerAuthentication with mTLS mode set to STRICT

C.ServiceEntry with mTLS enabled for external services

D.AuthorizationPolicy with deny rules for non-mTLS traffic

E.NetworkPolicy with ingress rules to allow only TLS traffic

AnswersA, B, C

Configures client-side mTLS for traffic to a specific host.

Why this answer

PeerAuthentication with mTLS mode (option A) enforces mTLS per namespace or workload. DestinationRule with tls settings (option B) configures client-side TLS settings. ServiceEntry can enable mTLS for external services (option D).

Option C (NetworkPolicy) is for Kubernetes network policies, not TLS. Option E (AuthorizationPolicy) is for access control, not TLS configuration.

Practice this question →

103

MCQhard

You want to run a workload in a sandboxed container using gVisor. You have created a RuntimeClass named 'gvisor' that references the 'runsc' handler. Which of the following Pod specs correctly uses this RuntimeClass?

A.apiVersion: v1 kind: Pod metadata: name: sandbox-pod annotations: runtimeClass: gvisor spec: containers: - name: app image: nginx

B.apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: runtimeClassName: gvisor containers: - name: app image: nginx

C.apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: nodeSelector: runtime: gvisor containers: - name: app image: nginx

D.apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: runtimeClass: name: gvisor containers: - name: app image: nginx

AnswerB

Correct usage: runtimeClassName set to the name of the RuntimeClass resource.

Practice this question →

104

MCQmedium

You have created a ValidatingWebhookConfiguration to reject pods without resource limits. When you try to create a pod without limits, it is created successfully. What is the most likely reason?

A.The webhook is not matching the namespace labels

B.The webhook service is not running or is unreachable

C.The webhook is configured with failurePolicy: Fail

D.The pod is being created by a controller like a Deployment

AnswerB

If the webhook service is down, the API server will fail open (depending on failurePolicy) and allow the pod creation.

Why this answer

If the webhook service is not available, the API server's behavior depends on the failurePolicy. The default failurePolicy is Fail, but if the service is unreachable, the webhook check fails and the request is denied. However, common misconfigurations include the webhook service not being deployed or the service name not matching the webhook configuration, causing the API server to skip the webhook.

The most common reason for a webhook not working is that the service is not running or the configuration is incorrect.

Practice this question →

105

MCQeasy

Which kubectl command is used to create a Constraint object in OPA/Gatekeeper?

A.kubectl create configmap constraint.yaml

B.kubectl apply -f constraint.yaml

C.kubectl create pod constraint.yaml

D.kubectl create -f constraint.yaml

AnswerB

kubectl apply can create a constraint from a YAML file. However, 'kubectl create -f' also works. Both are common, but 'apply' is more general.

Why this answer

In OPA/Gatekeeper, constraints are custom resources defined by the ConstraintTemplate. They are created using 'kubectl create -f constraint.yaml'. Option A is for creating a pod.

Option B is for applying a manifest (which can create or update). Option D is for creating a ConfigMap.

Practice this question →

106

MCQeasy

Which of the following is a best practice for storing sensitive data like passwords in Kubernetes?

A.Store them in ConfigMaps

B.Store them in Secrets and mount them as volumes

C.Store them as environment variables in the Pod spec

D.Store them as labels on Pods

AnswerB

Secrets are designed for sensitive data, and mounting as volumes is more secure than environment variables (avoids exposure in process listing).

Why this answer

Mounting Secrets as volumes is recommended over environment variables because they are not exposed in container environment or command output. Secrets themselves are base64 encoded but not encrypted by default; enabling encryption at rest adds another layer.

Practice this question →

107

MCQmedium

A pod is configured with securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 The volume mounted at /data is owned by user 1000 and group 2000. The container process inside the pod writes to /data. Which statement about file ownership is true?

A.Files created in /data will be owned by root:root because of the volume mount.

B.Files created in /data will be owned by user 1000 and group 2000.

C.Files created in /data will be owned by user 1000 and group 3000.

D.Files created in /data will be owned by user 1000 and group 1000.

AnswerB

fsGroup sets the group ownership for the volume, and runAsUser sets the user. New files are owned by the user and the fsGroup.

Practice this question →

108

MCQhard

An administrator wants to use gVisor as the container runtime for specific high-security workloads. After installing gVisor, what Kubernetes resource must be created to allow pods to request gVisor?

A.RuntimeClass with handler: runsc

B.CustomResourceDefinition for gVisor

C.PodSecurityPolicy with runtimeClass: gvisor

D.ConfigMap with runtime handler mapping

AnswerA

A RuntimeClass resource with handler set to 'runsc' (the gVisor runtime handler) allows pods to specify this runtime via runtimeClassName.

Why this answer

RuntimeClass is the standard Kubernetes way to select a container runtime. For gVisor, the handler is 'runsc'.

Practice this question →

109

MCQeasy

Which of the following is the best practice for providing sensitive data like passwords to a pod?

A.Mount secrets as volumes into the pod.

B.Use environment variables to inject secrets directly.

C.Pass secrets via command-line arguments.

D.Hardcode the secret in the container image.

AnswerA

Volume mounts are more secure as they are available only to the container and can have permissions set.

Why this answer

Mounting secrets as volumes is more secure than environment variables because volumes do not expose secrets in process listings or logs.

Practice this question →

110

MCQmedium

A security engineer runs the following command to inspect a pod's security context: kubectl get pod secure-pod -o jsonpath='{.spec.containers[0].securityContext.capabilities}' The output is: {"drop":["ALL"]} What does this indicate?

A.The container has all Linux capabilities dropped

B.The output is invalid because capabilities should be in add field

C.The container has no capability restrictions

D.The container has only the NET_ADMIN capability added

AnswerA

The output shows that the 'drop' field contains 'ALL', meaning all capabilities are removed from the container.

Why this answer

The capabilities field with drop: ["ALL"] removes all Linux capabilities from the container, increasing security.

Practice this question →

111

Multi-Selecteasy

Which TWO of the following are valid methods to securely manage secrets in Kubernetes?

Select 2 answers

A.Use Kubernetes Secrets with encryption at rest enabled

B.Store secrets in ConfigMaps and use them in pods

C.Commit secrets to a private Git repository

D.Store secrets directly in the application code

E.Use an external secret manager like HashiCorp Vault with a sidecar or CSI driver

AnswersA, E

Kubernetes Secrets can be encrypted using EncryptionConfiguration.

Why this answer

Secrets should be stored in etcd encrypted, and external secret managers like HashiCorp Vault provide better security. Using ConfigMaps for secrets is insecure because ConfigMaps are not encrypted. Committing secrets to Git is a security risk.

Hardcoding secrets in code is also insecure.

Practice this question →

112

MCQhard

An admin wants to enforce that all pods in a namespace use a read-only root filesystem except for a specific deployment that needs to write to a temporary directory. Which approach best meets this requirement?

A.Use a Gatekeeper Constraint that denies pods with readOnlyRootFilesystem not set to true, but add an exception label on the specific deployment's namespace or pod, and modify the Constraint to skip pods with that label

B.Set a default readOnlyRootFilesystem: true via a mutating webhook, and then manually patch the specific deployment after creation

C.Modify the PodSecurityPolicy to allow readOnlyRootFilesystem: false for the specific deployment's service account

D.Set readOnlyRootFilesystem: true in the deployment's pod template and add an emptyDir volume for the temporary directory

AnswerA

This allows fine-grained, policy-based enforcement with exceptions.

Why this answer

Option C is correct. Using a Constraint that allows exceptions via label matching is the most flexible. Option A is not possible per pod.

Option B would require manual maintenance. Option D would still require a policy to enforce non-exempt pods.

Practice this question →

113

MCQeasy

Which command creates a validating webhook configuration that checks all pods in the cluster?

A.kubectl create mutatingwebhookconfiguration my-webhook --from-file=webhook.yaml

B.kubectl run webhook --image=webhook

C.kubectl create validatingwebhookconfiguration my-webhook --from-file=webhook.yaml

D.kubectl apply -f webhook.yaml --validating

AnswerC

Correct.

Why this answer

ValidatingWebhookConfiguration is the resource for admission webhooks that validate resources.

Practice this question →

114

MCQhard

A security team wants to use OPA/Gatekeeper to enforce that all namespaces must have a label 'security-tier' with value 'high' or 'medium'. What is the correct approach?

A.Write a MutatingWebhookConfiguration that adds the label automatically.

B.Use kubectl label command with a --validate flag.

C.Create a ValidatingWebhookConfiguration that directly contains the Rego policy.

D.Create a ConstraintTemplate with Rego that denies namespaces missing the label, then create a Constraint referencing that template.

AnswerD

This is the standard Gatekeeper pattern: ConstraintTemplate defines the rule, Constraint applies it to specific resources.

Why this answer

The correct approach is to create a ConstraintTemplate that defines the Rego logic for checking the label, and then create a Constraint that uses that template. The Constraint is the actual policy object that specifies the enforcement scope (e.g., all namespaces).

Practice this question →

115

MCQmedium

An administrator wants to prevent pods from using secrets as environment variables and enforce that secrets are only mounted as volumes. Which admission controller could be used to achieve this?

A.NetworkPolicy

B.MutatingWebhookConfiguration

C.PodSecurityPolicy (deprecated)

D.ValidatingWebhookConfiguration

AnswerB

A mutating webhook can automatically modify the pod spec to replace env vars with volume mounts, enforcing the policy without rejecting the pod.

Why this answer

A MutatingWebhookConfiguration can be used to modify pod specs at admission time, for example to remove environment variable references to secrets and replace them with volume mounts. Alternatively, a ValidatingWebhookConfiguration could deny pods that use secrets as env vars. Both are valid, but a mutating webhook can automatically fix the issue.

Practice this question →

116

MCQmedium

You want to run a container with gVisor (runsc) runtime for sandboxing. Which resource is required to use a non-default runtime?

A.PodSecurityPolicy

B.ContainerRuntime resource

C.RuntimeClass resource

D.Node runtime configuration only

AnswerC

Correct. RuntimeClass is a cluster-scoped resource that defines a runtime handler (e.g., runsc) and is referenced in pod spec.

Why this answer

A RuntimeClass resource defines a container runtime (e.g., gVisor) that can be referenced in pod spec via 'runtimeClassName'. This is the standard way to use alternative runtimes in Kubernetes.

Practice this question →

117

MCQeasy

Given the following PodSecurityPolicy (PSP) snippet, which statement about the allowed containers is correct?

A.Containers can run in privileged mode

B.Containers cannot use ConfigMap volumes

C.Containers must run as the root user

D.Containers cannot add any Linux capabilities

AnswerD

The PSP requires dropping ALL capabilities, so adding any is disallowed.

Why this answer

Option D is correct because the PodSecurityPolicy snippet does not include `allowedCapabilities` or sets it to an empty list, and the `defaultAddCapabilities` is not specified, meaning no Linux capabilities are added by default. Additionally, the `requiredDropCapabilities` field is not present, but the absence of any allowed capabilities effectively prevents containers from adding any Linux capabilities beyond the default set, which is restricted by the PSP's `allowedCapabilities: []` or lack thereof. This enforces a strict security posture where containers cannot gain extra privileges via capabilities.

Exam trap

The trap here is that candidates often assume the absence of `allowedCapabilities` means all capabilities are allowed, but in PSP, an empty or missing `allowedCapabilities` list actually denies all non-default capabilities, which is a subtle but critical distinction tested in the CKS exam.

How to eliminate wrong answers

Option A is wrong because the PSP snippet does not set `privileged: true`; by default, `privileged` is false, preventing containers from running in privileged mode. Option B is wrong because ConfigMap volumes are allowed by default unless explicitly denied via `volumes` field; the snippet does not list ConfigMap in a `volumes` blacklist or restrict it. Option C is wrong because the PSP does not specify `runAsUser: rule: MustRunAsNonRoot` or `runAsUser: rule: RunAsAny`; without a `runAsUser` rule, containers are not forced to run as root, and the default behavior allows any user ID unless constrained.

Practice this question →

118

MCQmedium

A ValidatingWebhookConfiguration is not working as expected. The webhook server is running and accessible. What is a common misconfiguration that would cause the webhook to not be called?

A.The webhook server uses HTTP instead of HTTPS

B.The webhook service is of type ClusterIP

C.The webhook server returns a 502 status code

D.The 'clientConfig.service.namespace' does not match the namespace of the webhook service

AnswerD

The API server uses this namespace to route requests to the webhook service.

Why this answer

Option A is correct. The 'clientConfig.service' must specify the correct namespace where the webhook service is deployed. If the namespace is wrong, the API server cannot reach the service.

Options B and C are not required for the webhook to be called. Option D would cause the webhook to fail, but it would still be called.

Practice this question →

119

MCQmedium

You need to ensure that all pods in a namespace can only communicate via mTLS. In Istio, which resource should you apply?

A.PeerAuthentication with mode: STRICT

B.DestinationRule with tls: ISTIO_MUTUAL

C.PeerAuthentication with mode: DISABLE

D.PeerAuthentication with mode: PERMISSIVE

AnswerA

STRICT enforces mTLS for all traffic.

Why this answer

Option B is correct. PeerAuthentication with mode STRICT enforces mTLS for all workloads in the namespace. Option A sets mTLS to PERMISSIVE (allows both plaintext and mTLS).

Option C is for traffic policies, not mTLS enforcement. Option D disables mTLS.

Practice this question →

120

Multi-Selectmedium

Which THREE of the following security context settings help mitigate container breakout attacks? (Select 3)

Select 3 answers

A.readOnlyRootFilesystem: true

B.privileged: true

C.allowPrivilegeEscalation: false

D.capabilities: add: ['NET_ADMIN']

E.runAsNonRoot: true

AnswersA, C, E

Prevents writing to the root filesystem, limiting the ability to modify binaries or write scripts.

Why this answer

runAsNonRoot, allowPrivilegeEscalation: false, and readOnlyRootFilesystem are standard security hardening measures that reduce the risk of container breakout.

Practice this question →

121

MCQeasy

You are tasked with creating a ConstraintTemplate in OPA/Gatekeeper that denies pods running with the 'latest' image tag. Which Rego rule should the ConstraintTemplate include?

A.admit[{"msg": msg}] { ... }

B.violation[{"msg": msg}] { ... }

C.reject[{"msg": msg}] { ... }

D.deny[{"msg": msg}] { ... }

AnswerB

In OPA/Gatekeeper ConstraintTemplates, the violation rule is used to deny admission. If the rule evaluates to true, the request is denied.

Why this answer

Gatekeeper ConstraintTemplates use a Rego rule named 'violation' to define admission violations. When the rule evaluates to true, the request is denied.

Practice this question →

122

Multi-Selecthard

Which THREE of the following are valid capabilities that should be dropped for a container running a typical non-privileged application to adhere to the principle of least privilege?

Select 3 answers

A.CHOWN

B.SYS_ADMIN

C.NET_RAW

D.SETUID

E.NET_ADMIN

AnswersB, C, E

Highly privileged; almost never needed in containers and should be dropped.

Why this answer

The principle of least privilege suggests dropping all capabilities except those absolutely needed. For most applications, capabilities like NET_RAW, SYS_ADMIN, and SETUID are unnecessary and should be dropped. NET_ADMIN is also dangerous.

Dropping these reduces attack surface.

Practice this question →

123

MCQhard

A microservice container needs to perform DNS lookups using TCP rather than UDP. Which Kubernetes security context setting should be configured to allow this?

A.Add `DAC_OVERRIDE` capability

B.Add `NET_RAW` capability

C.Add `NET_ADMIN` capability

D.Add `NET_BIND_SERVICE` capability

AnswerB

TCP DNS may require raw socket access on some configurations.

Why this answer

Option B is correct because DNS queries typically use UDP, but when a response is truncated or when zone transfers are involved, TCP is required. The `NET_RAW` capability allows a container to create raw sockets, which is necessary for crafting and sending TCP packets for DNS lookups at the transport layer. Without this capability, the container's network stack may be restricted to only UDP-based DNS resolution.

Exam trap

The trap here is that candidates often confuse `NET_RAW` (needed for raw sockets and TCP-level operations) with `NET_ADMIN` (which is for network administration tasks), or incorrectly assume that DNS always uses UDP and that no capability is needed for TCP fallback.

How to eliminate wrong answers

Option A is wrong because `DAC_OVERRIDE` capability bypasses file permission checks and has no relevance to network protocol selection for DNS lookups. Option C is wrong because `NET_ADMIN` capability grants broad network administration privileges (e.g., interface configuration, firewall rules) which is excessive and not specifically required for enabling TCP-based DNS queries. Option D is wrong because `NET_BIND_SERVICE` capability allows binding to privileged ports (below 1024) and does not control the ability to use TCP for DNS lookups.

Practice this question →

124

MCQmedium

A pod's container tries to read environment variables that contain database credentials. The cluster has an external secrets manager (HashiCorp Vault) integrated via a sidecar. Which approach is MOST secure for exposing secrets to the container?

A.Mount the secrets as a volume using a CSI driver

B.Set the secrets as environment variables using the 'env' field

C.Embed the secrets directly in the container image

D.Use a ConfigMap to store the secrets

AnswerA

Correct. Volume mounts are more secure and avoid exposure.

Why this answer

Mounting secrets as volumes is more secure than environment variables because they are not exposed in process listings or logs.

Practice this question →

125

Drag & Dropmedium

Arrange the steps to configure and use Trivy to scan container images for vulnerabilities in a CI/CD pipeline.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Trivy scanning involves installation, building/pushing image, scanning, parsing results, and enforcing policies.

Practice this question →

126

MCQmedium

You need to encrypt secrets at rest in a Kubernetes cluster. What must be configured?

A.Create an EncryptionConfiguration object in the cluster and pass it to kube-apiserver via --encryption-provider-config

B.Set the environment variable ENCRYPT_SECRETS=true on the kube-controller-manager

C.Use a MutatingWebhookConfiguration to encrypt secrets before storage

D.Enable the 'SecretEncryption' feature gate on all control plane components

AnswerA

Kubernetes supports encryption at rest via EncryptionConfiguration resource, which is provided to the API server using the --encryption-provider-config flag.

Why this answer

EncryptionConfiguration is a Kubernetes resource that defines how to encrypt resources (like Secrets) at rest. The API server reads this configuration via the --encryption-provider-config flag.

Practice this question →

127

MCQmedium

You want to drop all Linux capabilities from a container. Which securityContext field should you set?

A.capabilities.allow

B.capabilities.add: ["ALL"]

C.capabilities.drop: ["ALL"]

D.dropCapabilities: true

AnswerC

Drops all capabilities, minimizing privilege.

Why this answer

Option C is correct. The 'capabilities.drop' field with a list of all capabilities (or using ['ALL']) drops all capabilities. Option A adds capabilities.

Option B is a field for defining allowed capabilities. Option D is not a valid field.

Practice this question →

128

MCQeasy

Which flag enables the PodSecurity admission plugin in kube-apiserver?

A.--enable-admission-plugins=PodSecurity

B.--admission-control=PodSecurity

C.--feature-gates=PodSecurity=true

D.--pod-security-policy=true

AnswerA

The PodSecurity plugin is enabled by adding it to the --enable-admission-plugins flag.

Why this answer

The PodSecurity admission plugin is enabled via the --enable-admission-plugins flag on the API server. It replaced the deprecated PodSecurityPolicy.

Practice this question →

129

MCQmedium

An OPA Gatekeeper ConstraintTemplate uses a Rego rule that denies pods without a specific label. The Constraint is created but pods without the label are still being allowed. What is the MOST likely cause?

A.The Rego policy has a syntax error

B.Gatekeeper is not installed in the cluster

C.The Constraint object has not been created

D.The namespace is excluded via Gatekeeper configuration

AnswerC

Correct. The Constraint instantiates the template.

Why this answer

Gatekeeper requires both a ConstraintTemplate and a Constraint instance. Without the Constraint, the template does not enforce.

Practice this question →

130

MCQmedium

A pod manifests with securityContext: { runAsNonRoot: true, runAsUser: 1001 }. However, the container image expects to run as root (UID 0). What will happen when the pod is created?

A.The container runs as root because runAsUser overrides runAsNonRoot

B.The container fails to start because it cannot run as root

C.The container runs as user 1001

D.The pod runs, but the securityContext is ignored

AnswerB

runAsNonRoot: true prevents running as root; if the image requires root, the container will fail.

Why this answer

runAsNonRoot: true prevents the container from running as UID 0. If the image user is root, the container will not start. The pod might be rejected by admission control or fail to run.

It will not run as root or switch to user 1001 automatically if the image entrypoint expects root.

Practice this question →

131

Multi-Selecteasy

You are asked to secure a set of microservices running in a Kubernetes cluster. Which TWO of the following practices help minimize vulnerabilities in microservices?

Select 2 answers

A.Manually inject sidecar proxies into every pod to enforce mTLS.

B.Run containers in privileged mode to allow them to perform necessary system calls.

C.Ensure containers run with a non-root user.

D.Use a read-only root filesystem for containers.

E.Store secrets directly in container images for easy access.

AnswersC, D

Running as non-root limits the permissions available to an attacker if the container is compromised.

Why this answer

Option C is correct because running containers with a non-root user (via the `securityContext.runAsNonRoot: true` field or a specific `runAsUser` directive) prevents privilege escalation and limits the blast radius of a container compromise. This aligns with the principle of least privilege, a core mitigation against container breakout attacks in Kubernetes.

Exam trap

CNCF often tests the misconception that sidecar proxies must be manually injected to enforce mTLS, but the correct approach is to use automated injection via admission controllers to avoid misconfiguration and ensure consistent policy enforcement.

Practice this question →

132

MCQmedium

You are implementing a Gatekeeper policy to deny pods that run as root. Which Rego rule should you include in the ConstraintTemplate?

A.allow[{"msg": msg}] { msg := "container runs as root"; input.spec.containers[_].securityContext.runAsNonRoot == false }

B.deny[msg] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }

C.deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }

D.deny[msg] { input.spec.containers[_].securityContext.runAsNonRoot == false }

AnswerC

This Rego rule denies pods where runAsNonRoot is not set to true.

Why this answer

Option A is correct. The deny rule in Rego returns a violation message when the condition is true. To deny pods running as root, the rule should check if runAsNonRoot is set to false (or not set).

Option B is syntactically incorrect (missing 'msg'). Option C allows root. Option D is not a valid Rego rule structure.

Practice this question →

133

MCQeasy

Which kubectl command would you use to create a ValidatingWebhookConfiguration from a YAML file?

A.kubectl run webhook --image=webhook --restart=Never

B.kubectl apply -f webhook.yaml

C.kubectl create -f webhook.yaml

D.kubectl expose deployment webhook --port=443

AnswerB

This is the standard command to create or update resources from a file.

Why this answer

The correct command is `kubectl apply -f webhook.yaml` to create or update the resource from a file.

Practice this question →

134

MCQeasy

Which kubectl command would you use to create a Secret from a file named 'db-password.txt'?

A.kubectl apply -f db-password.txt

B.kubectl create configmap db-password --from-file=db-password.txt

C.kubectl create secret tls db-password --cert=db-password.txt

D.kubectl create secret generic db-password --from-file=db-password.txt

AnswerD

This creates a Secret named 'db-password' with the file contents.

Practice this question →

135

MCQmedium

You need to set up a ValidatingWebhookConfiguration to deny pods that run as root. The webhook server is deployed in the 'webhook' namespace with service 'webhook-svc' on port 443. Which of the following is a correct snippet for the webhook configuration?

A.clientConfig: service: name: webhook-svc namespace: webhook path: /validate port: 443

B.clientConfig: url: https://10.96.0.1:443/validate

C.clientConfig: url: https://webhook-svc.webhook.svc:443/validate

D.clientConfig: service: name: webhook-svc namespace: webhook path: /validate caBundle: <base64>

AnswerA

This correctly references the service within the cluster.

Practice this question →

136

MCQeasy

Which of the following is the correct way to drop all capabilities in a container's security context?

A.securityContext: capabilities: drop: ['ALL']

B.securityContext: capabilities: remove: ['ALL']

C.securityContext: capabilities: []

D.securityContext: capabilities: add: []

AnswerA

This drops all capabilities.

Why this answer

The correct YAML is `capabilities: drop: ['ALL']` under securityContext.

Practice this question →

137

Multi-Selecthard

Which THREE of the following are valid ways to manage secrets in a Kubernetes environment? (Select THREE)

Select 3 answers

A.Use an external secret manager like HashiCorp Vault and inject secrets via sidecar or CSI driver.

B.Store secrets in environment variables directly in the Deployment YAML.

C.Use Kubernetes Secret objects mounted as volumes in pods.

D.Encrypt Secret objects at rest using EncryptionConfiguration.

E.Store secrets in ConfigMaps and reference them in pods.

AnswersA, C, D

External secret managers provide secure storage and dynamic secrets.

Practice this question →

138

Matchingmedium

Match each Kubernetes network security concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Outbound network traffic from a pod to external endpoints

Inbound network traffic to a pod from external sources

Specification of how groups of pods are allowed to communicate

Container Network Interface plugin that implements networking for pods

Infrastructure layer for handling service-to-service communication, often with mTLS

Why these pairings

Understanding these concepts is important for implementing network security.

Practice this question →

139

Multi-Selectmedium

Which TWO of the following are best practices for minimizing microservice vulnerabilities in a Kubernetes cluster?

Select 2 answers

A.Enable mutual TLS (mTLS) for service-to-service communication using a service mesh.

B.Run containers as root to avoid permission issues.

C.Allow all egress traffic from pods to simplify network management.

D.Set resource limits (CPU/memory) on containers to prevent resource exhaustion attacks.

E.Use hostNetwork: true for pods to improve network performance.

AnswersA, D

mTLS provides encryption and mutual authentication, reducing vulnerability to eavesdropping and impersonation.

Why this answer

Mutual TLS (mTLS) encrypts and authenticates all service-to-service traffic within the cluster, preventing eavesdropping, man-in-the-middle attacks, and unauthorized access. A service mesh like Istio or Linkerd transparently enforces mTLS without requiring application code changes, ensuring that only verified services can communicate. This directly minimizes the attack surface for microservice vulnerabilities by enforcing zero-trust network principles.

Exam trap

CNCF often tests the misconception that 'simplifying network management' (e.g., allowing all egress traffic) is a security best practice, when in fact it removes critical network segmentation controls required for microservice isolation.

Practice this question →

140

Multi-Selectmedium

Which TWO of the following are best practices for securing secrets in Kubernetes?

Select 2 answers

A.Storing secrets as environment variables

B.Using the default secret type (Opaque) for all secrets

C.Enabling encryption at rest for secrets

D.Limiting the number of secrets in the cluster

E.Using an external secrets management system like HashiCorp Vault

AnswersC, E

Encryption at rest protects secrets if etcd is compromised.

Why this answer

Options B and D are best practices. Option B: Using external secret managers provides rotation and auditing. Option D: Encryption at rest protects secrets stored in etcd.

Option A is not a best practice because secrets can be exposed. Option C: Reducing the number of secrets does not directly improve security; proper management is better. Option E: The default `type: Opaque` is not secure; using encrypted secrets is better.

Practice this question →

141

MCQmedium

You run 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' and get 'no'. What does this mean?

A.The command is invalid because 'system:serviceaccount' is not a valid user

B.The service account 'sa1' does not exist

C.The service account 'sa1' does not have permission to create pods in the default namespace

D.The service account 'sa1' is not allowed to perform any actions

AnswerC

The kubectl auth can-i command checks whether a user or service account can perform an action. 'no' means insufficient permissions.

Why this answer

kubectl auth can-i is used to verify if a user (including service accounts) has permission to perform a specific action. A 'no' response indicates that the action is denied by RBAC.

Practice this question →

142

Multi-Selectmedium

Which TWO of the following are valid methods to securely manage secrets in Kubernetes? (Select 2)

Select 2 answers

A.Use an external secrets manager like HashiCorp Vault with a CSI driver or operator

B.Store secrets directly in container images as files

C.Mount secrets as volumes using projected volumes or secret volumes

D.Store secrets in ConfigMaps

E.Pass secrets as environment variables from a Secret resource

AnswersA, C

External managers provide rotation and access control.

Why this answer

Mounting secrets as volumes (option A) is secure because the secret is not exposed in environment variables or command arguments. Using external secret managers like Vault (option C) is a best practice for centralized secret management. Option B (env vars) is insecure as secrets can be leaked in process listings.

Option D (hardcoded in images) is insecure. Option E (ConfigMaps) is for non-sensitive data.

Practice this question →

143

MCQmedium

You need to enforce that no pod runs with privileged containers or runs as root. Which tool can define policies that block such pods at admission time?

A.Kubernetes Secret

B.PodDisruptionBudget

C.OPA Gatekeeper

D.NetworkPolicy

AnswerC

OPA Gatekeeper is an admission webhook that enforces policies, including security policies.

Why this answer

OPA Gatekeeper allows enforcing custom policies via ConstraintTemplates and Constraints. It can deny pods that violate the policies.

Practice this question →

144

MCQeasy

You need to ensure that all pods in a cluster run with read-only root filesystems. Which Pod Security Standard (PSS) control field should be set to true?

A.spec.readOnlyRootFilesystem

B.securityContext.privileged: false

C.container.readOnly

D.securityContext.readOnlyRootFilesystem

AnswerD

Correct. Setting this field to true enforces a read-only root filesystem for the container.

Why this answer

The 'readOnlyRootFilesystem' field in the security context of a container, when set to true, ensures the root filesystem is read-only. This is a common security hardening measure.

Practice this question →

145

MCQmedium

A security team wants to enforce that containers in a specific namespace cannot gain new capabilities. Which Pod security context field is used to achieve this?

A.capabilities.drop: ["ALL"]

B.privileged: false

C.allowPrivilegeEscalation: false

D.runAsNonRoot: true

AnswerC

Correct. This prevents privilege escalation.

Why this answer

Setting 'allowPrivilegeEscalation: false' prevents processes from gaining more privileges than their parent.

Practice this question →

146

MCQmedium

An admin runs 'kubectl run test-pod --image=busybox --command -- sleep 3600' and then executes 'kubectl exec test-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token'. The admin wants to prevent such access to the service account token. What is the correct action?

A.Remove the service account from the pod

B.Set securityContext.runAsNonRoot: true

C.Set automountServiceAccountToken: false in the pod spec

D.Use a NetworkPolicy to block access to the API server

AnswerC

Correct. This boolean field controls whether the service account token is automatically mounted.

Why this answer

Setting automountServiceAccountToken to false in the pod spec prevents automatic mounting of the service account token. This is a security best practice for pods that do not need to interact with the API server.

Practice this question →

147

MCQmedium

A developer creates a Deployment with the following container spec: ```yaml containers: - name: app image: myapp:latest env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password ``` Which of the following is a security concern with this approach?

A.The secret is not encrypted at rest in etcd.

B.The secret is exposed in the container environment variables, which can be accessed via /proc or logs if the container is compromised.

C.The secret name 'db-secret' is too generic.

D.The secret is not base64 encoded.

AnswerB

Environment variables are visible in the container's /proc/self/environ and can be logged by applications. Mounting secrets as volumes is more secure.

Practice this question →

148

MCQhard

Which of the following is NOT a valid method to enforce pod security standards in a Kubernetes cluster?

A.Using Pod Security Policy (PSP) if still available in the cluster

B.Using a mutating webhook to apply security contexts

C.Using OPA/Gatekeeper with the built-in PSS templates

D.Using Pod Security Admission (PSA) with labels on namespaces

AnswerC

OPA/Gatekeeper does not include built-in PSS templates; you must write custom Rego policies.

Why this answer

Option D is correct. OPA/Gatekeeper is a policy engine, but it does not natively enforce Pod Security Standards (PSS); it can be used to implement custom policies. The built-in methods are Pod Security Admission (PSA) and PodSecurityPolicy (deprecated).

Options A, B, and C are valid methods.

Practice this question →

149

MCQmedium

You are deploying an application that needs to access a database password stored in a Kubernetes Secret. To minimize risk, you should mount the Secret as a volume rather than using environment variables. Which of the following is the primary security benefit of using mounted volumes over environment variables?

A.Environment variables can be leaked through commands like 'env' or 'cat /proc/1/environ', while mounted files are only accessible if the container has a shell and reads the file.

B.Mounted volumes are not visible in /proc, making them inaccessible to other processes.

C.Environment variables are stored in etcd in plaintext, while volumes are encrypted at rest.

D.Mounted volumes automatically rotate the secret when the Secret object is updated.

AnswerA

Environment variables are easily exposed through process listings and debugging tools. Mounted secrets require explicit file reads.

Practice this question →

150

Multi-Selecteasy

Which TWO of the following are valid Kubernetes RuntimeClass handlers for container sandboxing? (Choose two.)

Select 2 answers

A.docker

B.runc

C.runsc

D.containerd

E.kata

AnswersC, E

gVisor's runtime handler is runsc.

Why this answer

Option A (runsc) is gVisor. Option C (kata) is Kata Containers. Option B (docker) is not a sandboxing runtime.

Option D (runc) is the default OCI runtime, not sandboxed. Option E (containerd) is a container runtime, not a sandboxing handler.

Practice this question →