# NKP Practice: real-world practice companion

These manifests are optional examples for an isolated Kubernetes test environment.
Unlike the web app's simulator, kubectl in your real terminal changes real resources.
They are not a complete NKP installation, production baseline, or support statement.
Check your current context, cluster policy, image availability, and release documentation.

## Workload exercise

1. Inspect `workload.yaml`. It creates an academy-demo namespace, three non-root web
   replicas, a ClusterIP Service, and a PDB requiring two available replicas.
2. Apply with `kubectl apply -f workload.yaml`.
3. Observe `kubectl rollout status deployment/web -n academy-demo --timeout=120s`.
4. Inspect `kubectl get pods,svc,pdb -n academy-demo`.
5. Use `kubectl port-forward service/web 8080:80 -n academy-demo`, then visit
   http://localhost:8080. Stop the port-forward with Ctrl+C.
6. Scale with `kubectl scale deployment web --replicas=4 -n academy-demo`.
7. Reapply the original manifest and explain why the count returns to three.

The pinned example tag is not an immutable digest. Validate the image against your
organization's provenance and vulnerability requirements. No real cluster execution
was used to validate these examples as part of building the tutorial web application.

## Tenancy exercise

1. Read tenancy.yaml and map its example group to a deliberate test identity.
2. Apply it only after creating academy-demo.
3. As the test identity, verify Deployment write access and denied Secret access.
4. Compare the namespace quota with the application's requests and limits.
5. Test network access from a pod in the same namespace and one outside it.
   The NetworkPolicy requires an enforcing CNI and allows only namespace-local
   ingress to port 8080 for the web pods. Egress is not constrained.
6. Discuss why Deployment write access can itself be security-sensitive: actors
   able to create workloads may gain indirect access to mounted data or identities.

## Incident and maintenance review

- Read events before changing a failing Deployment.
- Check image pull, scheduling, mount, and readiness failures separately.
- Before draining a node, inspect PDBs, replica placement, local data, unmanaged pods,
  and spare capacity. Do not copy a drain command blindly into production.
- For GitOps-managed resources, change the managed source of truth.
- A storage snapshot does not prove application-consistent recovery.

## Cleanup

After checking the namespace contains only this exercise, deleting academy-demo
removes its workloads and other namespaced resources. Review any added persistent
data and reclaim policies before deleting it. No cleanup runs automatically.