Multi-tenancy and isolation in MLOps - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Multi-tenancy Isolation Levels

Which isolation level best ensures that tenants cannot access each other's data in a multi-tenant MLOps platform?

A Shared database with tenant-specific schemas

B Shared file storage with access control lists

C Shared database and shared schema with tenant ID filtering

D Dedicated database per tenant

💡 Hint

Think about physical separation to prevent accidental or malicious data access.

Dedicated databases per tenant provide the strongest isolation by physically separating data, preventing cross-tenant access.

💻 Command Output

intermediate

Kubernetes Namespace Isolation Output

Given the command kubectl get pods -n tenant-a, what is the expected output if the namespace tenant-a exists but has no pods?

MLOps

kubectl get pods -n tenant-a

A Error from server (NotFound): namespaces "tenant-a" not found

B No resources found in tenant-a namespace.

C

NAME   READY   STATUS   RESTARTS   AGE

D pod1 1/1 Running 0 5m

💡 Hint

Consider what Kubernetes shows when a namespace exists but has no pods.

Kubernetes returns 'No resources found' when the namespace exists but contains no pods.

❓ Configuration

advanced

Configuring Resource Quotas for Tenant Isolation

Which YAML snippet correctly sets a CPU limit of 2 cores and memory limit of 4Gi for a tenant namespace tenant-b in Kubernetes?

A

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-b-quota
  namespace: tenant-b
spec:
  hard:
    limits.cpu: "2"
    limits.memory: 4Gi

B

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-b-quota
  namespace: tenant-b
spec:
  hard:
    cpu: 2
    memory: 4Gi

C

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-b-quota
  namespace: tenant-b
spec:
  hard:
    cpu: "2"
    memory: 4Gi

D

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-b-quota
  namespace: tenant-b
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi

💡 Hint

ResourceQuota keys for limits must be prefixed with limits.

ResourceQuota requires keys like limits.cpu and limits.memory to set limits on CPU and memory usage.

❓ Troubleshoot

advanced

Troubleshooting Cross-Tenant Data Access

An MLOps platform uses shared storage with access control lists (ACLs) for tenant data isolation. Tenant C reports they can see files belonging to Tenant D. What is the most likely cause?

A ACLs are misconfigured allowing Tenant C read access to Tenant D files

B Tenant C's namespace is incorrectly labeled

C Resource quotas are too high for Tenant D

D Kubernetes pod security policies are too restrictive

💡 Hint

Focus on permissions controlling file access.

If ACLs are misconfigured, tenants can access each other's files despite namespace or quota settings.

🔀 Workflow

expert

Multi-tenant Deployment Workflow

Arrange the steps in the correct order to deploy isolated ML models for multiple tenants using Kubernetes namespaces and resource quotas.

A 1,3,2,4

B 2,1,3,4

C 1,2,3,4

D 1,2,4,3

💡 Hint

Think about setting up the environment before deploying workloads and securing communication last.

Namespaces must be created first, then resource quotas applied, followed by deploying pods, and finally network policies to isolate traffic.

Practice

1. What is the main purpose of multi-tenancy in MLOps platforms?

easy

A. To speed up model training by using multiple GPUs

B. To store all data in a single shared database without restrictions

C. To allow multiple users to share the same system safely

D. To run only one user's workload at a time

Solution

1. Step 1: Understand multi-tenancy concept

   Multi-tenancy means many users share one system but remain separate and safe.

2. Step 2: Identify the correct purpose

   The goal is to let users share resources without interfering with each other.

3. Final Answer:

   To allow multiple users to share the same system safely -> Option C

4. Quick Check:

   Multi-tenancy = safe shared use [OK]

Hint: Multi-tenancy means safe sharing, not exclusive use [OK]

Common Mistakes:

• Confusing multi-tenancy with faster hardware use
• Thinking all data is mixed without separation
• Believing only one user runs at a time

2. Which configuration snippet correctly isolates tenant data in a Kubernetes namespace?

easy

A. apiVersion: v1
kind: ConfigMap
metadata:
name: tenant-a-config

B. apiVersion: v1
kind: Namespace
metadata:
name: tenant-a

C. apiVersion: v1
kind: Service
metadata:
name: tenant-a-service

D. apiVersion: v1
kind: Pod
metadata:
name: tenant-a-pod

Solution

1. Step 1: Identify resource for tenant isolation

   Kubernetes namespaces isolate resources per tenant.

2. Step 2: Match correct YAML kind

   Namespace kind with tenant name isolates tenant data correctly.

3. Final Answer:

   apiVersion: v1 kind: Namespace metadata: name: tenant-a -> Option B

4. Quick Check:

   Namespace = tenant isolation [OK]

Hint: Namespaces isolate tenants, not pods or services alone [OK]

Common Mistakes:

• Choosing Pod or Service which do not isolate tenants
• Confusing ConfigMap with isolation resource
• Missing correct YAML syntax for namespaces

3. Given this code snippet for tenant isolation in a shared ML platform, what will be the output?

tenants = {"tenant1": {"models": ["modelA"]}, "tenant2": {"models": ["modelB"]}}

for tenant, data in tenants.items():
    print(f"{tenant} has models: {', '.join(data['models'])}")

medium

A. tenant1 has models: modelA
tenant2 has models: modelB

B. tenant1 has models: modelB
tenant2 has models: modelA

C. tenant1 has models:
tenant2 has models:

D. Error: KeyError

Solution

1. Step 1: Understand dictionary structure

   Each tenant key maps to a dict with a 'models' list.

2. Step 2: Loop and print models per tenant

   Loop prints tenant name and joins model names correctly.

3. Final Answer:

   tenant1 has models: modelA tenant2 has models: modelB -> Option A

4. Quick Check:

   Correct tenant-model mapping printed [OK]

Hint: Check keys and values carefully in dict loops [OK]

Common Mistakes:

• Swapping models between tenants
• Printing empty model lists
• Mistyping keys causing KeyError

4. You have this Kubernetes YAML snippet meant to isolate tenant workloads:

apiVersion: v1
kind: Namespace
metadata:
  name: tenant1
---
apiVersion: v1
kind: Pod
metadata:
  name: tenant1-pod
  namespace: tenant2
spec:
  containers:
  - name: app
    image: ml-app:latest

What is the main issue here?

medium

A. Pod is assigned to a different namespace than tenant's namespace

B. Namespace name is invalid

C. Container image name is incorrect

D. Pod spec is missing container ports

Solution

1. Step 1: Check namespace assignment

   Pod metadata namespace is 'tenant2' but tenant namespace defined is 'tenant1'.

2. Step 2: Identify isolation problem

   Pod runs in wrong namespace, breaking tenant isolation.

3. Final Answer:

   Pod is assigned to a different namespace than tenant's namespace -> Option A

4. Quick Check:

   Namespace mismatch breaks isolation [OK]

Hint: Pod namespace must match tenant namespace exactly [OK]

Common Mistakes:

• Ignoring namespace mismatch
• Assuming image name causes error
• Thinking missing ports cause isolation failure

5. In a multi-tenant MLOps platform, you want to ensure that tenant A's models cannot access tenant B's data. Which combination of strategies best achieves this?

hard

A. Run all tenant workloads on the same node without resource limits

B. Store all tenant data in one database and rely on application code to separate access

C. Allow tenants to share the same service account for simplicity

D. Use separate namespaces for each tenant and enforce RBAC policies limiting access

Solution

1. Step 1: Understand isolation requirements

   Tenant data must be separated and access controlled to prevent leaks.

2. Step 2: Identify best isolation methods

   Namespaces isolate resources; RBAC controls who can access what.

3. Step 3: Evaluate options

   Only Use separate namespaces for each tenant and enforce RBAC policies limiting access uses both namespaces and RBAC for strong isolation.

4. Final Answer:

   Use separate namespaces for each tenant and enforce RBAC policies limiting access -> Option D

5. Quick Check:

   Namespaces + RBAC = strong tenant isolation [OK]

Hint: Combine namespaces and RBAC for secure tenant isolation [OK]

Common Mistakes:

• Relying only on application code for data separation
• Sharing service accounts across tenants
• Ignoring resource limits and node sharing risks