KubeQuest

Appearance

Practice Questions: Cluster Setup and Hardening ​

About These Questions

These 20 questions cover all topics in Domain 1 and are designed for practice on a Kind cluster. They are performance-based, meaning you must perform actual tasks -- not just answer multiple choice. The difficulty levels are:

  • Easy: Straightforward single-step tasks (2-3 minutes)
  • Medium: Multi-step tasks requiring knowledge of configuration (5-8 minutes)
  • Hard: Complex tasks combining multiple concepts (8-12 minutes)

Question 1 -- Default Deny Network Policy ​

Difficulty: Easy

Scenario: The payments namespace contains several pods that process sensitive financial data. Currently, there are no network policies applied, meaning all pods can communicate freely.

Task: Create a NetworkPolicy called default-deny-all in the payments namespace that denies all ingress and egress traffic to all pods by default.

Question 2 -- Allow Specific Pod Communication ​

Difficulty: Medium

Scenario: In the webapp namespace, there are pods labeled role=frontend and pods labeled role=api. The frontend pods need to communicate with the API pods on port 8080, but no other communication should be allowed.

Task:

  1. Ensure a default deny all ingress policy exists in the webapp namespace
  2. Create a NetworkPolicy called allow-frontend-to-api that allows ingress traffic to pods labeled role=api from pods labeled role=frontend on TCP port 8080 only

Question 3 -- Cross-Namespace Network Policy ​

Difficulty: Medium

Scenario: The monitoring namespace contains Prometheus pods labeled app=prometheus. These pods need to scrape metrics from all pods in the production namespace on port 9090. The production namespace already has a default deny ingress policy.

Task: Create a NetworkPolicy called allow-prometheus-scrape in the production namespace that allows ingress traffic on port 9090 from any pod in the monitoring namespace. Use the automatic namespace label kubernetes.io/metadata.name.

Question 4 -- Egress Network Policy with DNS ​

Difficulty: Medium

Scenario: Pods in the restricted namespace should only be allowed to communicate with pods in the same namespace and must be able to resolve DNS. All other egress traffic must be blocked.

Task:

  1. Create a default deny egress NetworkPolicy called default-deny-egress in the restricted namespace
  2. Create a NetworkPolicy called allow-dns-and-internal that allows all pods in the restricted namespace to send DNS traffic (UDP and TCP on port 53) and communicate with any pod within the same namespace

Question 5 -- Fix CIS Benchmark Failures (API Server) ​

Difficulty: Hard

Scenario: A security audit has found the following issues with the API server configuration:

  • Anonymous authentication is enabled
  • Profiling is enabled
  • The AlwaysAdmit admission plugin is enabled
  • The NodeRestriction admission controller is not enabled

Task: Fix all four issues by editing the API server static pod manifest at /etc/kubernetes/manifests/kube-apiserver.yaml. Ensure the API server restarts successfully after your changes.

Question 6 -- Fix Kubelet Security Configuration ​

Difficulty: Medium

Scenario: The kubelet on the worker node has the following security issues:

  • Anonymous authentication is enabled
  • Authorization mode is set to AlwaysAllow
  • The read-only port (10255) is enabled

Task: Fix the kubelet configuration at /var/lib/kubelet/config.yaml to:

  1. Disable anonymous authentication
  2. Set authorization mode to Webhook
  3. Disable the read-only port
  4. Restart the kubelet service

Question 7 -- Configure Encryption at Rest ​

Difficulty: Hard

Scenario: Secrets stored in etcd are currently not encrypted. The security team requires all secrets to be encrypted at rest using AES-CBC encryption.

Task:

  1. Generate a 32-byte encryption key
  2. Create an EncryptionConfiguration at /etc/kubernetes/enc/encryption-config.yaml that encrypts secrets using aescbc
  3. Configure the API server to use this encryption configuration
  4. Create a test secret called test-secret in the default namespace to verify encryption is working
  5. Verify that the secret is encrypted in etcd

Question 8 -- Check and Rotate Certificates ​

Difficulty: Medium

Scenario: You need to audit the TLS certificates on the control plane and identify any that will expire within 30 days.

Task:

  1. Check the expiration dates of all Kubernetes certificates using kubeadm
  2. Use openssl to inspect the API server certificate and identify its Subject Alternative Names (SANs)
  3. Renew the API server certificate using kubeadm

Question 9 -- Create RBAC for Developer User ​

Difficulty: Medium

Scenario: A new developer named sarah needs access to the development namespace. She should be able to:

  • Get, list, and watch pods, services, and deployments
  • Create and delete pods
  • View pod logs
  • She should NOT be able to access secrets or exec into pods

Task:

  1. Create a Role called developer in the development namespace with the appropriate permissions
  2. Create a RoleBinding called sarah-developer binding the role to user sarah

Question 10 -- Audit Dangerous RBAC Permissions ​

Difficulty: Hard

Scenario: A security audit has flagged several RBAC configurations as potentially dangerous. You need to investigate and remediate.

Task:

  1. Find all ClusterRoleBindings that reference the cluster-admin ClusterRole
  2. Check if any user named intern has been granted cluster-admin access
  3. If found, remove the ClusterRoleBinding granting intern cluster-admin access
  4. Create a new ClusterRole called read-only-all that grants only get, list, watch on all resources (excluding secrets)
  5. Bind this new role to user intern with a ClusterRoleBinding called intern-readonly

Question 11 -- Secure Service Account ​

Difficulty: Medium

Scenario: The web-app deployment in the production namespace uses the default service account. The pods do not need to communicate with the Kubernetes API.

Task:

  1. Create a new ServiceAccount called web-app-sa in the production namespace with automountServiceAccountToken: false
  2. Update the web-app deployment to use this new service account
  3. Verify that no service account token is mounted in the pods

Question 12 -- Configure Audit Logging ​

Difficulty: Hard

Scenario: The security team requires audit logging on the API server with the following policy:

  • Log nothing for requests to endpoints and services
  • Log at Metadata level for secrets and configmaps
  • Log at RequestResponse level for pods
  • Log everything else at Request level

Task:

  1. Create an audit policy file at /etc/kubernetes/audit/audit-policy.yaml
  2. Configure the API server to use this audit policy and write logs to /var/log/kubernetes/audit/audit.log
  3. Set maximum log age to 30 days, max backup to 10, and max size to 100 MB
  4. Ensure proper volume mounts are added to the API server manifest

Question 13 -- Create TLS Ingress ​

Difficulty: Medium

Scenario: The webapp-service in the production namespace needs to be exposed externally via an Ingress with TLS.

Task:

  1. Generate a self-signed TLS certificate for the hostname webapp.example.com
  2. Create a TLS secret called webapp-tls in the production namespace
  3. Create an Ingress resource called webapp-ingress that:
    • Uses the nginx ingress class
    • Terminates TLS using the webapp-tls secret
    • Routes traffic for webapp.example.com to webapp-service on port 80
    • Forces HTTPS redirect

Question 14 -- Fix etcd TLS Configuration ​

Difficulty: Medium

Scenario: The etcd configuration has been tampered with and --client-cert-auth has been set to false, meaning etcd is not requiring client certificate authentication.

Task:

  1. Inspect the current etcd manifest at /etc/kubernetes/manifests/etcd.yaml
  2. Ensure --client-cert-auth=true is set
  3. Ensure --peer-client-cert-auth=true is set
  4. Verify etcd health after the changes

Question 15 -- Combined Network Policy Challenge ​

Difficulty: Hard

Scenario: In the microservices namespace, you have three tiers:

  • Frontend pods (tier=frontend) that receive external traffic on port 443
  • Backend pods (tier=backend) that listen on port 8080
  • Database pods (tier=database) that listen on port 5432

The rules are:

  • Frontend can receive traffic from anywhere and can communicate with backend
  • Backend can only receive from frontend and can communicate with database
  • Database can only receive from backend and cannot initiate any outbound connections
  • All pods need DNS access

Task: Create the complete set of NetworkPolicies to implement this architecture. You will need at minimum 4 policies (default deny + one per tier).

Question 16 -- Secure API Server Authorization ​

Difficulty: Easy

Scenario: The API server is currently configured with --authorization-mode=AlwaysAllow. This is a critical security vulnerability.

Task: Change the API server authorization mode to Node,RBAC by editing the static pod manifest. Verify the API server restarts successfully.

Question 17 -- Backup etcd Securely ​

Difficulty: Medium

Scenario: You need to create a secure backup of the etcd database.

Task:

  1. Take an etcd snapshot and save it to /tmp/etcd-backup-$(date +%Y%m%d).db
  2. Verify the snapshot integrity
  3. Set file permissions to 600 and ownership to root:root on the backup file

Question 18 -- Certificate Signing Request ​

Difficulty: Medium

Scenario: A new team member alex needs kubectl access to the cluster. You need to create a certificate for them and approve it through the Kubernetes CSR API.

Task:

  1. Generate a private key for user alex
  2. Create a CSR with subject /CN=alex/O=development
  3. Submit the CSR to Kubernetes
  4. Approve the CSR
  5. Retrieve the signed certificate

Question 19 -- Comprehensive Cluster Hardening ​

Difficulty: Hard

Scenario: You have been asked to perform a comprehensive security hardening of the cluster. Multiple issues need to be addressed.

Task:

  1. Ensure the API server has --anonymous-auth=false
  2. Ensure --authorization-mode=Node,RBAC
  3. Ensure --enable-admission-plugins includes NodeRestriction
  4. Ensure --profiling=false
  5. Ensure encryption at rest is configured for secrets
  6. Create a default deny NetworkPolicy in the kube-system namespace for ingress
  7. Ensure the default service account in kube-system has automountServiceAccountToken: false

Question 20 -- Investigate and Fix Security Issues ​

Difficulty: Hard

Scenario: A penetration test has revealed several security issues in your cluster. You have a report that identifies:

  1. A ClusterRoleBinding legacy-binding gives the service account default:default cluster-admin access
  2. The staging namespace has no network policies
  3. A Role in the staging namespace called too-permissive grants * verbs on all resources
  4. The API server insecure port is not explicitly disabled

Task: Remediate all four issues:

  1. Delete the dangerous ClusterRoleBinding
  2. Create a default deny ingress and egress NetworkPolicy in staging
  3. Modify the too-permissive role to only allow get, list, watch on pods, services, and deployments
  4. Ensure --insecure-port=0 is set in the API server manifest (for Kubernetes versions where this flag exists)

Released under the MIT License.

Copyright © 2026 OpsAlchemy