Quiz: Multi-Tenancy Patterns

← Back to quiz index

3 questions

L1 (2 questions)

1. Why must you create a default-deny NetworkPolicy before any allow rules in a multi-tenant cluster?

Show answer

By default, all pods can talk to all pods in Kubernetes. In a multi-tenant cluster, this means tenant A's web server can reach tenant B's database. A default-deny NetworkPolicy (empty podSelector, both Ingress and Egress policy types) blocks all traffic in the namespace, then you add specific allow rules on top. Without default-deny, network policies only add rules — they never restrict what was already open. *Common mistake:* Note: NetworkPolicies require a CNI that supports them (Calico, Cilium). On default kubenet, policies exist as objects but have zero enforcement effect.

2. What happens when a ResourceQuota exists in a namespace but a pod does not declare resource requests and limits?

Show answer

The pod is rejected by the API server. Once a ResourceQuota exists in a namespace, every pod in that namespace must declare resource requests and limits. This forces tenants to think about their resource needs. To prevent this from breaking existing workloads, combine ResourceQuota with a LimitRange that provides default requests and limits for pods that omit them.

L2 (1 questions)

1. What are the three multi-tenancy models in Kubernetes, and when would you choose each?

Show answer

Namespace per tenant (most common, low cost, moderate isolation — good starting point for most teams), virtual cluster per tenant using tools like vCluster (stronger isolation, tenants can install CRDs and have independent cluster-admin, higher complexity), and dedicated cluster per tenant (maximum isolation, no noisy-neighbor risk, but expensive and requires fleet management). Start with namespace-per-tenant and upgrade when the isolation model breaks.