SAI-270 knowledge check

How to use this assessment

Complete the questions without referring to the chapter text. Then review the guidance and update your operations runbook where your answer exposes a gap.

This public knowledge check supports learning. It does not authorize changes to a production cluster.

Scenario questions

1. Platform choice is not sovereignty

A team states their AI system is sovereign because it runs on Kubernetes inside their own data center. Explain why the platform choice alone does not establish this.

2. Binding admission to approval

A cluster allows any image from any source to be deployed as long as the manifest is syntactically valid. Identify what admission checks are missing.

3. Network-policy bypass paths

A namespace has a network policy that denies all traffic except to approved destinations. Name paths that could still bypass it.

4. Distinct storage protection

A team applies the same encryption and retention settings to model storage, evidence storage, and temporary scratch storage. Explain why this is a problem.

5. GPU compatibility set

A team upgrades only the host GPU driver and considers the change complete once the node reports the accelerator as available. Explain what else is part of the compatibility set.

6. Allocatable versus healthy

A scheduler reports a GPU as allocatable and assigns it to a workload. Explain why this is not proof the model service on that accelerator works correctly.

7. Internalized update dependencies

A platform update pulls a container image and a policy bundle directly from public internet sources during rollout. Explain the problem.

8. Recovery beyond restored files

After a disaster-recovery test, all files from backup have been restored to a new cluster. Explain what else must be validated before recovery is considered complete.

Answer guidance

1. Running on Kubernetes says nothing about who controls the artifacts, identities, network paths, and administrative access inside it — sovereignty depends on the explicit controls layered onto the platform, not the platform choice itself.
2. Admission should validate immutable image identity, required signatures or attestations, namespace, security context, resource limits, volumes, capabilities, host access, and policy exceptions — each check ties the running workload back to a specific approved artifact.
3. DNS resolution, node-level networking, host-network mode, operator-initiated traffic, debug containers, and administrative access paths can all move traffic outside a namespace's declared policy and need to be explicitly tested.
4. Model, cache, index, source, log, evidence, backup, and temporary storage each carry different sensitivity, integrity, and recovery requirements — encryption, key authority, retention, and access rules should be decided per class, not applied uniformly.
5. Accelerator hardware, firmware, host driver, the device plugin or operator, container runtime, libraries, inference runtime, model format, quantization, and serving configuration together form the tested compatibility set — changing the driver alone still requires impact analysis and revalidation of the rest.
6. A device being schedulable and allocatable only shows the platform can assign it — it does not confirm the approved model actually loaded correctly, is responsive, and is producing acceptable behavior on that accelerator.
7. Updates must be imported and verified through the controlled SAI-200 supply chain; pulling directly from a public source during rollout reintroduces an uncontrolled external dependency and bypasses the approval and provenance checks the rest of the platform relies on.
8. Recovery must validate that identity, policy, network, secrets, model, data, and evidence are all restored and that the application behaves correctly with verifiable inputs — restoring files alone does not confirm the environment can build and run an authorized workload again.

Completion rubric

Mark the operations runbook complete only when:

• Deployment boundaries, dependencies, and identities are explicit for the declared platform profile.
• Admission, network, storage, and secrets controls are documented and tested, including bypass paths.
• The GPU, model, and runtime compatibility set is defined, and changes go through impact analysis.
• Updates are internalized through the controlled artifact supply chain, not resolved externally.
• Backup, recovery, and telemetry have been tested, not just configured.
• Administrative exceptions are recorded with reason, approver, duration, and closure evidence.

Completion outcome

SAI-270 is complete when the learner can explain why the platform choice alone does not establish sovereignty, and can produce the operations runbook from the Restricted cluster operations workshop.