How should I use these Minimize Microservice Vulnerabilities practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

CKS · topic practice

Minimize Microservice Vulnerabilities practice questions

Q: Can I practise just Minimize Microservice Vulnerabilities questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Minimize Microservice Vulnerabilities domain.

Practise Certified Kubernetes Security Specialist CKS Minimize Microservice Vulnerabilities practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Minimize Microservice Vulnerabilities

Practice 10 questions Browse domain →

What the exam tests

What to know about Minimize Microservice Vulnerabilities

Minimize Microservice Vulnerabilities questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Minimize Microservice Vulnerabilities exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Minimize Microservice Vulnerabilities questions

20 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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?

Trap 1: Store the API key in a ConfigMap and expose it as an environment…

ConfigMaps are for non-sensitive configuration data, not secrets.

Trap 2: Hardcode the API key in the container image

Hardcoding secrets in images is insecure and makes rotation impossible without rebuilding.

Trap 3: Store the API key in a Kubernetes Secret and expose it as an…

Environment variables from Secrets can be leaked through process dumps or logs.

Study all Minimize Microservice Vulnerabilities common traps →

A
Store the API key in a ConfigMap and expose it as an environment variable
Why wrong: ConfigMaps are for non-sensitive configuration data, not secrets.
B
Hardcode the API key in the container image
Why wrong: Hardcoding secrets in images is insecure and makes rotation impossible without rebuilding.
C
Store the API key in a Kubernetes Secret and mount it as a volume inside the container
Secrets are designed for sensitive data; volume mounts avoid exposure in environment variable listings.
D
Store the API key in a Kubernetes Secret and expose it as an environment variable
Why wrong: Environment variables from Secrets can be leaked through process dumps or logs.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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

Trap 1: Use 'privileged' PSS with Warn mode

Privileged profile allows all capabilities and root, increasing breakout risk.

Trap 2: Use 'baseline' PSS with Audit mode

Audit mode only logs violations, does not prevent breakouts.

Trap 3: Use 'baseline' PSS with Enforce mode

Baseline restricts some capabilities but still allows running as root.

Study all Minimize Microservice Vulnerabilities common traps →

A
Use 'privileged' PSS with Warn mode
Why wrong: Privileged profile allows all capabilities and root, increasing breakout risk.
B
Use 'baseline' PSS with Audit mode
Why wrong: Audit mode only logs violations, does not prevent breakouts.
C
Use 'restricted' PSS with Enforce mode
Restricted profile requires non-root and drops all capabilities except net bind service.
D
Use 'baseline' PSS with Enforce mode
Why wrong: Baseline restricts some capabilities but still allows running as root.

Full breakdown with real-world context →

Question 3easymultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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?

Trap 1: Set `securityContext.runAsNonRoot: true` in the Pod spec

This only ensures the container runs as a non-root user, not that the filesystem is read-only.

Trap 2: Mount an emptyDir volume to the container's writable directories

This does not make the root filesystem read-only; emptyDir is writable.

Trap 3: Set `securityContext.privileged: false` in the Pod spec

This disables privileged mode but does not prevent writes to the root filesystem.

Study all Minimize Microservice Vulnerabilities common traps →

A
Set `securityContext.runAsNonRoot: true` in the Pod spec
Why wrong: This only ensures the container runs as a non-root user, not that the filesystem is read-only.
B
Mount an emptyDir volume to the container's writable directories
Why wrong: This does not make the root filesystem read-only; emptyDir is writable.
C
Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec
This directly enforces a read-only root filesystem for all containers in the Pod.
D
Set `securityContext.privileged: false` in the Pod spec
Why wrong: This disables privileged mode but does not prevent writes to the root filesystem.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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?

Trap 1: Apply a NetworkPolicy to block egress traffic from the Pod

Network policy cannot mitigate a local library vulnerability.

Trap 2: Apply an AppArmor profile to the Pod

AppArmor can restrict file access but might not block the specific syscall needed for the CVE.

Trap 3: Use a PodSecurityPolicy to drop all capabilities

Dropping capabilities does not address a system library CVE.

Study all Minimize Microservice Vulnerabilities common traps →

A
Apply a NetworkPolicy to block egress traffic from the Pod
Why wrong: Network policy cannot mitigate a local library vulnerability.
B
Apply a custom seccomp profile that blocks the vulnerable syscall
Seccomp can filter system calls, directly mitigating exploitation of syscall-related CVEs.
C
Apply an AppArmor profile to the Pod
Why wrong: AppArmor can restrict file access but might not block the specific syscall needed for the CVE.
D
Use a PodSecurityPolicy to drop all capabilities
Why wrong: Dropping capabilities does not address a system library CVE.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full DNS explanation →

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

Trap 1: Add `DAC_OVERRIDE` capability

This overrides discretionary access control on files, not network.

Trap 2: Add `NET_ADMIN` capability

This provides broad network admin privileges, too permissive for just DNS.

Trap 3: Add `NET_BIND_SERVICE` capability

This capability allows binding to ports below 1024, not DNS TCP lookups.

Study all Minimize Microservice Vulnerabilities common traps →

A
Add `DAC_OVERRIDE` capability
Why wrong: This overrides discretionary access control on files, not network.
B
Add `NET_RAW` capability
TCP DNS may require raw socket access on some configurations.
C
Add `NET_ADMIN` capability
Why wrong: This provides broad network admin privileges, too permissive for just DNS.
D
Add `NET_BIND_SERVICE` capability
Why wrong: This capability allows binding to ports below 1024, not DNS TCP lookups.

Full breakdown with real-world context →

Question 6mediummulti select

Read the full Minimize Microservice Vulnerabilities explanation →

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

Trap 1: Set the container's root filesystem as read-only

Read-only filesystem prevents malware installation but does not limit lateral movement.

Trap 2: Run the container as root to simplify debugging

Running as root increases the blast radius if the container is compromised.

Trap 3: Use hostNetwork: true to share the host's network namespace

HostNetwork exposes the host's network stack, increasing the attack surface.

Study all Minimize Microservice Vulnerabilities common traps →

A
Set resource limits (CPU/memory) on the container
Resource limits prevent a compromised container from exhausting cluster resources.
B
Set the container's root filesystem as read-only
Why wrong: Read-only filesystem prevents malware installation but does not limit lateral movement.
C
Apply a NetworkPolicy that restricts egress traffic to only necessary services
Network policies limit the ability of a compromised container to communicate with other services.
D
Run the container as root to simplify debugging
Why wrong: Running as root increases the blast radius if the container is compromised.
E
Use hostNetwork: true to share the host's network namespace
Why wrong: HostNetwork exposes the host's network stack, increasing the attack surface.

Full breakdown with real-world context →

Question 7hardmulti select

Read the full Minimize Microservice Vulnerabilities explanation →

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

Trap 1: Use images from any public registry for flexibility

Images from untrusted registries may contain malware.

Trap 2: Always use the latest tag to get the most recent patches

Latest tag can change unpredictably and may not be verified.

Study all Minimize Microservice Vulnerabilities common traps →

A
Use images from any public registry for flexibility
Why wrong: Images from untrusted registries may contain malware.
B
Use minimal base images (e.g., distroless or scratch) to reduce attack surface
Smaller images have fewer packages that could contain vulnerabilities.
C
Always use the latest tag to get the most recent patches
Why wrong: Latest tag can change unpredictably and may not be verified.
D
Scan images for vulnerabilities using tools like Trivy or Clair
Regular scanning identifies known CVEs in images.
E
Enable image verification using digital signatures (e.g., Notary or Cosign)
Signature verification ensures the image hasn't been tampered with.

Full breakdown with real-world context →

Question 8easymultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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

Exhibit

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
  - ALL
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: MustRunAs
    ranges:
    - min: 1
      max: 65535
  volumes:
  - configMap
  - emptyDir
  - projected
  - secret
  - downwardAPI
  - persistentVolumeClaim

Trap 1: Containers can run in privileged mode

Privileged is explicitly set to false.

Trap 2: Containers cannot use ConfigMap volumes

ConfigMaps are listed in the allowed volumes.

Trap 3: Containers must run as the root user

The policy enforces MustRunAsNonRoot.

Study all Minimize Microservice Vulnerabilities common traps →

A
Containers can run in privileged mode
Why wrong: Privileged is explicitly set to false.
B
Containers cannot use ConfigMap volumes
Why wrong: ConfigMaps are listed in the allowed volumes.
C
Containers must run as the root user
Why wrong: The policy enforces MustRunAsNonRoot.
D
Containers cannot add any Linux capabilities
The PSP requires dropping ALL capabilities, so adding any is disallowed.

Full breakdown with real-world context →

Question 9mediummultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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

Network Topology

Trap 1: The container is running without any capabilities

CapEff shows many capabilities set.

Trap 2: The container has dropped all capabilities except NET_BIND_SERVICE

The capability mask is not limited to a single capability.

Trap 3: The container has default Docker capabilities, which is secure

Default Docker capabilities are a subset; this mask includes all.

Study all Minimize Microservice Vulnerabilities common traps →

A
The container is running without any capabilities
Why wrong: CapEff shows many capabilities set.
B
The container has all capabilities enabled, which is a security risk
Full capabilities allow many privileged operations, increasing attack surface.
C
The container has dropped all capabilities except NET_BIND_SERVICE
Why wrong: The capability mask is not limited to a single capability.
D
The container has default Docker capabilities, which is secure
Why wrong: Default Docker capabilities are a subset; this mask includes all.

Full breakdown with real-world context →

Question 10mediummultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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?

Trap 1: Store the credentials in a Secret and mount it as a volume with…

Mounting as volume is good, but default permissions may allow other processes to read the secret. Also, no RBAC restriction is mentioned.

Trap 2: Use a sidecar container that reads the secret from a file and…

Running as root is insecure and the Unix socket approach adds complexity without significant security benefit.

Trap 3: Store the credentials in a ConfigMap and inject them as environment…

ConfigMaps are not designed for secrets and are stored in plaintext in etcd unless encrypted. Environment variables can leak via pod logs or /proc.

Study all Minimize Microservice Vulnerabilities common traps →

A
Store the credentials in a Secret and mount it as a volume with default permissions.
Why wrong: Mounting as volume is good, but default permissions may allow other processes to read the secret. Also, no RBAC restriction is mentioned.
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.
Read-only volume prevents modification, dedicated service account with RBAC ensures only the specific pod can access the secret, minimizing exposure.
C
Use a sidecar container that reads the secret from a file and exposes it via a Unix socket, running the container as root.
Why wrong: Running as root is insecure and the Unix socket approach adds complexity without significant security benefit.
D
Store the credentials in a ConfigMap and inject them as environment variables.
Why wrong: ConfigMaps are not designed for secrets and are stored in plaintext in etcd unless encrypted. Environment variables can leak via pod logs or /proc.

Full breakdown with real-world context →

Question 11easymulti select

Read the full Minimize Microservice Vulnerabilities explanation →

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

Trap 1: Manually inject sidecar proxies into every pod to enforce mTLS.

Manual sidecar injection is error-prone; it should be automated via mutating webhooks or service mesh.

Trap 2: Run containers in privileged mode to allow them to perform…

Privileged containers have all capabilities and can access host resources, which is highly risky.

Trap 3: Store secrets directly in container images for easy access.

Secrets in images are baked into layers and can be extracted by anyone with access to the image.

Study all Minimize Microservice Vulnerabilities common traps →

A
Manually inject sidecar proxies into every pod to enforce mTLS.
Why wrong: Manual sidecar injection is error-prone; it should be automated via mutating webhooks or service mesh.
B
Run containers in privileged mode to allow them to perform necessary system calls.
Why wrong: Privileged containers have all capabilities and can access host resources, which is highly risky.
C
Ensure containers run with a non-root user.
Running as non-root limits the permissions available to an attacker if the container is compromised.
D
Use a read-only root filesystem for containers.
Read-only root filesystem prevents attackers from writing malicious files or modifying binaries.
E
Store secrets directly in container images for easy access.
Why wrong: Secrets in images are baked into layers and can be extracted by anyone with access to the image.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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?

Trap 1: The seccomp profile must be set via an admission controller, not…

OPA can enforce seccomp profiles; the issue is the scope of the check.

Trap 2: OPA/Gatekeeper is not properly installed or the constraint is not…

The constraint is passing other checks, so it is likely active.

Trap 3: The cluster's nodes do not support seccomp, so the profile is…

Nodes with containerd 1.6 support seccomp by default; the cluster supports it.

Study all Minimize Microservice Vulnerabilities common traps →

A
The seccomp profile must be set via an admission controller, not OPA.
Why wrong: OPA can enforce seccomp profiles; the issue is the scope of the check.
B
OPA/Gatekeeper is not properly installed or the constraint is not active.
Why wrong: The constraint is passing other checks, so it is likely active.
C
The cluster's nodes do not support seccomp, so the profile is ignored.
Why wrong: Nodes with containerd 1.6 support seccomp by default; the cluster supports it.
D
The OPA constraint only checks pod-level `securityContext`, but the deployment uses container-level settings.
The constraint should iterate over containers in the pod spec to enforce seccomp at the container level.

Full breakdown with real-world context →

Question 13mediummulti select

Read the full Minimize Microservice Vulnerabilities explanation →

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

Trap 1: Run containers as root to avoid permission issues.

Running as root increases security risks; containers should run with least privilege.

Trap 2: Allow all egress traffic from pods to simplify network management.

Allowing unrestricted egress can enable data exfiltration; egress should be restricted to necessary destinations.

Trap 3: Use hostNetwork: true for pods to improve network performance.

Using hostNetwork bypasses network policies and exposes host network stack, increasing attack surface.

Study all Minimize Microservice Vulnerabilities common traps →

A
Enable mutual TLS (mTLS) for service-to-service communication using a service mesh.
mTLS provides encryption and mutual authentication, reducing vulnerability to eavesdropping and impersonation.
B
Run containers as root to avoid permission issues.
Why wrong: Running as root increases security risks; containers should run with least privilege.
C
Allow all egress traffic from pods to simplify network management.
Why wrong: Allowing unrestricted egress can enable data exfiltration; egress should be restricted to necessary destinations.
D
Set resource limits (CPU/memory) on containers to prevent resource exhaustion attacks.
Resource limits prevent a compromised container from consuming excessive resources and causing denial of service.
E
Use hostNetwork: true for pods to improve network performance.
Why wrong: Using hostNetwork bypasses network policies and exposes host network stack, increasing attack surface.

Full breakdown with real-world context →

Question 14easymultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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?

Trap 1: Encrypt traffic by configuring TLS certificates in each pod's…

This requires significant code changes and manual certificate management, not minimal overhead.

Trap 2: Use Kubernetes NetworkPolicies to restrict pod-to-pod communication…

NetworkPolicies control traffic but do not provide encryption or authentication; TLS in code requires application changes.

Trap 3: Move all services to a separate overlay network using Weave Net and…

This approach adds complexity, does not provide built-in mTLS, and requires manual iptables management.

Study all Minimize Microservice Vulnerabilities common traps →

A
Encrypt traffic by configuring TLS certificates in each pod's environment variables and updating the application code to use HTTPS.
Why wrong: This requires significant code changes and manual certificate management, not minimal overhead.
B
Use Kubernetes NetworkPolicies to restrict pod-to-pod communication based on labels and namespaces, and enable TLS in each service's code.
Why wrong: NetworkPolicies control traffic but do not provide encryption or authentication; TLS in code requires application changes.
C
Deploy Istio as a service mesh with mutual TLS enabled and configure AuthorizationPolicy resources to allow only required traffic between services.
Istio provides transparent mTLS and fine-grained authorization without code changes, meeting all requirements.
D
Move all services to a separate overlay network using Weave Net and enforce egress rules with iptables on each node.
Why wrong: This approach adds complexity, does not provide built-in mTLS, and requires manual iptables management.

Full breakdown with real-world context →

Question 15mediumdrag order

Read the full Minimize Microservice Vulnerabilities explanation →

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

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 16mediumdrag order

Read the full Minimize Microservice Vulnerabilities explanation →

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

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 17mediummatching

Read the full Minimize Microservice Vulnerabilities explanation →

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

Question 18mediummatching

Read the full Minimize Microservice Vulnerabilities explanation →

Match each Kubernetes network security concept to its definition.

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

Concepts

Matches

Outbound network traffic from a pod to external endpoints

Inbound network traffic to a pod from external sources

Specification of how groups of pods are allowed to communicate

Container Network Interface plugin that implements networking for pods

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

Question 19mediummultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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

Trap 1: violation[{"msg": "Running as root is not allowed"}] {…

This checks for dropping ALL capabilities, not the user ID.

Trap 2: violation[{"msg": "Running as root is not allowed"}] {…

This only checks pod-level securityContext, not container-level, and uses incorrect field path (should be container level).

Trap 3: violation[{"msg": "Running as root is not allowed"}] {…

This denies pods that set runAsNonRoot: true, which is the opposite of what we want.

Study all Minimize Microservice Vulnerabilities common traps →

A
violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.capabilities.drop == "ALL" }
Why wrong: This checks for dropping ALL capabilities, not the user ID.
B
violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.securityContext.runAsUser == 0 }
Why wrong: This only checks pod-level securityContext, not container-level, and uses incorrect field path (should be container level).
C
violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }
This correctly denies pods with runAsUser=0.
D
violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }
Why wrong: This denies pods that set runAsNonRoot: true, which is the opposite of what we want.

Full breakdown with real-world context →

Question 20mediummultiple choice

Read the full Minimize Microservice Vulnerabilities explanation →

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?

Trap 1: allowPrivilegeEscalation

This controls whether processes can gain more privileges than their parent, not filesystem access.

Trap 2: privileged

This gives the container extended privileges, which is the opposite of what is wanted.

Trap 3: runAsNonRoot

This ensures the container does not run as root, but does not make the filesystem read-only.

Study all Minimize Microservice Vulnerabilities common traps →

A
allowPrivilegeEscalation
Why wrong: This controls whether processes can gain more privileges than their parent, not filesystem access.
B
readOnlyRootFilesystem
This makes the root filesystem read-only, which is the correct setting.
C
privileged
Why wrong: This gives the container extended privileges, which is the opposite of what is wanted.
D
runAsNonRoot
Why wrong: This ensures the container does not run as root, but does not make the filesystem read-only.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Minimize Microservice Vulnerabilities sessions

Start a Minimize Microservice Vulnerabilities only practice session

Every question in these sessions is drawn from the Minimize Microservice Vulnerabilities domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Minimize Microservice Vulnerabilities questions →Mixed CKS session

Frequently asked questions

What does the CKS exam test about Minimize Microservice Vulnerabilities?: Minimize Microservice Vulnerabilities questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Minimize Microservice Vulnerabilities questions in a focused session?: Yes — the session launcher on this page draws every question from the Minimize Microservice Vulnerabilities domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CKS topics?: Use the topic links above to move to related areas, or go back to the CKS question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the CKS exam covers. They are not copied from any real exam or dump site.

Minimize Microservice Vulnerabilities only

10 questions 20 questions 30 questions 50 questions

Mixed CKS session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All CKS questions Minimize Microservice Vulnerabilities domain overview CKS exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Minimize Microservice Vulnerabilities practice questions

What to know about Minimize Microservice Vulnerabilities

Common Minimize Microservice Vulnerabilities exam traps

Minimize Microservice Vulnerabilities questions

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 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 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 microservice container needs to perform DNS lookups using TCP rather than UDP. Which Kubernetes security context setting should be configured to allow this?

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

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

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

Exhibit

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

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?

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

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

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

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

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

Match each Kubernetes network security concept to its definition.

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

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?

Track your progress over time

Start a Minimize Microservice Vulnerabilities only practice session

Related CKS topic practice pages

Monitoring Logging and Runtime Security practice questions

Cluster Setup and Hardening practice questions

System Hardening practice questions