CCNA Minimize Microservice Vulnerabilities Questions

43 of 193 questions · Page 3/3 · Minimize Microservice Vulnerabilities · Answers revealed

151
MCQhard

You are using External Secrets Operator to sync secrets from HashiCorp Vault. The operator is deployed but secrets are not being created. Which resource defines the mapping between Vault secrets and Kubernetes secrets?

A.ClusterSecretStore
B.ExternalSecret
C.VaultSecret
D.SecretStore
AnswerB

Correct. The ExternalSecret resource defines the source (Vault path) and the target Kubernetes secret name.

Why this answer

External Secrets Operator uses a custom resource called ExternalSecret (or sometimes SecretStore depending on the version) to define the mapping. The ExternalSecret resource specifies the backend (Vault) and the secret keys to sync.

152
MCQhard

You are a platform engineer at a financial services company. The production cluster runs a set of microservices that handle sensitive customer data. The cluster has been configured with Pod Security Standards (PSS) enforced via OPA/Gatekeeper. Recently, the security team identified that a new deployment of the `payment-processing` microservice is running with the `seccomp` profile set to `Unconfined`. This violates the company policy that requires all containers to use a runtime default seccomp profile. The deployment YAML does not explicitly set any security context for seccomp. The cluster's nodes are running containerd 1.6 with default seccomp profile enabled. The OPA constraint template checks that `securityContext.seccompProfile.type` is set to `RuntimeDefault` or `Localhost`. However, the deployment passes the OPA validation. What is the most likely reason the deployment is not being rejected by OPA, and how should you fix it?

A.The seccomp profile must be set via an admission controller, not OPA.
B.OPA/Gatekeeper is not properly installed or the constraint is not active.
C.The cluster's nodes do not support seccomp, so the profile is ignored.
D.The OPA constraint only checks pod-level `securityContext`, but the deployment uses container-level settings.
AnswerD

The constraint should iterate over containers in the pod spec to enforce seccomp at the container level.

Why this answer

Option D is correct because the OPA constraint template checks `securityContext.seccompProfile.type` at the pod level, but the deployment does not set any security context at the pod level. The seccomp profile is only set at the container level (or defaults to `Unconfined` by the runtime), and the OPA constraint does not inspect container-level `securityContext`. This mismatch allows the deployment to pass validation even though the container is running with an unconfined seccomp profile.

Exam trap

The trap here is that candidates assume OPA constraints automatically check all levels of securityContext, but they must be explicitly written to inspect container-level settings, and the default behavior of the runtime can lead to a false sense of security.

How to eliminate wrong answers

Option A is wrong because OPA/Gatekeeper can enforce seccomp profiles via constraints; admission controllers are not required for seccomp enforcement. Option B is wrong because the scenario states the cluster is configured with PSS enforced via OPA/Gatekeeper, and the constraint is active (it checks pod-level securityContext), so the issue is not installation or activation. Option C is wrong because the nodes run containerd 1.6 with default seccomp profile enabled, so seccomp is supported and the profile is not ignored.

153
MCQmedium

An administrator deploys a Gatekeeper ConstraintTemplate with the following Rego policy: package k8srequiredlabels deny[{"msg": msg}] { input.request.kind.kind == "Pod" not input.request.object.metadata.labels["security-tier"] msg := "Pod must have label 'security-tier'" } After creating the Constraint, a user creates a Pod without the 'security-tier' label. What is the expected behavior?

A.The pod is created and the label is automatically added
B.The pod creation is denied with a message
C.Only the first pod without the label is denied; subsequent ones are allowed
D.The pod is created but logged as a violation
AnswerB

Correct. The deny rule blocks admission and returns the message.

Why this answer

Gatekeeper denies the request because the Rego policy denies pods missing the required label.

154
Multi-Selecthard

Which THREE of the following are true about Istio PeerAuthentication? (Select THREE.)

Select 3 answers
A.It can be used to enable mTLS for all workloads in a namespace
B.It configures how traffic is routed between services
C.It can specify TLS mode as STRICT, PERMISSIVE, or DISABLE
D.It requires a DestinationRule to define the TLS settings
E.It can be applied to specific workloads using label selectors
AnswersA, C, E

Correct.

Why this answer

PeerAuthentication defines mTLS mode at namespace or workload level, can be set to STRICT to require mTLS, and can override mesh-wide settings.

155
MCQmedium

A cluster administrator wants to audit all pod creations and modifications using an admission webhook. Which resource type should be created to register the webhook?

A.ValidatingWebhookConfiguration
B.WebhookConfiguration
C.MutatingWebhookConfiguration
D.AdmissionWebhook
AnswerA

ValidatingWebhookConfiguration is used to register admission webhooks that can validate requests (allow/deny) based on custom logic.

Why this answer

ValidatingWebhookConfiguration is used for admission webhooks that validate (allow/deny) requests without modifying them.

156
MCQeasy

In the context of service mesh (e.g., Istio), which resource is used to enforce mutual TLS (mTLS) between services in a specific namespace?

A.PeerAuthentication
B.VirtualService
C.DestinationRule
D.ServiceEntry
AnswerA

Defines mTLS settings for workloads.

Why this answer

Option A is correct. PeerAuthentication is the Istio resource that defines the mTLS mode for workloads. DestinationRule is for traffic policies, not mTLS enforcement.

VirtualService is for routing. ServiceEntry is for external services.

157
Multi-Selectmedium

Which TWO of the following are valid arguments for the kubectl command to create a secret from a file? (Select TWO)

Select 2 answers
A.--dry-run
B.--from-literal
C.--from-yaml
D.--from-file
E.--from-env-file
AnswersB, D

Creates secret from literal key-value pairs.

Why this answer

Options A and C are correct. '--from-file' creates a secret from a file; '--from-literal' from a literal string. Option B is for ConfigMaps. Option D is not a valid flag.

Option E is for a different purpose.

158
MCQeasy

Which field must be set in a Pod's security context to prevent the container from running as the root user?

A.runAsUser: 1000
B.readOnlyRootFilesystem: true
C.allowPrivilegeEscalation: false
D.runAsNonRoot: true
AnswerD

Correct. This ensures the container is not running as root.

Why this answer

The 'runAsNonRoot: true' field in the Pod's security context enforces that the container cannot run as UID 0 (root).

159
MCQhard

An OPA/Gatekeeper ConstraintTemplate is written to enforce that all Deployments have the label 'app.kubernetes.io/name'. However, the Constraint does not deny Deployments without the label. What is the most likely cause?

A.The Rego rule does not set 'violation' to true when the label is missing
B.The Constraint is not bound to any namespaces
C.The Deployment has the label set but with a different value
D.Gatekeeper is not installed in the cluster
AnswerA

Correct. The ConstraintTemplate must have a Rego rule named 'violation' that evaluates to true when the resource violates the policy.

Why this answer

Gatekeeper ConstraintTemplates use Rego to define violation rules. A common mistake is to use 'violation' with a generic message but not actually deny the request. The Rego must contain a 'deny' rule or use the 'violation' keyword correctly.

In Gatekeeper, the default Rego rule name is 'violation' and it must be set to true when a violation occurs. If the rule is empty or incorrectly written, it will not deny.

160
MCQhard

A cluster administrator wants to ensure that all Secrets are encrypted at rest using AES-CBC with a key managed by the local Kubernetes API server. Which configuration is required?

A.Enable etcd encryption by setting --experimental-encryption-provider-config
B.Use Secret resource's 'data' field with base64 encoding
C.Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'aescbc' provider
D.Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'identity' provider
AnswerC

Correct. This enables AES-CBC encryption at rest.

Why this answer

EncryptionConfiguration with a provider of type 'aescbc' is used for AES-CBC encryption at rest.

161
MCQmedium

Which Kubernetes admission controller is responsible for mutating and validating pod requests based on policies defined by OPA Gatekeeper?

A.PodSecurityPolicy
B.ValidatingAdmissionWebhook
C.ServiceAccount
D.NodeRestriction
AnswerB

Gatekeeper registers a ValidatingWebhookConfiguration to intercept and validate pod requests.

Why this answer

Gatekeeper uses the `ValidatingAdmissionWebhook` and `MutatingAdmissionWebhook` admission controllers. The question asks for the admission controller itself, which is `ValidatingAdmissionWebhook` for validation and `MutatingAdmissionWebhook` for mutation. Since OPA Gatekeeper primarily validates (though it can also mutate), the most directly involved admission controller for policy enforcement is ValidatingAdmissionWebhook.

162
MCQmedium

An administrator wants to enforce mutual TLS (mTLS) between all services in an Istio service mesh. Which resource should be configured?

A.AuthorizationPolicy
B.ServiceEntry
C.VirtualService
D.PeerAuthentication
AnswerD

PeerAuthentication is used to configure mTLS mode (STRICT, PERMISSIVE, DISABLE) for workloads.

Why this answer

Option A is correct. PeerAuthentication defines the traffic policy for mTLS within a namespace or mesh. Option B is for routing to external services.

Option C is for traffic routing. Option D is for authorization, not mTLS enforcement.

163
MCQeasy

You need to enforce that all containers in a namespace run with a read-only root filesystem. Which OPA Gatekeeper resource would you use to define the policy?

A.Constraint
B.ValidatingWebhookConfiguration
C.ConstraintTemplate
D.ConfigMap
AnswerC

ConstraintTemplate defines the Rego logic (rules) for the policy.

164
MCQeasy

A developer wants to run a container that reads a secret from a mounted volume, not as an environment variable. Which volume type should they use?

A.secret
B.emptyDir
C.hostPath
D.configMap
AnswerA

A secret volume mounts a Secret into the container's filesystem.

Why this answer

The secret volume type mounts a Kubernetes Secret as files into a container. ConfigMaps are for non-sensitive data. hostPath is for host filesystem. emptyDir is ephemeral.

165
Multi-Selecthard

Which THREE of the following are recommended practices for minimizing microservice vulnerabilities related to container security?

Select 3 answers
A.Set securityContext.runAsNonRoot: true
B.Drop all capabilities via securityContext.capabilities.drop: ["ALL"]
C.Set high CPU requests to ensure performance
D.Set securityContext.readOnlyRootFilesystem: true
E.Expose secrets as environment variables for convenience
AnswersA, B, D

Prevents the container from running as root, reducing the impact of a compromise.

Why this answer

Running as non-root, read-only root filesystem, and dropping all capabilities are recommended for least privilege. Setting CPU requests high does not reduce vulnerabilities; it may cause resource contention. Using secrets in environment variables is insecure as they can be exposed in logs or via /proc.

166
MCQeasy

Which of the following is a valid way to drop all capabilities from a container?

A.securityContext: dropCapabilities: true
B.securityContext: privileged: false
C.securityContext: capabilities: remove: ["ALL"]
D.securityContext: capabilities: drop: ["ALL"]
AnswerD

The drop field accepts an array of capabilities; "ALL" is a wildcard to drop all capabilities.

167
MCQmedium

A developer wants to ensure that all containers in a pod run with a read-only root filesystem except for a specific volume mounted for writing logs. Which container-level security context field should be set to true?

A.allowPrivilegeEscalation
B.readOnlyRootFilesystem
C.privileged
D.runAsNonRoot
AnswerB

This makes the root filesystem read-only, which is the correct setting.

Why this answer

The field `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which forces all writes to go to mounted volumes.

168
MCQhard

A pod is using a RuntimeClass that specifies gVisor (runsc). Which of the following scenarios is most likely to cause the pod to fail?

A.The pod runs a web server listening on port 8080.
B.The pod attempts to mount a hostPath directory with privileged access.
C.The pod mounts a ConfigMap as a volume.
D.The pod uses a PersistentVolumeClaim for storage.
AnswerB

gVisor restricts host access and may not allow privileged hostPath mounts, causing the pod to fail.

Why this answer

gVisor intercepts system calls and may not support all of them, especially ones that require direct hardware access. Option C is most likely to fail.

169
MCQeasy

You are a Kubernetes administrator for a fintech company that runs a payment processing service in a production cluster. The service consists of multiple microservices that communicate over the network. Recently, a security audit revealed that a compromised pod could potentially send malicious requests to other services because there are no network restrictions between pods. The security team has mandated that all inter-service traffic must be encrypted and authenticated, and that only necessary traffic should be allowed. You need to implement a solution that meets these requirements with minimal changes to the application code and minimal operational overhead. Which approach should you take?

A.Encrypt traffic by configuring TLS certificates in each pod's environment variables and updating the application code to use HTTPS.
B.Use Kubernetes NetworkPolicies to restrict pod-to-pod communication based on labels and namespaces, and enable TLS in each service's code.
C.Deploy Istio as a service mesh with mutual TLS enabled and configure AuthorizationPolicy resources to allow only required traffic between services.
D.Move all services to a separate overlay network using Weave Net and enforce egress rules with iptables on each node.
AnswerC

Istio provides transparent mTLS and fine-grained authorization without code changes, meeting all requirements.

Why this answer

Option C is correct because deploying Istio as a service mesh with mutual TLS (mTLS) provides transparent encryption and authentication of all inter-service traffic without modifying application code. Istio's AuthorizationPolicy resources allow fine-grained, label-based access control to enforce the principle of least privilege, meeting the security mandate with minimal operational overhead through sidecar proxy injection.

Exam trap

The trap here is that candidates may think NetworkPolicies alone satisfy the encryption requirement, but NetworkPolicies only filter traffic at L3/L4 and do not provide any encryption or authentication, which is explicitly required by the security audit.

How to eliminate wrong answers

Option A is wrong because configuring TLS certificates via environment variables and updating application code to use HTTPS requires significant code changes and does not address network-level restrictions; it also lacks centralized policy enforcement. Option B is wrong because while NetworkPolicies restrict traffic at the network layer, they do not provide encryption or authentication; enabling TLS in each service's code still requires application modifications and does not offer mutual authentication by default. Option D is wrong because moving services to a separate overlay network with Weave Net and enforcing egress rules via iptables adds complexity, does not encrypt traffic, and requires manual per-node configuration, failing to meet the minimal operational overhead requirement.

170
MCQhard

A pod is running with the following security context: ```yaml securityContext: allowPrivilegeEscalation: false runAsNonRoot: true seccompProfile: type: RuntimeDefault ``` The pod is in a CrashLoopBackOff. The logs show: "exec user process caused: operation not permitted". What is the most likely cause?

A.The container image is set to run as root, which conflicts with runAsNonRoot.
B.The container is missing the CAP_SYS_ADMIN capability.
C.The allowPrivilegeEscalation: false prevents the container from starting.
D.The seccomp profile is blocking necessary system calls.
AnswerA

runAsNonRoot: true requires the container to run as a non-root user. If the image defaults to root, the container fails to start.

171
MCQeasy

Which of the following is a valid approach to enforce that containers cannot escalate privileges?

A.Set securityContext.readOnlyRootFilesystem: true
B.Set securityContext.privileged: false
C.Set securityContext.capabilities.drop: ["ALL"]
D.Set securityContext.allowPrivilegeEscalation: false
AnswerD

allowPrivilegeEscalation: false prevents processes in the container from gaining more privileges than their parent process.

Why this answer

allowPrivilegeEscalation controls whether a process can gain more privileges than its parent. Setting it to false is the direct way to prevent privilege escalation.

172
MCQmedium

An administrator creates a Pod with the following securityContext: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 The container image has a binary that requires read/write access to /data, which is an emptyDir volume mounted by the Pod. The container fails to start with 'Permission denied' when writing to /data. What is the most likely cause?

A.The container's base image has a restrictive umask that overrides the pod's security context.
B.The fsGroup is set but the volume's fsGroupChangePolicy is missing.
C.The emptyDir volume is not writable by default; it needs to be explicitly configured.
D.The container is running as user 1000, but the volume is owned by root (uid 0) and the fsGroup 2000 does not give write permission.
173
MCQmedium

You need to enforce that all pods in the 'production' namespace run with read-only root filesystems. Which OPA Gatekeeper resource do you create first?

A.A ConfigMap containing the Rego policy, then reference it in a custom admission controller
B.A ConstraintTemplate containing a Rego policy that checks for readOnlyRootFilesystem: true
C.A Constraint resource that enforces the readOnlyRootFilesystem rule
D.A ValidatingWebhookConfiguration that points to the Gatekeeper service
AnswerB

ConstraintTemplate defines the Rego policy logic and parameters. It must be created before instantiating a Constraint.

Why this answer

In OPA Gatekeeper, the ConstraintTemplate defines the policy (Rego) and the schema for parameters. A Constraint instantiates the template with specific parameters. The ValidatingWebhookConfiguration is typically created by the Gatekeeper installation, not as a first step by the user.

174
MCQeasy

You need to ensure that all containers in a pod run as non-root. Which security context field should you set to enforce this?

A.privileged: false
B.readOnlyRootFilesystem: true
C.allowPrivilegeEscalation: false
D.runAsNonRoot: true
AnswerD

This field enforces that the container runs as a non-root user.

Why this answer

Setting runAsNonRoot: true in the security context enforces that the container runs as a non-root user; if the container attempts to run as root, it will be denied.

175
MCQeasy

Which kubectl command lists all MutatingWebhookConfigurations in the cluster?

A.kubectl get webhooks
B.kubectl list webhooks
C.kubectl get mutatingwebhookconfigurations
D.kubectl get mutating-webhooks
AnswerC

Correct.

Why this answer

The correct command is 'kubectl get mutatingwebhookconfigurations'.

176
MCQmedium

A security policy requires that all pods drop ALL Linux capabilities and disable privilege escalation. Which YAML snippet correctly implements this in the pod's security context?

A.securityContext: privileged: false capabilities: drop: ["ALL"]
B.securityContext: allowPrivilegeEscalation: false capabilities: add: ["NET_ADMIN"]
C.securityContext: capabilities: drop: ["ALL"]
D.securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"]
AnswerD

Correctly sets both fields.

Why this answer

The securityContext must include capabilities.drop with ALL and allowPrivilegeEscalation set to false. Option B has both.

177
MCQeasy

Which container runtime is specifically designed for sandboxing containers with a lightweight kernel?

A.Docker
B.containerd
C.gVisor (runsc)
D.runc
AnswerC

gVisor implements a user-space kernel for sandboxing.

Why this answer

Option B is correct. gVisor (runsc) provides a sandboxed kernel for containers. Kata Containers also provides sandboxing but uses a lightweight VM. Docker and containerd are general-purpose runtimes.

178
MCQmedium

In an Istio service mesh, you want to enforce mutual TLS (mTLS) between all services in the 'default' namespace. Which resource should you create?

A.PeerAuthentication with mTLS mode STRICT
B.Sidecar resource with outboundTrafficPolicy REGISTRY_ONLY
C.ServiceEntry with resolution NONE
D.DestinationRule with trafficPolicy tls mode ISTIO_MUTUAL
AnswerA

PeerAuthentication sets mTLS mode; STRICT requires mTLS for all traffic.

Why this answer

PeerAuthentication defines mTLS mode for workloads. DestinationRule can be used for traffic policies, but PeerAuthentication is the primary resource for mTLS enforcement. ServiceEntry is for external services.

Sidecar is for customizing the sidecar proxy.

179
MCQeasy

What is the primary purpose of using a service mesh like Istio for microservices security?

A.To replace Kubernetes NetworkPolicies for network segmentation.
B.To provide a centralized logging solution.
C.To automatically scale pods based on CPU usage.
D.To provide mTLS communication between services for encrypted and authenticated traffic.
AnswerD

One of the main features of a service mesh is to enable mTLS between services transparently.

180
MCQeasy

Which command correctly creates a secret from a file named 'config.json'?

A.kubectl create configmap my-secret --from-file=config.json
B.kubectl create secret generic my-secret --from-file=config.json
C.kubectl create secret tls my-secret --cert=config.json
D.kubectl create secret generic my-secret --from-literal=config.json
AnswerB

Correct. This creates a secret named my-secret with the file contents as the value, key defaults to 'config.json'.

Why this answer

The 'kubectl create secret generic' command with '--from-file' flag creates a secret from a file. The syntax is 'kubectl create secret generic <name> --from-file=<key>=<source>' or just '--from-file=<source>' where the key defaults to the filename.

181
MCQmedium

You need to run a container with a sandboxed runtime using gVisor (runsc). Which Kubernetes resource must be created first to enable this?

A.A RuntimeClass resource with handler: runsc
B.A PodSecurityPolicy that allows the runsc runtime
C.A ValidatingWebhookConfiguration to validate the runtime
D.A priorityClass with a high priority
AnswerA

RuntimeClass defines the container runtime to use for pods.

Why this answer

Option B is correct. A RuntimeClass resource must be defined to reference the gVisor runtime handler. The pod's spec then sets 'runtimeClassName' to that RuntimeClass.

Options A, C, and D are not required for using a runtime class.

182
MCQmedium

A security auditor requires that all pods in a cluster must not run as root. Which Pod Security Standard (PSS) and enforcement mode should be applied at the namespace level?

A.Baseline profile with enforce mode
B.Restricted profile with enforce mode
C.Baseline profile with warn mode
D.Privileged profile with audit mode
AnswerB

The Restricted profile requires runAsNonRoot: true, which prevents pods from running as root. Enforce mode rejects non-compliant pods.

Why this answer

The Restricted Pod Security Standard enforces runAsNonRoot: true, which is the requirement. Using enforce mode ensures that any pod violating this policy is rejected at admission.

183
MCQmedium

An administrator wants to enforce a policy that all containers must drop ALL capabilities and not allow privilege escalation. Which YAML snippet correctly implements this requirement in a PodSecurityPolicy-like manner using a security context? (Note: PodSecurityPolicy is deprecated; consider using a ValidatingAdmissionPolicy or OPA/Gatekeeper, but for this question choose the correct security context fields.)

A.securityContext: { privileged: false, capabilities: { drop: ["ALL"] } }
B.securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }
C.securityContext: { allowPrivilegeEscalation: false, capabilities: { add: ["ALL"] } }
D.spec: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }
AnswerB

Correctly sets both fields at the container security context level.

Why this answer

The correct approach is to set 'allowPrivilegeEscalation: false' and 'capabilities.drop: ["ALL"]' under the container's securityContext. This ensures no privilege escalation and drops all capabilities.

184
MCQmedium

You are deploying a microservice that must run as a non-root user and have a read-only root filesystem. Which two fields must be set in the PodSecurityContext or container SecurityContext?

A.allowPrivilegeEscalation: false
B.seLinuxOptions
C.runAsUser: 1000
D.readOnlyRootFilesystem: true
E.runAsNonRoot: true
AnswerD, E

Makes the container's root filesystem read-only.

Why this answer

The correct options are A and B. runAsNonRoot: true ensures the container runs as a non-root user; readOnlyRootFilesystem: true makes the root filesystem read-only. Option C is unrelated, D disables privilege escalation but does not enforce non-root/read-only root, and E is a deprecated field.

185
MCQmedium

An administrator wants to enforce that all containers in a Kubernetes cluster run as non-root and have read-only root filesystems using OPA/Gatekeeper. Which two resources must be created?

A.NetworkPolicy and RoleBinding
B.PodSecurityPolicy and ClusterRole
C.ValidatingWebhookConfiguration and MutatingWebhookConfiguration
D.ConstraintTemplate and Constraint
AnswerD

ConstraintTemplate contains the Rego policy; Constraint applies it to specific resources.

Why this answer

In OPA/Gatekeeper, a ConstraintTemplate defines the Rego logic (policy), and a Constraint instantiates that policy with specific parameters and scope. Pod Security Policies are deprecated; PodSecurity admission is a separate mechanism. ValidatingWebhookConfiguration is auto-managed by Gatekeeper.

186
MCQhard

You are writing a Rego policy for OPA Gatekeeper to deny pods that do not have 'runAsNonRoot: true' set in their security context. The ConstraintTemplate expects an input parameter 'runAsNonRoot' that is a boolean. Which Rego rule correctly denies such pods?

A.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "Container must run as non-root" } violation[{"msg": msg}] { pod := input.review.object not pod.spec.securityContext.runAsNonRoot msg := "Pod must run as non-root" }
B.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not has_field(container, "securityContext") or not container.securityContext.runAsNonRoot msg := "Container must set runAsNonRoot: true" }
C.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "Container must run as non-root" }
D.violation[{"msg": msg}] { pod := input.review.object not pod.spec.securityContext.runAsNonRoot msg := "Pod must run as non-root" }
187
Multi-Selecthard

Which THREE of the following are capabilities that should typically be dropped from a container to minimize vulnerabilities?

Select 3 answers
A.CHOWN
B.NET_ADMIN
C.NET_RAW
D.KILL
E.SETUID
AnswersB, C, E

Allows network administration; often dropped.

188
MCQeasy

To encrypt secrets at rest, which file must be modified on the control plane nodes?

A./etc/kubernetes/scheduler.conf
B./etc/kubernetes/manifests/kube-apiserver.yaml
C./etc/kubernetes/etcd.yaml
D./etc/kubernetes/kubelet.conf
AnswerB

This is the static pod manifest for the API server; you add the --encryption-provider-config flag here.

Why this answer

Option C is correct. The EncryptionConfiguration is a resource that is passed to the kube-apiserver via the --encryption-provider-config flag. The API server configuration is typically in a YAML file passed to the API server.

Options A and B are not relevant. Option D is for etcd.

189
MCQhard

A developer asks you to run a container with gVisor runtime. The cluster has a RuntimeClass named 'gvisor' defined. Which field must be added to the Pod spec to use gVisor?

A.spec.containers[0].runtimeClassName: gvisor
B.metadata.runtimeClassName: gvisor
C.spec.runtimeClass: gvisor
D.spec.runtimeClassName: gvisor
AnswerD

Correct.

Why this answer

The 'runtimeClassName' field in the Pod spec selects the RuntimeClass.

190
MCQhard

Which Istio resource is used to enforce mutual TLS (mTLS) for all services in a namespace, ensuring that traffic between services is encrypted?

A.DestinationRule
B.PeerAuthentication
C.ServiceEntry
D.VirtualService
AnswerB

PeerAuthentication defines mTLS settings for workloads in a namespace. Setting mode: STRICT enforces mTLS.

Why this answer

PeerAuthentication defines the traffic policy for mTLS within a namespace. Setting `mode: STRICT` enforces mTLS for all services in the namespace.

191
Matchingmedium

Match each Kubernetes object or feature to its primary security purpose.

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

Concepts
Matches

Provides an identity for processes running in a pod

Stores sensitive data such as passwords, OAuth tokens, and ssh keys

Stores non-sensitive configuration data in key-value pairs

Specifies security settings for a pod or container

Limits resource consumption per namespace to prevent resource exhaustion

Why these pairings

These objects are essential for managing security and resource constraints.

192
MCQmedium

A pod fails to start with 'CrashLoopBackOff'. The pod's YAML includes securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ['ALL'] } }. What is the likely cause?

A.The container image requires privilege escalation to run
B.The pod is missing a required environment variable
C.The node does not support seccomp profiles
D.The pod's service account lacks permissions to create pods
AnswerA

If the application needs to perform privileged operations (e.g., setuid binaries, syscalls), dropping all capabilities and disabling privilege escalation will cause it to fail.

Why this answer

Setting allowPrivilegeEscalation: false and dropping all capabilities restricts the container from gaining additional privileges. If the container image relies on any privileged operations (e.g., using ping or other setcap binaries), it will fail.

193
MCQhard

A Gatekeeper Constraint is not blocking pods that violate the policy. The constraint references a ConstraintTemplate that has been successfully created. What is the most likely cause?

A.The Constraint is missing the 'match' field
B.The Constraint has 'enforcementAction: dryrun'
C.The Constraint is in a different namespace than the pods
D.The ConstraintTemplate is missing the 'violation' rule
AnswerB

Dryrun mode logs violations but does not deny admission.

Why this answer

Option C is correct. In Gatekeeper, the enforcementAction defaults to 'deny', but if it is set to 'dryrun', violations are logged but not denied. Option A would cause the template to not be created; B would cause errors; D is not relevant.

← PreviousPage 3 of 3 · 193 questions total

Ready to test yourself?

Try a timed practice session using only Minimize Microservice Vulnerabilities questions.