CCNA Cks Microservice Vuln Questions — Page 1 of 3

Multi-Selectmedium

Which TWO of the following are valid approaches to manage secrets in a Kubernetes cluster?

Select 2 answers

A.Pass secrets as environment variables

B.Embed secrets directly in the pod YAML definition

C.Mount secrets as volumes in pods

D.Store secrets as plain text in ConfigMap

E.Use an external secrets manager like HashiCorp Vault with CSI driver

AnswersC, E

This is a best practice; secrets are mounted as files.

Why this answer

Mounting secrets as volumes and using an external secrets manager like HashiCorp Vault are both valid. Storing in ConfigMap is insecure because ConfigMaps are not encrypted. Embedding in YAML is insecure.

Using environment variables is less secure than volumes.

Practice this question →

MCQmedium

A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?

A.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

B.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

C.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

D.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

AnswerB

This correctly denies pods where any container does not set runAsNonRoot to true.

Why this answer

Option A correctly defines a ConstraintTemplate with a Rego rule that checks `runAsNonRoot` is true, and a Constraint that matches all pods in the namespace. Option B checks the wrong field. Option C uses `securityContext.capabilities` which is unrelated.

Option D uses an incorrect Rego condition.

Practice this question →

MCQmedium

You need to drop all Linux capabilities from a container. Which YAML snippet is correct?

A.capabilities: { remove: ["ALL"] }

B.capabilities: { drop: ["ALL"] }

C.capabilities: { none: true }

D.securityContext: { capabilities: { drop: ["ALL"] } }

AnswerB, D

Correct.

Why this answer

The correct way is to drop ALL capabilities using 'capabilities.drop: ["ALL"]'.

Practice this question →

MCQmedium

A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?

A.Store the API key in a ConfigMap and expose it as an environment variable

B.Hardcode the API key in the container image

C.Store the API key in a Kubernetes Secret and mount it as a volume inside the container

D.Store the API key in a Kubernetes Secret and expose it as an environment variable

AnswerC

Secrets are designed for sensitive data; volume mounts avoid exposure in environment variable listings.

Why this answer

Option C is correct because mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.

Exam trap

CNCF often tests the misconception that environment variables from Secrets are equally secure as volume mounts, but the trap is that environment variables are more exposed to runtime leaks and cannot be rotated without pod restart, whereas volume mounts offer better isolation and live update capabilities.

How to eliminate wrong answers

Option A is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets like API keys. Option B is wrong because hardcoding secrets in a container image embeds them in the image layers, making them accessible to anyone with image pull access and violating immutable infrastructure principles. Option D is wrong because exposing a Secret as an environment variable increases the risk of leakage through container logs, debugging endpoints, or the `/proc/self/environ` file, and does not support seamless secret rotation without pod restart.

Practice this question →

MCQmedium

You need to encrypt Kubernetes secrets at rest. Which resource should you configure?

A.EncryptionProvider

B.SecretEncryptionConfig

C.KMSProvider

D.EncryptionConfiguration

AnswerD

Correct. EncryptionConfiguration is an API resource that specifies encryption providers and keys for encrypting resources at rest.

Why this answer

EncryptionConfiguration is the Kubernetes resource that defines how to encrypt resources at rest in etcd, including secrets. It is used with the kube-apiserver flag --encryption-provider-config.

Practice this question →

MCQhard

A security engineer wants to encrypt secrets at rest in an existing Kubernetes cluster. The cluster is already running with the default encryption configuration. After creating an EncryptionConfiguration resource and updating the kube-apiserver manifest, which command should be used to ensure the new configuration is applied without restarting the API server?

A.kubectl label node control-plane --overwrite encryption=true

B.kubectl rollout restart -n kube-system deployment/kube-apiserver

C.kubectl apply -f encryption-config.yaml

D.kubectl delete pod -n kube-system -l component=kube-apiserver

AnswerB

Restarts the API server deployment, causing it to read the updated EncryptionConfiguration.

Why this answer

Option B is correct. After updating the EncryptionConfiguration, you must restart the kube-apiserver pod or process. The recommended way is to use 'kubectl rollout restart' on the API server pod (if it's managed by a static pod).

Option A is not needed. Option C does not affect encryption. Option D is not a valid command.

Practice this question →

Multi-Selectmedium

You want to use an external secret management system like HashiCorp Vault to manage database credentials for your application. Which of the following are valid approaches to integrate Vault with Kubernetes?

Select 3 answers

A.Use environment variables from Vault with a script

B.Store Vault tokens in a Kubernetes Secret and mount them

C.Use the Vault Agent Sidecar Injector to inject secrets into pods

D.Use the Vault CSI Provider to mount secrets as volumes

E.Store Vault tokens in a ConfigMap and mount them into pods

AnswersB, C, D

A Kubernetes Secret can hold a Vault token, but it's less secure than using Vault directly; however, it is a valid approach.

Practice this question →

MCQeasy

Which field in a PodSecurityContext ensures that the container cannot gain privileges beyond its parent process?

A.privileged

B.readOnlyRootFilesystem

C.runAsNonRoot

D.allowPrivilegeEscalation

AnswerD

allowPrivilegeEscalation: false prevents the container from gaining more privileges than its parent process.

Practice this question →

Multi-Selecteasy

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Select 2 answers

A.gVisor (runsc)

B.Docker

C.containerd

D.runc

E.Kata Containers

AnswersA, E

gVisor provides a sandboxed container runtime and is supported via RuntimeClass.

Why this answer

gVisor and Kata Containers are sandboxed runtimes that provide additional isolation. They are configured via RuntimeClass in Kubernetes.

Practice this question →

MCQmedium

A security engineer runs the following command to inspect a container's security context. What vulnerability does this configuration expose?

A.The container is running without any capabilities

B.The container has all capabilities enabled, which is a security risk

C.The container has dropped all capabilities except NET_BIND_SERVICE

D.The container has default Docker capabilities, which is secure

AnswerB

Full capabilities allow many privileged operations, increasing attack surface.

Why this answer

The command `docker run --privileged` or a similar configuration that grants all capabilities (e.g., `--cap-add=ALL`) removes all kernel-level isolation, giving the container full access to the host's kernel capabilities. This means the container can perform privileged operations like loading kernel modules, modifying network settings, and accessing raw devices, which directly violates the principle of least privilege and exposes the host to container breakout attacks.

Exam trap

CNCF often tests the distinction between 'default Docker capabilities' (which are secure and limited) and 'all capabilities' (which is a severe vulnerability), and the trap here is that candidates may confuse 'all capabilities' with the default set or think that dropping all capabilities is the only insecure state.

How to eliminate wrong answers

Option A is wrong because the container is explicitly configured with all capabilities enabled, not running without any capabilities (which would be the case with `--cap-drop=ALL`). Option C is wrong because the configuration grants all capabilities, not a minimal set like only `NET_BIND_SERVICE`; dropping all but one capability would be a secure practice, not a vulnerability. Option D is wrong because default Docker capabilities (a restricted set like `CHOWN`, `DAC_OVERRIDE`, `FSETID`, `FOWNER`, `MKNOD`, `NET_RAW`, `SETGID`, `SETUID`, `SETFCAP`, `SETPCAP`, `NET_BIND_SERVICE`, `SYS_CHROOT`, `KILL`, `AUDIT_WRITE`) are considered secure for most workloads, but this configuration explicitly grants all capabilities, which is far less restrictive and insecure.

Practice this question →

MCQeasy

What is the primary benefit of using external secret managers (e.g., HashiCorp Vault) in Kubernetes?

A.They ensure that secrets are never stored in etcd

B.They prevent all unauthorized access to secrets

C.They provide better control over secret rotation, auditing, and access policies

D.They eliminate the need for Kubernetes Secrets entirely

AnswerC

External secret managers offer advanced features like automatic rotation and detailed audit logs.

Why this answer

Option B is correct. External secret managers provide centralized secret management, rotation, and auditing. Option A is wrong because secrets are still stored in etcd unless encrypted.

Option C is wrong because secrets are still accessible if RBAC is misconfigured. Option D is wrong because secrets can still be used by pods.

Practice this question →

MCQhard

A cluster has a ValidatingWebhookConfiguration that intercepts Pod CREATE requests. The webhook server is unavailable. What happens when a user tries to create a pod?

A.The webhook is automatically disabled

B.The API server crashes

C.The pod creation is rejected until the webhook becomes available

D.The pod is created without webhook validation

AnswerC

Default failurePolicy is Fail, so the API server rejects the request.

Why this answer

By default, if a webhook is unreachable, the API server fails closed (rejects the request) unless the failurePolicy is set to Ignore. The default failurePolicy is Fail.

Practice this question →

Multi-Selectmedium

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Select 2 answers

A.Kata Containers run containers in lightweight VMs, providing hardware-level isolation.

B.gVisor provides a kernel-level sandbox by implementing a user-space kernel.

C.Kata Containers use the host kernel for system calls.

D.gVisor runs containers in separate VMs for each pod.

E.Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

AnswersA, B

Kata Containers use VMs for stronger isolation.

Practice this question →

MCQmedium

Which of the following OPA Gatekeeper Rego policies would deny a pod that sets `securityContext.runAsUser: 0`?

A.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.capabilities.drop == "ALL" }

B.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.securityContext.runAsUser == 0 }

C.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }

D.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }

AnswerC

This correctly denies pods with runAsUser=0.

Why this answer

The correct Rego policy denies pods with `runAsUser: 0` because that runs as root. Option A correctly checks for the field and denies if it is 0.

Practice this question →

MCQmedium

A pod uses a Secret mounted as a volume. The Secret is updated. How can the pod consume the updated values without restarting?

A.Use a sidecar container that watches for changes and reloads the application

B.Update the pod spec to reference a new Secret version

C.The mounted volume is automatically updated over time

D.Delete and recreate the pod

AnswerC

When using subPath or projected volumes, updates may not propagate automatically. But for regular volume mounts, the contents are updated periodically.

Why this answer

Kubernetes automatically updates the mounted files when the Secret is updated, but this is not instantaneous and may take some time. However, the question asks for a way without restarting; the answer is that it is automatic, but for an alternative approach, using a sidecar that watches for changes is also valid. Option C (automatic refresh) is the simplest correct answer.

Practice this question →

MCQmedium

An admin has deployed a ValidatingWebhookConfiguration that denies pods with `runAsNonRoot: false`. After creating a pod that does not set `runAsNonRoot` at all, the pod is created successfully. Why did the webhook not deny it?

A.The webhook configuration's rules do not match the pod create operation

B.The webhook's failure policy is set to Ignore

C.The webhook is only applied to pods in a specific namespace

D.The webhook only applies to pods created with a specific service account

AnswerA

If the rules do not include pods or the create operation, the webhook is not invoked.

Why this answer

Option C is correct. A ValidatingWebhookConfiguration must define `rules` with `apiGroups`, `apiVersions`, `operations`, and `resources` to match requests. If the rules do not match the pod creation request, the webhook is not called.

Option A is wrong because the webhook can be cluster-scoped. Option B is wrong because admission webhooks can be used with any pod. Option D is wrong because the webhook can have any failure policy.

Practice this question →

MCQeasy

An administrator needs to enforce that all pods in a namespace run with read-only root filesystem. Which Pod Security Standard should be applied?

A.Use a NetworkPolicy to restrict filesystem access

B.Run the pod with securityContext.readOnlyRootFilesystem: true

C.Set securityContext.runAsNonRoot: true

D.Set securityContext.allowPrivilegeEscalation: false

AnswerB

Setting readOnlyRootFilesystem: true in the security context makes the root filesystem read-only. This is a Pod-level setting.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid Rego policy constructs used in OPA Gatekeeper ConstraintTemplates to enforce security policies? (Choose three)

Select 3 answers

A.violation[{"msg": msg}] { condition }

B.allow { condition }

C.deny[{"msg": msg}] { condition }

D.audit { condition }

E.warn[{"msg": msg}] { condition }

AnswersA, B, C

This is the standard way to report violations in Gatekeeper Rego policies.

Why this answer

In OPA Gatekeeper, Rego policies typically use violation, deny, or allow rules to enforce policies. Violation is specific to Gatekeeper's ConstraintTemplate framework, while deny and allow are general Rego constructs.

Practice this question →

MCQhard

A cluster administrator wants to run some workloads in a sandboxed environment using gVisor. Which Kubernetes resource must be created first to allow pods to request the gVisor runtime?

A.Create a new PodSecurityPolicy that allows the gVisor runtime

B.Create a custom resource definition for the runtime

C.Create a RuntimeClass resource that specifies the gVisor runtime handler

D.Add a `runtimeClass` field to the pod spec

AnswerC

The RuntimeClass resource defines the runtime handler (e.g., runsc) that gVisor uses.

Why this answer

Option C is correct. A RuntimeClass is required to define the container runtime (e.g., gVisor). Pods then specify `runtimeClassName` to use that runtime.

Option A is not correct because RuntimeClass is not a pod spec field but a separate resource. Option B is not correct because a custom resource definition is not needed for built-in RuntimeClass. Option D is not correct because a new PodSecurityPolicy is not required.

Practice this question →

Multi-Selecteasy

Which TWO of the following are valid RuntimeClass handlers for container sandboxing?

Select 2 answers

A.docker

B.runc

C.runsc

D.crun

E.kata

AnswersC, E

Handler for gVisor.

Why this answer

gVisor uses the runsc handler. Kata Containers use kata or kata-qemu. runc is the default runtime for regular containers, not sandboxing. docker is not a RuntimeClass handler. crun is another runtime but not specifically for sandboxing.

Practice this question →

Multi-Selectmedium

Which TWO of the following are required to enable encryption of Kubernetes Secrets at rest?

Select 2 answers

A.Configure etcd encryption via etcdctl

B.Create an EncryptionConfiguration resource

C.Enable the --feature-gates=EncryptionAtRest=true flag on the API server

D.Pass the --encryption-provider-config flag to the kube-apiserver

AnswersB, D

Defines the encryption providers and keys.

Why this answer

EncryptionConfiguration is the resource that defines encryption providers and keys. The kube-apiserver must be configured with the --encryption-provider-config flag pointing to that file. --feature-gates is not needed as encryption is GA. etcd encryption is not directly configured via etcdctl.

Practice this question →

MCQeasy

Which admission controller is responsible for validating and mutating requests based on webhooks?

A.ServiceAccount

B.PodSecurityPolicy

C.NodeRestriction

D.ValidatingAdmissionWebhook and MutatingAdmissionWebhook

AnswerD

These admission controllers enable custom webhooks for validation and mutation.

Why this answer

ValidatingAdmissionWebhook and MutatingAdmissionWebhook are the admission controllers that call external webhooks. The question asks which controller handles both; the webhook infrastructure is managed by these controllers.

Practice this question →

MCQhard

An administrator needs to encrypt secrets at rest in etcd. Which of the following steps is required?

A.Use kubectl encrypt secrets command.

B.Modify the etcd configuration to enable encryption.

C.Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.

D.Set the environment variable ENCRYPT_SECRETS=true on all nodes.

AnswerC

EncryptionConfiguration is a resource that defines how to encrypt data at rest. The kube-apiserver reads it via the flag.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to enforce that a container runs as a non-root user?

Select 2 answers

A.Set the container image to use a root user

B.Set runAsNonRoot: true in the pod securityContext

C.Use a PodSecurityPolicy (PSP)

D.Use a Kyverno policy to validate runAsNonRoot

E.Set runAsUser: 0 in the container securityContext

AnswersB, D

This enforces that the container cannot run as root.

Practice this question →

MCQmedium

An administrator wants to enforce mTLS between all services in the 'mesh' namespace using Istio. Which resource should be applied to require mutual TLS for all workloads in that namespace?

A.PeerAuthentication with mtls.mode: STRICT in the namespace

B.VirtualService with tls mode

C.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

D.ServiceEntry for external services

AnswerA

PeerAuthentication with mtls.mode: STRICT enforces mTLS for all services in the namespace.

Why this answer

PeerAuthentication is the Istio resource that defines how traffic is handled at the sidecar proxy level. Setting mode: STRICT requires mTLS for all traffic in the namespace.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to enforce that containers run with a read-only root filesystem?

Select 2 answers

A.Setting `runAsNonRoot: true` in the pod's securityContext

B.Using an emptyDir volume mounted at /

C.Setting `fsGroup: 1000` in the pod's securityContext

D.Using a MutatingWebhookConfiguration that adds `readOnlyRootFilesystem: true` to all containers

E.Setting `readOnlyRootFilesystem: true` in the container's securityContext

AnswersD, E

A mutating webhook can automatically inject the setting.

Why this answer

Options A and D are correct. Setting `readOnlyRootFilesystem: true` in the container's securityContext enforces a read-only root filesystem. A mutating webhook can also add this setting automatically.

Option B is incorrect because `runAsNonRoot` does not affect filesystem writability. Option C is incorrect because `securityContext.fsGroup` is about file ownership. Option E is incorrect because `emptyDir` volumes are writable but do not enforce a read-only root.

Practice this question →

Multi-Selectmedium

Which TWO of the following are best practices for securing secrets in Kubernetes? (Select 2)

Select 2 answers

A.Use external secret management systems like HashiCorp Vault

B.Mount secrets as volumes instead of environment variables

C.Enable encryption at rest for etcd

D.Set secrets with kubectl create secret generic --from-literal

E.Store secrets in ConfigMaps for easier rotation

AnswersA, B

External secret managers provide better security, auditing, and rotation capabilities.

Why this answer

Mounting secrets as volumes and using external secret managers are recommended best practices to minimize exposure.

Practice this question →

Multi-Selecthard

Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)

Select 3 answers

A.Enforce that containers set runAsNonRoot: true.

B.Enforce that containers do not mount hostPath volumes with read-write access.

C.Allow privileged containers for system-critical workloads.

D.Allow containers to use hostNetwork for easier service discovery.

E.Enforce that containers set seccompProfile.type to RuntimeDefault or Localhost.

AnswersA, B, E

This is a common security best practice.

Why this answer

Option A ensures pods don't run as root. Option B restricts host filesystem access. Option E ensures all pods use a non-default seccomp profile.

Option C (allowing privileged containers) is the opposite of best practice. Option D (allowing host network) is also not a best practice.

Practice this question →

Multi-Selecthard

Which TWO of the following are valid methods to enforce mTLS in an Istio service mesh? (Select 2)

Select 2 answers

A.Create a ServiceEntry for internal services

B.Create a VirtualService with tls termination

C.Create a PeerAuthentication resource with mtls.mode: STRICT

D.Set global.mtls.enabled: true in IstioConfigMap

E.Create a DestinationRule with tls.mode: ISTIO_MUTUAL

AnswersC, E

PeerAuthentication enforces mTLS at the sidecar proxy level.

Why this answer

PeerAuthentication enforces mTLS on the server side, and DestinationRule configures the client side. Both are used together for comprehensive mTLS enforcement.

Practice this question →

MCQhard

An administrator wants to use OPA Gatekeeper to enforce that all pods have a resource limits section defined. Which of the following is the correct combination to implement this policy?

A.Create a NetworkPolicy to block pods without limits.

B.Create a MutatingWebhookConfiguration to add resource limits automatically.

C.Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.

D.Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.

AnswerD

Gatekeeper uses ConstraintTemplate (Rego) and Constraint to enforce policies. The Rego policy inspects the resource limits.

Practice this question →

MCQmedium

You are implementing a policy to ensure all containers in a namespace run as non-root. Which of the following is the most appropriate approach to enforce this at the cluster level?

A.Create a PodSecurityPolicy that requires runAsNonRoot

B.Use OPA/Gatekeeper with a ConstraintTemplate that checks runAsNonRoot is set to true

C.Set runAsNonRoot in the securityContext of each Pod spec manually

D.Configure a ValidatingAdmissionPolicy with a CEL rule requiring runAsNonRoot

AnswerB

OPA/Gatekeeper can enforce policies via admission webhooks, and a ConstraintTemplate can validate that all containers have runAsNonRoot: true.

Why this answer

OPA/Gatekeeper uses ConstraintTemplates and Constraints to enforce policies like requiring runAsNonRoot. A PodSecurityPolicy is deprecated. A ValidatingAdmissionPolicy is a beta feature that could be used but is less common than OPA/Gatekeeper for this purpose.

Configuring each Pod manually is not scalable. Setting runAsNonRoot in the PodSecurityContext only applies to that specific pod, not enforced cluster-wide.

Practice this question →

MCQmedium

You need to create a NetworkPolicy that denies all ingress traffic to pods with label 'app: web' in the 'frontend' namespace, except for traffic from pods with label 'app: ingress' in the 'ingress' namespace. Which NetworkPolicy spec correctly achieves this?

A.ingress: - from: - namespaceSelector: matchLabels: name: ingress podSelector: matchLabels: app: ingress

B.ingress: - from: - namespaceSelector: matchLabels: app: ingress podSelector: {}

C.ingress: - from: - podSelector: matchLabels: app: ingress - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress

D.ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress podSelector: matchLabels: app: ingress

AnswerD

This allows ingress only from pods matching both selectors; default deny is implied if no other rules.

Practice this question →

MCQeasy

Which command can be used to view the current set of admission webhooks in the cluster?

A.kubectl get webhooks

B.kubectl get validatingwebhookconfigurations

C.kubectl get webhookconfigurations

D.kubectl get admissionwebhooks

AnswerB

This lists the ValidatingWebhookConfiguration resources, which define the webhooks.

Why this answer

ValidatingWebhookConfiguration and MutatingWebhookConfiguration are cluster-scoped resources that can be listed with kubectl get.

Practice this question →

MCQmedium

An administrator deploys a Pod with the following security context: securityContext: runAsNonRoot: true runAsUser: 1000 However, the Pod fails to start with an error: 'container has runAsNonRoot and image will run as root'. What is the most likely cause?

A.The container runtime does not support runAsNonRoot

B.The pod is missing a seccomp profile

C.The runAsUser field is set to 1000, which is a non-root user

D.The container image specifies USER root in its Dockerfile

AnswerD

runAsNonRoot: true checks the image's default user; if the image runs as root (USER root), the pod is rejected even if runAsUser: 1000 is set.

Why this answer

runAsNonRoot: true requires that the image's default user is not root (UID 0). Even though runAsUser overrides the user, the validation checks the image's USER directive first.

Practice this question →

MCQmedium

A security scanner reports that a microservice container image contains a critical vulnerability (CVE-2024-1234) in a system library. The team cannot immediately rebuild the image. What is the most effective temporary mitigation at the Kubernetes level?

A.Apply a NetworkPolicy to block egress traffic from the Pod

B.Apply a custom seccomp profile that blocks the vulnerable syscall

C.Apply an AppArmor profile to the Pod

D.Use a PodSecurityPolicy to drop all capabilities

AnswerB

Seccomp can filter system calls, directly mitigating exploitation of syscall-related CVEs.

Why this answer

Option B is correct because a custom seccomp (secure computing mode) profile can restrict the system calls (syscalls) a container is allowed to make. By blocking the specific vulnerable syscall exploited by CVE-2024-1234, you can prevent the vulnerability from being triggered at runtime without rebuilding the image. This is a temporary, Kubernetes-native mitigation that directly addresses the attack vector at the syscall level.

Exam trap

CNCF often tests the distinction between seccomp (syscall filtering) and AppArmor/SELinux (MAC on files and capabilities), leading candidates to confuse AppArmor as a syscall blocker when it is not.

How to eliminate wrong answers

Option A is wrong because blocking egress traffic with a NetworkPolicy only prevents outbound network connections; it does not prevent exploitation of a local system library vulnerability, which typically does not require network egress. Option C is wrong because AppArmor profiles enforce mandatory access control (MAC) on file paths, network, and capabilities, but they do not filter syscalls; seccomp is the correct mechanism for syscall-level restriction. Option D is wrong because dropping all capabilities with a PodSecurityPolicy (or Pod Security Admission) removes Linux capabilities like CAP_NET_RAW, but it does not block specific syscalls; the vulnerable syscall may still be invoked even with no capabilities.

Practice this question →

MCQmedium

You have enabled encryption at rest for Kubernetes Secrets by configuring an EncryptionConfiguration object and restarting the API server. After the configuration, you create a new Secret. However, when you retrieve the Secret using 'kubectl get secret mysecret -o yaml', the 'data' field still shows base64-encoded plaintext. Is the Secret encrypted at rest?

A.No, because only Secrets in namespaces with a specific annotation are encrypted.

B.Yes, but only if the Secret was created after the API server restart.

C.No, because the data is still visible in the API response.

D.Yes, because encryption at rest applies to the storage layer (etcd), not the API response.

AnswerD

EncryptionConfiguration encrypts data written to etcd; the API server decrypts it when serving requests.

Practice this question →

MCQmedium

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

B.PeerAuthentication with mTLS mode set to STRICT

C.VirtualService with tls configuration

D.ServiceEntry with mTLS enabled

AnswerB

PeerAuthentication defines the mTLS mode for workloads. Setting mode: STRICT enforces mTLS.

Practice this question →

MCQmedium

A security best practice is to avoid storing sensitive data in environment variables. Instead, secrets should be mounted as volumes. Which of the following YAML snippets correctly mounts a Kubernetes Secret named 'db-secret' as a volume at /etc/secrets?

A.volumes: - name: secret-volume secret: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets

B.volumes: - name: secret-volume configMap: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets

C.volumes: - name: secret-volume secret: secretName: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets

D.containers: - name: app env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

AnswerC

This correctly defines a secret volume and mounts it at /etc/secrets.

Why this answer

Option A shows the correct syntax for mounting a secret as a volume. Option B uses ConfigMap, C has wrong field name, D uses env var.

Practice this question →

Multi-Selecthard

Which THREE of the following are characteristics of container sandboxing runtimes like gVisor and Kata Containers?

Select 3 answers

A.They eliminate the need for seccomp profiles

B.They require setting spec.runtimeClassName in the pod spec

C.They have higher performance overhead compared to runc

D.They share the host kernel directly

E.They provide stronger isolation than default runc

AnswersB, C, E

To use a specific runtime, you set runtimeClassName to a RuntimeClass that defines the handler.

Why this answer

They provide stronger isolation than default runc, have performance overhead, and are selected via RuntimeClass. They do not share the host kernel directly; Kata uses a lightweight VM, gVisor uses a user-space kernel.

Practice this question →

MCQmedium

A cluster administrator has configured EncryptionConfiguration to encrypt secrets at rest using a local key. After applying the configuration, the administrator creates a new secret. How can they verify that the secret is encrypted at rest?

A.Run kubectl get secret -o yaml and check for an encryption annotation.

B.Use kubectl describe secret and look for 'Encrypted: true'.

C.Check the apiserver logs for encryption status messages.

D.Use etcdctl to read the secret directly from etcd and verify it is encrypted.

AnswerD

Directly reading from etcd shows the encrypted value, verifying encryption at rest.

Why this answer

The encryption is transparent to clients; you can verify by reading the raw data from etcd or enabling audit logging. Option A is correct: direct etcd access shows encrypted data.

Practice this question →

MCQhard

You are writing a Rego policy for OPA/Gatekeeper to deny pods that do not have runAsNonRoot set to true. Which Rego statement should the ConstraintTemplate contain?

A.violation[msg] { not input.request.object.spec.securityContext.runAsNonRoot == true }

B.deny[msg] { input.request.object.spec.securityContext.runAsNonRoot == true }

C.allow[msg] { input.request.object.spec.securityContext.runAsNonRoot == false }

D.deny[msg] { input.request.object.spec.containers[_].securityContext.runAsNonRoot == true }

AnswerA

This triggers a violation when runAsNonRoot is not true.

Why this answer

Deny rules in Rego return false to reject the request. A violation is typically a rule that evaluates to true when the policy is violated. The deny or violation rule must return true if the condition is not met.

Option B correctly checks that runAsNonRoot is not true and returns true (violation).

Practice this question →

MCQeasy

Which kubectl command creates a validating webhook configuration that calls an external HTTPS endpoint for pod validation?

A.kubectl create admission webhook --validate

B.kubectl run webhook --image=...

C.kubectl apply -f webhook.yaml

D.kubectl create validatingwebhookconfiguration --url=https://...

AnswerC

Correct. The ValidatingWebhookConfiguration is defined in a YAML file and applied with kubectl apply.

Why this answer

The correct way is to create a YAML file for a ValidatingWebhookConfiguration resource and apply it with kubectl apply. There is no kubectl create command for webhook configurations directly; you must use a manifest.

Practice this question →

Multi-Selectmedium

Which TWO of the following are secure practices for managing secrets in Kubernetes? (Select TWO.)

Select 2 answers

A.Store secrets as environment variables

B.Use a CSI driver to mount secrets as volumes

C.Embed secrets in container images

D.Use an external secrets manager like Vault with a sidecar

E.Store secrets in a ConfigMap

AnswersB, D

Correct.

Why this answer

Mounting secrets as volumes and using external secret managers like HashiCorp Vault are recommended practices.

Practice this question →

MCQhard

You have a Pod that uses a ServiceAccount token mounted via a projected volume. You want to ensure that the token has an expiration time and that the pod is not using a long-lived token. What is the most secure way to mount the token?

A.Mount the default service account token at /var/run/secrets/kubernetes.io/serviceaccount

B.Use a projected volume with 'serviceAccountToken' and set 'expirationSeconds'

C.Set automountServiceAccountToken: false and manually mount a Secret containing a token

D.Use a ConfigMap to inject the token

AnswerB

Projected volumes allow you to request a time-bound token.

Practice this question →

MCQmedium

Which of the following is the correct kubectl command to view the OPA Gatekeeper ConstraintTemplates in the cluster?

A.kubectl get gatekeeper-constrainttemplates

B.kubectl describe opa constrainttemplate

C.kubectl get constrainttemplates

D.kubectl get crd -o name | grep constraint

AnswerC

This lists all ConstraintTemplate resources.

Why this answer

Option B is correct. Gatekeeper ConstraintTemplates are custom resources, typically listed with `kubectl get constrainttemplates`. Option A uses an incorrect resource name.

Option C uses a different command. Option D is a generic command that might not list all ConstraintTemplates.

Practice this question →

MCQhard

You are using Open Policy Agent (OPA) Gatekeeper to enforce pod security. You want to create a constraint that denies pods unless they have readOnlyRootFilesystem set to true. Which Rego rule in a ConstraintTemplate correctly implements this?

A.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.readOnlyRootFilesystem == true msg := "readOnlyRootFilesystem must be true" }

B.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.readOnlyRootFilesystem msg := "readOnlyRootFilesystem must be true" }

C.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.readOnlyRootFilesystem == false msg := "readOnlyRootFilesystem must be true" }

D.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.readOnlyRootFilesystem == false msg := "readOnlyRootFilesystem must be true" }

AnswerB

Correctly denies when readOnlyRootFilesystem is not set or false.

Why this answer

The Rego rule should deny when the violation condition holds: the pod spec contains a container without readOnlyRootFilesystem set to true. Option C uses 'not input.review.object.spec.containers[_].securityContext.readOnlyRootFilesystem' to detect missing true.

Practice this question →

MCQeasy

Which of the following is a characteristic of Kata Containers compared to gVisor?

A.Kata Containers require no additional configuration in Kubernetes

B.Kata Containers have lower overhead than gVisor

C.Kata Containers use lightweight VMs to isolate containers

D.Kata Containers provide a user-space kernel that intercepts system calls

AnswerC

Kata Containers run each container in its own VM for strong isolation.

Why this answer

Option B is correct. Kata Containers use lightweight virtual machines to provide strong isolation, while gVisor uses a user-space kernel for sandboxing. Option A is true for gVisor, not Kata.

Option C is not correct; both have overhead. Option D is not correct; both have similar integration complexity.

Practice this question →

MCQmedium

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

A.Use environment variables in the pod spec to pass secrets

B.Mount secrets as volumes in the pod

C.Embed secrets as literals in the pod YAML file

D.Store them in ConfigMaps

AnswerB

Mounting as volumes reduces the risk of exposure through environment variables.

Why this answer

Option C is correct. Mounting secrets as volumes is more secure than using environment variables because secrets are not exposed in the process list or logs. Option A is insecure.

Option B is insecure. Option D is not a standard practice.

Practice this question →

MCQeasy

A DevOps engineer wants to ensure that all microservice containers run with a read-only root filesystem to prevent unauthorized writes. What is the simplest way to enforce this at the Pod level?

A.Set `securityContext.runAsNonRoot: true` in the Pod spec

B.Mount an emptyDir volume to the container's writable directories

C.Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec

D.Set `securityContext.privileged: false` in the Pod spec

AnswerC

This directly enforces a read-only root filesystem for all containers in the Pod.

Why this answer

Option C is correct because setting `securityContext.readOnlyRootFilesystem: true` in the Pod spec directly enforces that the container's root filesystem is read-only, preventing any unauthorized writes to the root filesystem. This is the simplest and most direct way to achieve the requirement at the Pod level, as it applies to all containers in the Pod unless overridden at the container level.

Exam trap

CNCF often tests the distinction between security contexts that control user identity (runAsNonRoot) versus those that control filesystem permissions (readOnlyRootFilesystem), and the trap here is that candidates may confuse 'non-root' with 'read-only' or assume that disabling privileged mode is sufficient to prevent writes.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only ensures the container runs as a non-root user, but does not restrict writes to the root filesystem; a non-root user can still write to writable directories. Option B is wrong because mounting an emptyDir volume to writable directories is a workaround to allow specific writes while keeping the root filesystem read-only, but it does not enforce the read-only root filesystem itself; the root filesystem remains writable unless explicitly set to read-only. Option D is wrong because `privileged: false` is the default and simply disables privileged mode, but it does not prevent writes to the root filesystem; a non-privileged container can still modify the root filesystem if it is not explicitly set to read-only.

Practice this question →

MCQmedium

In an Istio service mesh, you want to enforce mutual TLS (mTLS) between services in a specific namespace. Which resource should you create to set the default mTLS mode to STRICT for all workloads in that namespace?

A.PeerAuthentication

B.VirtualService

C.ServiceEntry

D.DestinationRule

AnswerA

PeerAuthentication defines mTLS policy for workloads; setting mode: STRICT enforces mTLS.

Practice this question →

MCQmedium

A cluster administrator needs to run a workload that uses gVisor (runsc) for container sandboxing. Which Kubernetes resource is required to enable this?

A.RuntimeClass

B.PriorityClass

C.NetworkPolicy

D.PodSecurityPolicy

AnswerA

RuntimeClass allows selecting a different container runtime, such as gVisor.

Why this answer

RuntimeClass specifies the container runtime to use for pods. It must be defined and referenced in the pod spec. PodSecurityPolicy is deprecated.

PriorityClass is for scheduling priority. NetworkPolicy is for network rules.

Practice this question →

MCQmedium

Which of the following commands creates a ValidatingWebhookConfiguration that uses an OPA Gatekeeper webhook?

A.kubectl apply -f validatingwebhook.yaml where the webhook's service reference points to the gatekeeper-validating-webhook service.

B.kubectl apply -f constraint.yaml with a ConstraintTemplate.

C.kubectl create validatingwebhook gatekeeper --from-file=webhook.yaml

D.kubectl run gatekeeper-webhook --image=openpolicyagent/gatekeeper:v3.14.0

AnswerA

Gatekeeper registers a ValidatingWebhookConfiguration that points to its service.

Practice this question →

MCQhard

To encrypt secrets at rest in Kubernetes, an administrator configures an EncryptionConfiguration. What is the correct flag to pass to the kube-apiserver to use this configuration?

A.--encryption-provider-config=/path/to/config.yaml

B.--feature-gates=EncryptionAtRest=true

C.--encryption-key=/path/to/config.yaml

D.--encryption-config=/path/to/config.yaml

AnswerA

The --encryption-provider-config flag specifies the path to the EncryptionConfiguration file.

Why this answer

The kube-apiserver uses --encryption-provider-config to load the EncryptionConfiguration YAML file that defines how etcd data is encrypted.

Practice this question →

MCQhard

An admin creates the following EncryptionConfiguration to encrypt secrets at rest. After applying it, what must the admin do to ensure existing secrets are encrypted?

A.Re-create the existing secrets

B.Restart the kube-apiserver

C.Delete the existing secrets and wait for them to be recreated automatically

D.Nothing, the existing secrets are automatically encrypted

AnswerA

Existing secrets are not automatically encrypted; they must be re-created to be encrypted.

Why this answer

The EncryptionConfiguration only encrypts newly created secrets. Existing secrets must be re-created (e.g., by replacing them) to be encrypted. The kube-apiserver does not automatically rewrite existing resources.

Practice this question →

MCQeasy

An admin runs 'kubectl get pod web -o yaml' and sees the following security context. Which setting prevents privilege escalation?

A.allowPrivilegeEscalation: false

B.Both B and C

C.runAsNonRoot: true

D.capabilities: drop: [ALL]

AnswerA

This setting explicitly disallows privilege escalation.

Why this answer

allowPrivilegeEscalation: false directly prevents processes from gaining more privileges than their parent. Dropping all capabilities reduces attack surface but does not itself prevent privilege escalation. runAsNonRoot ensures the container does not run as root but does not prevent escalation if the container could still gain capabilities.

Practice this question →

MCQeasy

Which field in a Pod's securityContext prevents privilege escalation by the container?

A.capabilities.add: ["SYS_ADMIN"]

B.runAsNonRoot

C.allowPrivilegeEscalation

D.privileged

AnswerC

Setting allowPrivilegeEscalation: false prevents privilege escalation inside the container.

Why this answer

Option C is correct. `allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent. Setting it to false prevents escalation. Option A controls whether the container has root privileges.

Option B controls if the container is a privileged container. Option D controls if the container can gain privileges, but the specific field is `allowPrivilegeEscalation`.

Practice this question →

MCQhard

A pod fails to start with the error 'Container runtime network not ready', and the node uses Kata Containers (RuntimeClass: kata). What is the most likely cause?

A.The node has insufficient memory

B.The pod is trying to mount a hostPath volume

C.The CNI plugin is not configured correctly for the kata RuntimeClass

D.The pod's securityContext sets runAsNonRoot: true

AnswerC

Kata requires specific CNI configuration; misconfiguration leads to network not ready.

Why this answer

Kata Containers run inside a lightweight VM with its own kernel. Network configuration can be complex, and if the CNI plugin is not properly configured for Kata, the network may not be ready.

Practice this question →

Multi-Selectmedium

Which TWO actions help minimize vulnerabilities in microservices by securing secrets? (Choose two)

Select 2 answers

A.Base64 encode the secret in the YAML manifest

B.Set the secret as a label on the pod

C.Mount Secrets as volumes instead of environment variables

D.Use an external secrets manager like HashiCorp Vault

E.Store secrets in ConfigMaps to leverage ConfigMap encryption

AnswersC, D

Mounting as volumes reduces exposure in process listing and logs.

Why this answer

Best practices for secrets include mounting as volumes (avoiding environment variables) and using external secret management solutions for enhanced security features.

Practice this question →

Drag & Dropmedium

Order the steps to configure and apply a NetworkPolicy to restrict pod-to-pod traffic.

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

Steps

Order

Why this order

NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid methods to restrict a container's filesystem to read-only in Kubernetes?

Select 2 answers

A.Use a ConfigMap volume with defaultMode 0444

B.Set readOnly: true on a hostPath volume mount

C.Set readOnlyRootFilesystem: true in the container's securityContext

D.Mount an emptyDir volume with readOnly: true

AnswersC, D

This makes the container's root filesystem read-only.

Why this answer

Setting readOnlyRootFilesystem: true in the container securityContext makes the root filesystem read-only. Using an emptyDir volume with readOnly: true mounts an emptyDir as read-only, but the root filesystem remains writable. hostPath is not read-only by default. ConfigMap volumes are typically mounted read-only by default, but the question asks about restricting the container's filesystem.

Option A directly makes the root filesystem read-only. Option D also works by mounting a volume read-only, but it does not restrict the root filesystem. However, the question says 'restrict a container's filesystem to read-only' which can include specific mounts.

The intended correct answers are A and D. (Note: In many contexts, 'filesystem' refers to the root filesystem, but volumes are also part of the filesystem.)

Practice this question →

MCQhard

An admin has created an EncryptionConfiguration to encrypt secrets at rest in etcd. After applying the configuration and restarting the kube-apiserver, existing secrets are still stored in plaintext. What is the most likely reason?

A.The encryption provider is set to 'identity' which does not encrypt

B.The kube-apiserver was not restarted after applying the configuration

C.Existing secrets are not automatically encrypted; they need to be rewritten by reading and writing them back

D.The EncryptionConfiguration has a syntax error that caused it to be ignored

AnswerC

EncryptionConfiguration only encrypts new writes; existing data remains as-is until rewritten.

Why this answer

Option A is correct. By default, Kubernetes does not rewrite existing resources when encryption is enabled. To encrypt existing secrets, the admin must use `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` to rewrite them.

Option B would cause errors. Option C is wrong because the encryption provider is used for new writes. Option D is wrong because the configuration is correct.

Practice this question →

MCQmedium

A cluster administrator wants to ensure that all pods in a namespace run with the `seccomp` profile set to `RuntimeDefault`. Which OPA Gatekeeper ConstraintTemplate would achieve this?

A.violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.containers[_].securityContext.seccompProfile.type == "Unconfined" }

B.violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.containers[_].securityContext.seccompProfile == "RuntimeDefault" }

C.violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.securityContext.seccompProfile.type != "RuntimeDefault" }

D.violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.containers[_].securityContext.seccompProfile.type != "RuntimeDefault" }

AnswerD

This denies pods that do not have the required seccomp profile.

Why this answer

The correct Rego policy checks that the container's securityContext has `seccompProfile.type: RuntimeDefault`. Option A does this correctly.

Practice this question →

MCQmedium

A DevOps team deploys a microservice that needs to access a third-party API using credentials stored in a Kubernetes Secret. The team wants to minimize the risk of credential exposure. Which approach best achieves this goal while following security best practices?

A.Store the credentials in a Secret and mount it as a volume with default permissions.

B.Store the credentials in a Secret, mount it as a read-only volume, and use a dedicated service account with RBAC limiting access to that secret.

C.Use a sidecar container that reads the secret from a file and exposes it via a Unix socket, running the container as root.

D.Store the credentials in a ConfigMap and inject them as environment variables.

AnswerB

Read-only volume prevents modification, dedicated service account with RBAC ensures only the specific pod can access the secret, minimizing exposure.

Why this answer

Option B is correct because mounting the Secret as a read-only volume prevents runtime modification, and using a dedicated service account with RBAC ensures only the specific microservice can access the Secret. This follows the principle of least privilege and minimizes exposure, as the credentials are never injected as environment variables (which can be leaked via /proc or logs) and are only available to the intended pod.

Exam trap

CNCF often tests the misconception that environment variables are safe for secrets, but the trap here is that environment variables can be exposed via `/proc/self/environ`, logs, or debug endpoints, making volume mounts with strict permissions and RBAC the more secure choice.

How to eliminate wrong answers

Option A is wrong because mounting a Secret with default permissions (typically 0644) allows other processes on the node to read the secret files, increasing exposure risk. Option C is wrong because running the sidecar container as root violates the principle of least privilege and could allow privilege escalation; a Unix socket approach adds complexity without addressing the core credential exposure issue. Option D is wrong because ConfigMaps are not designed for sensitive data—they lack encryption at rest and are often stored in plaintext in etcd, making credentials vulnerable to exposure.

Practice this question →

MCQeasy

Which of the following is a MutatingAdmissionWebhook that is built into Kubernetes and can automatically inject a sidecar proxy for service mesh?

A.PodSecurity admission controller

B.Istio sidecar injector

C.Cert-manager

D.Gatekeeper

AnswerB

Istio uses a mutating admission webhook to automatically inject the Envoy sidecar proxy into pods.

Why this answer

Istio’s sidecar injector is a mutating webhook that modifies pod specs to add the Envoy proxy sidecar.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid Pod Security Context settings to harden a container? (Select 2)

Select 2 answers

A.privileged: true

B.runAsUser: 0

C.runAsNonRoot: true

D.readOnlyRootFilesystem: true

E.allowPrivilegeEscalation: true

AnswersC, D

Prevents running as root user.

Why this answer

runAsNonRoot: true (option A) ensures the container does not run as root. readOnlyRootFilesystem: true (option C) prevents writes to the root filesystem. Option B (privileged: true) is insecure. Option D (runAsUser: 0) runs as root.

Option E (allowPrivilegeEscalation: true) allows privilege escalation.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid approaches to enforce that all pods in a cluster run with a read-only root filesystem? (Select THREE)

Select 3 answers

A.Deploy a ValidatingWebhookConfiguration that checks for readOnlyRootFilesystem: true

B.Use a Gatekeeper policy to drop all capabilities

C.Enable Pod Security Admission (PSA) with the 'restricted' profile

D.Deploy a MutatingWebhookConfiguration that adds readOnlyRootFilesystem: true to all pods

E.Apply a NetworkPolicy that denies egress

AnswersA, C, D

Validating webhooks can reject non-compliant pods.

Why this answer

Options A, B, and D are correct. A ValidatingWebhook can reject pods without readOnlyRootFilesystem. A MutatingWebhook can inject it.

Pod Security Admission (PSA) can enforce it via the 'restricted' profile. Option C is about dropping capabilities, not read-only root. Option E is for network policies.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid Rego keywords used in OPA policies for Gatekeeper? (Select TWO)

Select 2 answers

A.violation

B.allow

C.input

D.data

E.deny

AnswersC, E

input is a reserved variable in Rego representing the request data.

Practice this question →

MCQhard

You want to run a container with gVisor for sandboxing. After installing gVisor and creating a RuntimeClass named 'gvisor', which Pod configuration enables it?

A.Set spec.runtimeClassName: gvisor

B.Set spec.nodeSelector with 'gvisor: true'

C.Define an environment variable RUNTIME=gvisor in the container

D.Add an annotation 'container.runtime: gvisor' to the Pod

AnswerA

The runtimeClassName field in Pod spec selects the RuntimeClass resource, which points to the gVisor runtime handler.

Why this answer

RuntimeClass is a cluster resource that defines a container runtime configuration (e.g., gVisor, Kata). Pods specify which RuntimeClass to use via the runtimeClassName field.

Practice this question →

MCQeasy

A security engineer needs to ensure that all containers in a cluster run as non-root users. Which Pod Security Context field should be set to enforce this requirement?

A.runAsNonRoot: true

B.runAsUser: 1000

C.privileged: false

D.allowPrivilegeEscalation: false

AnswerA

runAsNonRoot: true prevents the container from running as root (UID 0). If the container tries to run as root, the Pod will not be admitted.

Why this answer

runAsNonRoot: true is the correct field to ensure containers cannot run as root. It is a Pod Security Context field that rejects pods whose container image specifies a root user or does not specify a user.

Practice this question →

MCQhard

You have deployed a service mesh with Istio and want to enforce mutual TLS (mTLS) for all traffic between services in the 'mesh' namespace. Which resource should you create?

A.A PeerAuthentication resource with mTLS mode set to STRICT and a namespace selector

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

C.A VirtualService with a rewrite rule to enforce TLS

D.A ServiceEntry to define external services

AnswerA

PeerAuthentication with mtls.mode: STRICT enforces mTLS for the selected namespace or workloads.

Why this answer

PeerAuthentication defines the mTLS mode for workloads. Setting mode to STRICT enforces that only mTLS traffic is accepted. DestinationRule can complement with client-side settings, but the primary enforcement is PeerAuthentication.

Practice this question →

MCQhard

A cluster has EncryptionConfiguration with aescbc provider. After rotating the encryption key, what must be done to re-encrypt existing Secrets with the new key?

A.Delete and recreate all Secrets

B.Restart the API server

C.Run 'kubectl encrypt secrets --key new-key'

D.Use 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'

AnswerD

Correct. This reads and rewrites all secrets, triggering re-encryption with the new key.

Why this answer

The 'kubectl replace' command triggers re-encryption by rewriting the resource.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to enable mTLS between services in a service mesh (e.g., Istio)?

Select 2 answers

A.Creating a DestinationRule with a trafficPolicy that sets tls mode to ISTIO_MUTUAL

B.Creating a ServiceEntry for the destination service

C.Creating a NetworkPolicy that allows ingress on port 443

D.Creating a PeerAuthentication resource with mTLS mode set to STRICT

E.Creating an AuthorizationPolicy with DENY action

AnswersA, D

DestinationRule can override mTLS settings for specific services.

Why this answer

In Istio, PeerAuthentication enables mTLS for traffic within the mesh, and DestinationRule can set the traffic policy for specific services. ServiceEntry is for external services, not internal mTLS. NetworkPolicy is for Kubernetes network policies, not mTLS.

AuthorizationPolicy is for access control, not transport security.

Practice this question →

MCQmedium

What is the purpose of the `allowPrivilegeEscalation: false` setting in a container's security context?

A.It prevents the container from running as root.

B.It prevents processes from gaining additional privileges (e.g., via setuid).

C.It prevents the container from using host networking.

D.It prevents the container from accessing host devices.

AnswerB

Correct: it disables privilege escalation.

Why this answer

This setting prevents processes in the container from gaining more privileges than their parent, such as via setuid binaries.

Practice this question →

Multi-Selectmedium

Which TWO of the following are effective measures to minimize the impact of a compromised microservice container in a Kubernetes cluster? (Choose two.)

Select 2 answers

A.Set resource limits (CPU/memory) on the container

B.Set the container's root filesystem as read-only

C.Apply a NetworkPolicy that restricts egress traffic to only necessary services

D.Run the container as root to simplify debugging

E.Use hostNetwork: true to share the host's network namespace

AnswersA, C

Resource limits prevent a compromised container from exhausting cluster resources.

Why this answer

Setting resource limits (CPU/memory) on a container is correct because it prevents a compromised microservice from consuming excessive cluster resources, which could lead to a denial-of-service (DoS) attack against other workloads. By enforcing limits via the container's cgroup constraints, the kernel throttles or OOM-kills the container if it exceeds its allocated resources, containing the blast radius of the compromise.

Exam trap

CNCF often tests the distinction between preventive controls (e.g., read-only filesystem, non-root user) and impact-minimization controls (e.g., resource limits, network policies), and candidates mistakenly choose read-only filesystem as an impact-minimization measure when it is actually a preventive measure.

Practice this question →

MCQhard

You need to encrypt Secrets at rest in an existing Kubernetes cluster. You create an EncryptionConfiguration file specifying aescbc as the provider. After updating the API server kube-apiserver.yaml with the new configuration, you create a new Secret. Which of the following statements is true?

A.Only newly created secrets will be encrypted; existing secrets remain unencrypted.

B.The encryption key is automatically rotated every 30 days.

C.The aescbc provider can be changed to identity without any impact on existing secrets.

D.All existing secrets in the cluster are automatically encrypted after the API server restart.

AnswerA

EncryptionConfiguration applies at write time. Existing secrets stored in etcd remain unencrypted until they are modified.

Why this answer

EncryptionConfiguration only encrypts newly created or updated secrets. Existing secrets are not automatically encrypted unless they are rewritten. Option A is incorrect because existing secrets are not automatically encrypted.

Option C is incorrect because the key is not automatically rotated. Option D is incorrect because the encryption provider can be changed but would require rewriting existing secrets.

Practice this question →