The full 75-question bank, every premise and answer fact-checked against Nutanix NKP 2.12 and upstream Kubernetes/CNCF documentation, with the concept taught, the trap named, and deep links to drill down. This is the companion to the timed mock exam, not another sim.
Hands-on labs (local, no Nutanix)
NKP is a curated bundle of upstream CNCF projects, so you can build most of the hands-on muscle the exam tests on your own laptop with kind and free tools. Every command below was run on macOS before publishing. Full copy-paste version with the complete YAML: the labs page.
Covered: kubectl, RBAC, the Cluster API object model, Flux GitOps, Gatekeeper policy, the Prometheus stack, Velero backup. Not covered (stays book-knowledge): the Nutanix provider parameters, the Kommander UI with its workspaces and projects, and the licensing flow, which need a real NKP estate.
brew install colima docker kind helm clusterctl fluxcd/tap/flux velero kubectl
colima start --cpu 6 --memory 12 --disk 60
kind create cluster --name ncpcn-lab
kubectl --context kind-ncpcn-lab get nodes
Lab 0 · kind and kubectl: the control plane
Section 1/2 · bootstrap cluster (Q5, Q6), NotReady troubleshooting (Q22)
kubectl create namespace demo
kubectl -n demo create deployment web --image=nginx:stable --replicas=2
kubectl -n demo expose deployment web --port=80 --type=ClusterIP
kubectl -n kube-system get pods # the control plane: etcd, apiserver, scheduler, controller-manager, kube-proxy
Lab 1 · RBAC: Role and RoleBinding
Section 3 · in-cluster RBAC vs fleet RBAC (Q34, Q35)
kubectl create namespace team-a
kubectl -n team-a create serviceaccount dev
kubectl -n team-a create role pod-reader --verb=get,list,watch --resource=pods
kubectl -n team-a create rolebinding dev-pod-reader --role=pod-reader --serviceaccount=team-a:dev
kubectl auth can-i list pods --as=system:serviceaccount:team-a:dev -n team-a # yes
kubectl auth can-i list pods --as=system:serviceaccount:team-a:dev -n default # no
Lab 2 · Cluster API: the object model
Section 2 · management cluster (Q7), KubeadmControlPlane vs MachineDeployment (Q21, Q23), generate workflow (Q20)
clusterctl init --infrastructure docker
kubectl get crds | grep cluster.x-k8s.io
# clusters, kubeadmcontrolplanes (control plane), machinedeployments (workers), dockermachinetemplates
clusterctl generate cluster my-cluster --kubernetes-version v1.31.0 \
--control-plane-machine-count=1 --worker-machine-count=2 > my-cluster.yaml
Lab 3 · Flux: GitOps continuous delivery
Section 4 · GitOps CD (Q72), Flux reconcile (Q29)
flux install
flux create source git podinfo --url=https://github.com/stefanprodan/podinfo --branch=master --interval=1m
flux create kustomization podinfo --source=GitRepository/podinfo --path="./kustomize" --prune=true --interval=5m --target-namespace=default --wait
kubectl -n default get deploy podinfo # deployed straight from Git
Lab 4 · Gatekeeper: admission policy
Section 3 · OPA Gatekeeper no-privileged-containers (Q37)
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.22.2/deploy/gatekeeper.yaml
kubectl -n gatekeeper-system rollout status deploy/gatekeeper-controller-manager
# apply a ConstraintTemplate + Constraint forbidding privileged containers (full YAML on the labs page)
# result: a privileged pod is DENIED by the admission webhook; a normal pod is ALLOWED
Lab 5 · Prometheus: the monitoring stack
Section 3 · the monitoring trio (Q47), ServiceMonitor (Q49)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kps prometheus-community/kube-prometheus-stack -n monitoring --create-namespace
kubectl -n monitoring get pods | grep -E "prometheus-kps|grafana|alertmanager" # the trio
kubectl get crd servicemonitors.monitoring.coreos.com
Lab 6 · Velero: backup and restore
Section 3 · object-storage backup (Q41), velero backup (Q44), velero restore (Q45)
kubectl apply -f https://raw.githubusercontent.com/vmware-tanzu/velero/main/examples/minio/00-minio-deployment.yaml
velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.12.0 --bucket velero \
--secret-file minio-creds --use-volume-snapshots=false \
--backup-location-config region=minio,s3ForcePathStyle=true,s3Url=http://minio.velero.svc:9000
velero backup create demo-bak --include-namespaces demo --wait
kubectl delete ns demo
velero restore create demo-restore --from-backup demo-bak --wait
Velero scope: this validates resource backup and restore to object storage (Q41, Q44, Q45). The persistent-volume path via CSI VolumeSnapshotClasses (Q43, Q46) needs the external-snapshotter controller plus a snapshot-capable CSI driver, which a default kind cluster does not ship. Understand it from the guide.
Section 1 · Prepare the Environment 17 questions
Q1Verifiedconfidence: high
An organization has zero internet connectivity in its datacenter. What is the FIRST artifact-related step of an NKP install there?
- ARun nkp create cluster with --offline
- BDownload the NKP air-gapped bundle on a connected machine and transfer it across the gapcorrect
- COpen a firewall exception for registry.k8s.io
- DInstall Kommander
Answer: B
WhyAn air-gapped NKP install begins on an internet-connected machine (jumphost): download the NKP air-gapped bundle from the Nutanix Portal, then physically transfer it across the gap to the bastion host. Only after the artifacts are inside the gap can you extract them and seed your private registry, since the isolated environment cannot pull from public registries. The actual cluster create command comes much later in the workflow.
The trap'nkp create cluster --offline' (A) sounds plausible but is far downstream and not the FIRST artifact step; opening a firewall exception to registry.k8s.io (C) contradicts the premise of zero connectivity; installing Kommander (D) is a late management-layer step.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Air-gapped bundle: One downloadable tarball containing every NKP container image plus install artifacts, transferred across the air gap.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Q2Verifiedconfidence: high
Which parameters does a registry seeding operation require?
- APrism Element cluster name only
- BBundle location, destination registry URL, and registry credentials/TLS materialcorrect
- CThe management cluster kubeconfig
- DA Kommander license key
Answer: B
WhySeeding pushes the bundle's container images into a private registry, so it needs three things: where the bundle is (the tarball path), where the images go (the destination registry URL/project), and how to authenticate and trust it (credentials plus optional CA/TLS material). In NKP this is the 'nkp push bundle' command with --bundle, --to-registry, --to-registry-username/password, and --to-registry-ca-cert-file.
The trapA Prism Element cluster name (A), a management kubeconfig (C), and a Kommander license key (D) are all real NKP nouns used elsewhere in the workflow, but none are inputs to the registry-seeding/push operation itself, which is purely a bundle-to-registry transfer.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Prism Element: The management UI for a single Nutanix cluster (one cluster's local console).
Air-gapped bundle: One downloadable tarball containing every NKP container image plus install artifacts, transferred across the air gap.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Q3Verifiedconfidence: high
Seeding fails with x509 certificate errors. The cause is most likely:
- AWrong NKP version
- BThe registry's self-signed certificate is not trusted by the host running the seedcorrect
- CThe bundle is corrupt
- DThe license tier is Starter
Answer: B
Whyx509 errors during seeding are trust failures: the registry presents a certificate signed by a private/internal CA (often self-signed) that the host running the push does not trust. The fix is to supply the registry's CA certificate, e.g. --to-registry-ca-cert-file during the push and --registry-mirror-cacert during cluster creation, so the seeding host and later the nodes trust the registry.
The trapWrong NKP version (A), corrupt bundle (B), and Starter license tier (D) cause different failure signatures (version-skew warnings, checksum/extraction errors, feature-gating) and would not surface as an x509 certificate validation error, which is specifically a TLS-trust problem.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
Air-gapped bundle: One downloadable tarball containing every NKP container image plus install artifacts, transferred across the air gap.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Node: A worker machine (a VM or physical server) that runs pods.
x509 certificate: The standard format for TLS certificates. An x509 error means a certificate is not trusted (often a private CA that was not imported).
Q4Verifiedconfidence: high
Which components must be able to reach the private registry in a fully air-gapped NKP estate?
- AOnly the bastion
- BOnly the management cluster
- CThe bastion, bootstrap process, management cluster nodes, and all workload cluster nodescorrect
- DOnly Kommander
Answer: C
WhyIn a fully air-gapped NKP estate, every component that pulls container images must reach the private registry: the bastion (which performs the initial push), the temporary bootstrap KinD cluster, the management cluster nodes, and all workload cluster nodes. The registry is the single image source inside the gap, so registry reachability is the central design constraint these questions probe.
The trap'Only the bastion' (A), 'only the management cluster' (B), and 'only Kommander' (D) each name a real participant but understate the scope; the trap is forgetting that workload cluster nodes and the bootstrap cluster also pull images and therefore also need registry access.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
Node: A worker machine (a VM or physical server) that runs pods.
Q5Verifiedconfidence: high
What is the bootstrap cluster, physically?
- AA three-node AHV cluster
- BA temporary kind (Kubernetes-in-Docker) cluster on the install hostcorrect
- CA Prism Central VM
- DA cloud-hosted SaaS control plane
Answer: B
WhyThe NKP bootstrap cluster is a temporary kind (Kubernetes-in-Docker) cluster created on the install/bastion host. It runs the Cluster API (CAPI) controllers that provision the real cluster; once the target cluster is up, NKP pivots (moves) the CAPI resources to it and deletes the throwaway bootstrap cluster.
The trapA three-node AHV cluster (A) confuses the bootstrap with the eventual target/management cluster; a Prism Central VM (C) is the infra control plane, not the bootstrap; a cloud-hosted SaaS control plane (D) contradicts the local, self-deleting kind design.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
AHV: Nutanix's built-in hypervisor, their alternative to VMware ESXi.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Pivot: Moving the Cluster API state out of the temporary bootstrap cluster into the new management cluster, so it manages itself.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
Node: A worker machine (a VM or physical server) that runs pods.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q6Verifiedconfidence: high
Why does the NKP install host need a container runtime?
- ATo run Kommander locally
- BBecause the bootstrap cluster runs as containers on itcorrect
- CTo cache Loki logs
- DIt does not
Answer: B
WhyNKP bootstraps using kind (Kubernetes IN Docker), so the install/bastion host must have a container runtime. kind runs each Kubernetes node as a container on the host; with no runtime, no bootstrap cluster can be created and the install cannot begin. This temporary bootstrap cluster carries the Cluster API (CAPI) controllers that provision the real management cluster.
The trap"To run Kommander locally" tempts because Kommander is the NKP management UI, but Kommander runs on the management cluster, not the install host. "Cache Loki logs" is a plausible-sounding day-2 distractor unrelated to install prerequisites. "It does not" baits anyone who forgets kind needs Docker/containerd.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q7Verifiedconfidence: high
After the management cluster is built, what happens to CAPI state and the bootstrap cluster?
- ABoth remain on the bastion permanently
- BCAPI state pivots into the management cluster; the bootstrap cluster is deletedcorrect
- CCAPI state moves to Prism Central
- DThe bootstrap cluster becomes a workload cluster
Answer: B
WhyAfter the management cluster is up, NKP performs a CAPI "pivot" (clusterctl move): the Cluster API objects and controllers are moved from the temporary kind bootstrap cluster into the new management cluster, which then manages its own lifecycle (self-managed). The bootstrap cluster has no further purpose and is deleted. This is why the management cluster can later upgrade and scale itself without the bastion.
The trap"Both remain on the bastion permanently" misreads the bootstrap cluster as durable. "CAPI state moves to Prism Central" conflates Nutanix infra management with Kubernetes control-plane state; PC is the IaaS provider, not the CAPI store. "Bootstrap becomes a workload cluster" invents a promotion that never happens.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Pivot: Moving the Cluster API state out of the temporary bootstrap cluster into the new management cluster, so it manages itself.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
clusterctl: The Cluster API command-line tool.
Q8Verifiedconfidence: high
A team only wants to evaluate basic NKP cluster deployment on Nutanix with no production platform stack. The fitting license tier:
- AStartercorrect
- BPro
- CUltimate
- DFIPS
Answer: A
WhyNKP Starter is the entry tier: free with Nutanix infrastructure, supported only on Nutanix AHV, and providing basic Kubernetes cluster lifecycle (Konvoy + Kommander, basic apps, RBAC/SSO). It is exactly right for evaluating cluster deployment without the production platform stack. Pro adds the production application stack (observability, backup/restore, service mesh); Ultimate adds fleet management, multitenancy, and external-cluster attach.
The trapPro tempts because it is the "real" production tier, but the question explicitly excludes the production platform stack. Ultimate over-buys for a simple evaluation. "FIPS" is not a license tier at all (it is a hardened build/mode), planted to catch test-takers who confuse compliance variants with editions.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
AHV: Nutanix's built-in hypervisor, their alternative to VMware ESXi.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
FIPS: A US government cryptography compliance standard; NKP offers a FIPS-validated build variant.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
Service: A stable virtual IP and DNS name that load-balances traffic to a set of pods (pods come and go, the Service address stays).
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Multi-tenancy: Serving multiple isolated teams or customers on shared infrastructure without them seeing each other.
Q9Verifiedconfidence: highselect 2
Which TWO capabilities require NKP Ultimate rather than Pro?
- ADeploying a managed cluster on Nutanix
- BAttaching existing EKS/AKS/GKE clusterscorrect
- CNKP Insightscorrect
- DUsing Velero at all
- ERunning Prometheus
Answer: B, C
WhyPer the Nutanix NKP datasheet, attaching/managing existing CNCF-certified or external clusters (EKS/AKS/GKE) and NKP Insights (AI anomaly detection / root-cause analytics) are both Ultimate-only capabilities. Ultimate is the tier for fleet management across different infrastructures. Deploying a managed cluster on Nutanix exists at Starter; the core observability stack (Prometheus) and backup (Velero) appear at Pro, so none of those require Ultimate.
The trap"Deploying a managed cluster on Nutanix" tempts as a flagship capability but is the baseline (Starter). "Velero at all" and "Prometheus" bait the assumption that backup and monitoring are premium; they ship at Pro. The two correct answers (attach + Insights) are the genuinely fleet/enterprise features gated to Ultimate.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
Prometheus: The metrics database that scrapes and stores time-series numbers (CPU, requests, and so on) from your apps and the cluster.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
EKS / AKS / GKE: The managed Kubernetes services run by AWS (EKS), Azure (AKS), and Google (GKE).
Q10Verifiedconfidence: high
How are NKP licenses obtained and applied?
- AAuto-generated by the CLI
- BThrough Nutanix licensing/support flows, then applied in Kommandercorrect
- CBought per pod
- DEmbedded in machine images
Answer: B
WhyNKP license keys are generated through Nutanix licensing/support flows (Support Portal > Licenses, including non-production/trial keys), then applied inside NKP's Kommander UI under Licensing (Activate/remove License). The CLI does not auto-generate licenses, and they are not embedded in machine images or billed per pod. Generate in the portal, activate in Kommander.
The trap"Auto-generated by the CLI" plays on the heavy CLI use during install. "Bought per pod" mimics SaaS metering, but NKP licenses are core/CPU-based, not per-pod. "Embedded in machine images" sounds plausible for an appliance model but is wrong; the license is applied as a key post-deploy.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Q11Verifiedconfidence: high
The bastion host in an air-gapped design primarily exists to:
- AServe as a worker node
- BBe the controlled machine inside the restricted network that drives the install (CLI, bundles, bootstrap)correct
- CHost the registry GUI
- DRun Grafana
Answer: B
WhyIn an air-gapped NKP deployment the bastion host is the controlled, network-connected machine inside the restricted environment from which the entire install is driven. The NKP air-gapped bundle is downloaded, extracted, and the nkp CLI placed on the bastion; it hosts the bootstrap (KIND) cluster, pushes image bundles to the local registry, and orchestrates cluster creation. It is an operations/control node, not a Kubernetes worker, registry GUI, or monitoring host.
The trapDistractors map the bastion onto other roles that exist nearby in the architecture (a worker node, the registry, Grafana). They tempt because all three are real components in an air-gapped install, but none is the bastion's job; the bastion drives the install.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Air-gapped bundle: One downloadable tarball containing every NKP container image plus install artifacts, transferred across the air gap.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Q12Verifiedconfidence: highselect 3
Pick the THREE network lines of sight a bastion needs for an NKP-on-Nutanix install:
- APrism Central API endpointcorrect
- BThe private registrycorrect
- CThe node subnets/SSH where applicablecorrect
- DThe public internet at all times
- ENutanix support portal during install
Answer: A, B, C
WhyTo drive an air-gapped NKP-on-Nutanix install the bastion needs three lines of sight: the Prism Central API endpoint (to provision and manage infrastructure/CSI), the private/internal container registry (to push and later pull mirrored images), and the node subnets via SSH where applicable (to install and configure pre-provisioned nodes using the konvoy user with passwordless sudo). An air gap deliberately removes any path to the public internet or the Nutanix support portal during the install.
The trapOptions D and E describe outbound internet access, which is exactly what an air gap forbids. They tempt because a connected install would use them, and because reaching the support portal sounds operationally helpful, so a reader who forgets the air-gap constraint over-selects them.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Node: A worker machine (a VM or physical server) that runs pods.
CSI: Container Storage Interface: the standard plugin layer connecting Kubernetes to storage systems, including taking volume snapshots.
Q13Verifiedconfidence: high
KIB's node 'preparation' mode (vs image building) exists for which scenario?
- AAWS only
- BPre-provisioned infrastructure where machines already exist and must be readied in placecorrect
- CBare metal only with PXE
- DIt is deprecated
Answer: B
WhyKIB has two operating styles. For cloud/provider flows it bakes a reusable machine image (template) that CAPI later boots. For pre-provisioned infrastructure the machines already exist (base OS laid down via a golden image), so KIB runs as part of the CAPPP (Cluster API Provider Pre-Provisioned) process and performs the installation and configuration of the Kubernetes components on those existing hosts in the same step, rather than producing a separate image.
The trapThe provider-specific distractors (AWS only, bare-metal/PXE only, deprecated) tempt because pre-provisioned and bare-metal deployments overlap conceptually. But preparation mode is defined by the machines already existing, not by a specific cloud or PXE boot, and it is current, not deprecated.
Plain-English terms in this questionKIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q14Verifiedconfidence: high
What is baked into a KIB-built machine image?
- ACustomer application containers
- BOS plus the Kubernetes payload (containerd, kubelet) and hardening, ready for CAPI to boot nodes fromcorrect
- CThe NKP license
- DKommander dashboards
Answer: B
WhyA KIB-built machine image carries the operating system plus the Kubernetes node payload, specifically the container runtime (containerd), kubelet, and kubeadm, along with OS configuration and hardening (swap disabled, NTP/DNS, CA certs, the konvoy user). CAPI then boots nodes from that image and injects cluster-specific config (cluster name, control-plane endpoint, pod CIDRs) at startup. Customer application containers, the NKP license, and Kommander dashboards are layered on much later, not baked into the image.
The trapDistractors place later-stage artifacts (apps, license, Kommander dashboards) into the image. They tempt because all three are part of a finished NKP cluster, blurring the line between what is pre-baked into the node OS image and what is deployed onto the running cluster afterward.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Control plane endpoint (VIP): A stable virtual IP that fronts the cluster's API server, so clients always have one address to reach.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
kubelet: The agent on every node that starts containers and reports the node's health back to the control plane.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Node: A worker machine (a VM or physical server) that runs pods.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q15Verifiedconfidence: high
An air-gapped KIB build differs from a connected one chiefly in:
- ACPU architecture
- BPackage/artifact sources pointing at internal mirrors and local bundles via overridescorrect
- CImage format
- DIt must run as root
Answer: B
WhyAn air-gapped KIB build is functionally the same image-bake as a connected one; the chief difference is where artifacts come from. Because no upstream repositories are reachable, you supply pre-staged content and redirect sources: an OS-packages local bundle, the --artifacts-directory flag pointing at local binaries/bundles, and override files that point package/image sources at internal mirrors instead of the internet. CPU architecture, image format, and running as root are unchanged by the air gap.
The trapThe wrong options (CPU architecture, image format, must run as root) are plausible-sounding build parameters, but none of them is what the air gap changes. The single real difference is the source of packages and artifacts being redirected to local mirrors and bundles.
Plain-English terms in this questionAir-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Air-gapped bundle: One downloadable tarball containing every NKP container image plus install artifacts, transferred across the air gap.
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Q16Verifiedconfidence: high
Choosing a control plane endpoint IP for a Nutanix NKP cluster, you must ensure:
- AIt is inside the pod CIDR
- BIt is a stable address outside DHCP conflicts and not overlapping pod/service CIDRscorrect
- CIt matches Prism Central's IP
- DIt is public
Answer: B
WhyThe control plane endpoint IP is the Kubernetes API server VIP for an NKP cluster. It must be a static IPv4 address on the same Layer 2 network/subnet as the control plane machines, excluded from the DHCP range and outside Nutanix IPAM scope, and it must not overlap the pod or service CIDRs. The same exclusion-from-DHCP rule applies to the LoadBalancer Service IP range.
The trap'Inside the pod CIDR' (A) is the exact collision the requirement forbids. 'Matches Prism Central's IP' (C) confuses the cluster API VIP with the management plane address. 'Public' (D) is irrelevant to an internal cluster VIP and tempts those thinking about external reachability.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Control plane endpoint (VIP): A stable virtual IP that fronts the cluster's API server, so clients always have one address to reach.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
API server: The single entry point to a cluster. Every tool (kubectl, the UI, controllers) talks to it.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Service: A stable virtual IP and DNS name that load-balances traffic to a set of pods (pods come and go, the Service address stays).
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
MetalLB: An open-source load balancer that gives Services external IPs on bare-metal or on-prem clusters that lack a cloud load balancer.
CIDR: A way of writing an IP address range. Pod and Service networks each get a CIDR, and they must not overlap each other or the node network.
Q17Verifiedconfidence: medium
Which fact about supported operating systems matters when planning images?
- AAny Linux ISO works
- BNode images must come from NKP's supported OS list, which constrains KIB base imagescorrect
- COnly Windows Server is supported
- DOS choice is irrelevant to upgrades
Answer: B
WhyNKP node images must be built from operating systems on the Supported Infrastructure Operating Systems matrix (Ubuntu, Rocky, RHEL, Oracle Linux, Flatcar at specific versions per release). Konvoy Image Builder (KIB) bakes machine images, but only from those supported base OSes; an arbitrary Linux ISO is not supported and can break node bring-up or upgrades. Licensing also bounds OS choice in newer releases (for example, starter licenses limit you to Rocky in NKP 2.17).
The trap'Any Linux ISO works' (A) over-generalizes Kubernetes' OS-agnostic reputation and ignores the support matrix. 'Only Windows Server' (C) is plainly false for NKP node OSes. 'OS choice is irrelevant to upgrades' (D) is the seductive wrong answer because Kubernetes feels OS-portable, yet cloud-init/version mismatches (a documented 2.12.x KIB failure) prove OS choice affects builds and upgrades.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
Section 2 · Build an NKP Cluster 12 questions
Q18Verifiedconfidence: high
The canonical tool for creating an NKP cluster on Nutanix infrastructure is:
- APrism Element UI
- BThe nkp CLI (nkp create cluster nutanix ...)correct
- Cterraform apply
- Dkubeadm init on each VM
Answer: B
WhyThe canonical way to build an NKP cluster on Nutanix is the nkp CLI, e.g. 'nkp create cluster nutanix ...'. The CLI fronts a Cluster API (CAPI) workflow: it spins up a temporary KIND bootstrap cluster, provisions the target cluster via CAPI/CAPX providers, then pivots (moves) the CAPI resources into the new cluster so it becomes self-managing. Prism Element UI does not create NKP clusters, and you never hand-run kubeadm init on each VM.
The trap'terraform apply' (C) is plausible because Terraform can apply NKP CAPI manifests, but those manifests are still generated by the nkp CLI (dry-run), so Terraform is an alternative apply mechanism, not the canonical creator. 'kubeadm init on each VM' (D) describes vanilla Kubernetes, not the CAPI-driven NKP flow. 'Prism Element UI' (A) confuses VM/infra management with Kubernetes lifecycle.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Element: The management UI for a single Nutanix cluster (one cluster's local console).
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Pivot: Moving the Cluster API state out of the temporary bootstrap cluster into the new management cluster, so it manages itself.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q19Verifiedconfidence: high
Which flag pair expresses 'stable API VIP' and 'IP pool for LoadBalancer Services'?
- A--endpoint / --subnets
- B--control-plane-endpoint-ip / --kubernetes-service-load-balancer-ip-rangecorrect
- C--vm-image / --cluster-name
- D--self-managed / --dry-run
Answer: B
WhyIn the nkp CLI, --control-plane-endpoint-ip sets the stable static IPv4 VIP for the Kubernetes API server, while --kubernetes-service-load-balancer-ip-range supplies a hyphen-separated IP range (for example 10.0.0.0-10.0.0.10) that the in-cluster LoadBalancer provider hands out to Service type=LoadBalancer. Both must sit on the node subnet and be excluded from DHCP/IPAM.
The trap'--endpoint / --subnets' (A) are real flags (Prism Central URL and node subnets) but neither is the API VIP nor the Service LB range, so they look authoritative while answering a different question. '--vm-image / --cluster-name' (C) and '--self-managed / --dry-run' (D) are valid flags too, which tempts pattern-matchers who recognize the flag names without mapping them to the two specific concepts asked.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Control plane endpoint (VIP): A stable virtual IP that fronts the cluster's API server, so clients always have one address to reach.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
API server: The single entry point to a cluster. Every tool (kubectl, the UI, controllers) talks to it.
Node: A worker machine (a VM or physical server) that runs pods.
Service: A stable virtual IP and DNS name that load-balances traffic to a set of pods (pods come and go, the Service address stays).
MetalLB: An open-source load balancer that gives Services external IPs on bare-metal or on-prem clusters that lack a cloud load balancer.
Q20Verifiedconfidence: high
How do you obtain editable CAPI manifests instead of immediately building a cluster?
- Akubectl get cluster -o yaml on the bootstrap cluster
- BRun the create command with --dry-run -o yaml, edit, then applycorrect
- CExport from Prism Central
- DDecompile the NKP binary
Answer: B
WhyTo customize an NKP cluster before it exists, run the create command with --dry-run and -o yaml (optionally --output-directory) to emit the CAPI manifests without provisioning anything. You then edit those YAML objects (Cluster, MachineDeployment, secrets, etc.) and apply them. This is the supported custom-manifest path; --dry-run only prints the objects that would be created.
The trap'kubectl get cluster -o yaml on the bootstrap cluster' (A) is tempting because it does return CAPI objects, but those are post-creation, live resources, not the pre-build editable template. 'Export from Prism Central' (C) confuses the infra plane with the Kubernetes manifest source. 'Decompile the NKP binary' (D) is an absurd distractor that punishes overthinking.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Secret: Stores sensitive data like passwords, base64-encoded (which is encoding, not encryption, so add RBAC and encryption-at-rest).
kubectl: The Kubernetes command-line tool; it talks to the API server to create, inspect, and change resources.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
MachineDeployment: The Cluster API object that owns a pool of worker nodes (like a Deployment, but for machines). Different worker pools are different MachineDeployments.
Q21Verifiedconfidence: high
Control plane node count and version for a CAPI cluster live in:
- AMachineDeployment
- BKubeadmControlPlanecorrect
- CNutanixMachineTemplate
- DClusterRoleBinding
Answer: B
WhyIn Cluster API, the KubeadmControlPlane (KCP) object owns the control plane: its spec.replicas field sets the number of control plane machines and spec.version sets the Kubernetes version for them. KCP also handles etcd membership, certificate management, and rolling control-plane upgrades. Worker nodes are owned by MachineDeployments, which carry their own replicas and version. So control-plane count and version live in KubeadmControlPlane, option B.
The trapNutanixMachineTemplate (C) is tempting because it defines VM shape (CPU, memory, disk), but it does not set replica count or Kubernetes version. MachineDeployment (A) controls worker replicas/version, not the control plane. ClusterRoleBinding (D) is an RBAC object, unrelated to node topology.
Plain-English terms in this questionKubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
etcd: The cluster's key-value database; the single source of truth holding all cluster state and configuration.
Node: A worker machine (a VM or physical server) that runs pods.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
ClusterRole: Like a Role, but its permissions apply cluster-wide instead of in a single namespace.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
KubeadmControlPlane: The Cluster API object that owns a cluster's control-plane machines: how many, and which Kubernetes version.
MachineDeployment: The Cluster API object that owns a pool of worker nodes (like a Deployment, but for machines). Different worker pools are different MachineDeployments.
Q22Verifiedconfidence: high
Machines reach Running but nodes stay NotReady. The first suspicion:
- APrism Central is down
- BCNI not functioning or nodes cannot pull images (registry trust/reachability)correct
- CToo few namespaces
- DKommander missing
Answer: B
WhyWhen CAPI Machines reach Running, the VM exists and kubelet has started, but a node staying NotReady almost always means the network is not wired up: the CNI plugin has not initialized (kubelet reports NetworkPluginNotReady / cni plugin not initialized) or the node cannot pull the CNI/sandbox images because the private registry is unreachable or untrusted. This is the classic air-gapped failure mode. Diagnose with kubectl describe node and check Ready condition plus kubelet/containerd events.
The trapPrism Central being down (A) would block CAPX reconciliation and new VM creation, not leave an already-Running machine NotReady. Too few namespaces (C) is nonsense; namespaces do not gate node readiness. Kommander missing (D) is a fleet-management layer and has nothing to do with a single node's Ready condition.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
kubelet: The agent on every node that starts containers and reports the node's health back to the control plane.
CNI: Container Network Interface: the plugin that gives pods their networking. If it is broken, nodes stay NotReady.
Node: A worker machine (a VM or physical server) that runs pods.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
kubectl: The Kubernetes command-line tool; it talks to the API server to create, inspect, and change resources.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q23Verifiedconfidence: high
One cluster needs three worker pools with different VM shapes. In CAPI that is:
- AThree Clusters
- BThree MachineDeployments each referencing its own machine templatecorrect
- CThree KubeadmControlPlanes
- DImpossible
Answer: B
WhyIn Cluster API each worker pool is modeled as its own MachineDeployment, and each MachineDeployment references an infrastructure machine template (here a NutanixMachineTemplate) that defines the VM shape (vcpuSockets, vcpusPerSocket, memorySize, systemDiskSize). To get three pools with three different shapes, you create three MachineDeployments, each pointing at its own template. The CAPX multi-PE docs confirm you add a new MachineDeployment + NutanixMachineTemplate per pool.
The trapThree Clusters (A) over-provisions; you do not need separate clusters for separate node shapes. Three KubeadmControlPlanes (C) is wrong because KCP is control-plane-only and a cluster has exactly one. Impossible (D) is the obvious distractor for anyone who does not know MachineDeployments are the per-pool primitive.
Plain-English terms in this questionNode: A worker machine (a VM or physical server) that runs pods.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
KubeadmControlPlane: The Cluster API object that owns a cluster's control-plane machines: how many, and which Kubernetes version.
MachineDeployment: The Cluster API object that owns a pool of worker nodes (like a Deployment, but for machines). Different worker pools are different MachineDeployments.
Q24Verifiedconfidence: medium
When is the custom-manifest route REQUIRED over CLI flags?
- AEvery production build
- BWhen the desired configuration cannot be expressed by available CLI parameterscorrect
- COnly for AWS
- DWhenever FIPS is on
Answer: B
WhyNKP cluster creation favors CLI flags for common configuration, but those flags expose only a subset of the underlying CAPI/manifest surface. When the desired cluster shape cannot be expressed by the available nkp create cluster parameters (for example multiple worker pools across Prism Elements, custom machine details, or non-default topology), you generate the manifests (e.g. with --dry-run -o yaml) and edit/apply them directly. So the custom-manifest route is required precisely when flags cannot express the configuration.
The trap"Every production build" (A) and "Whenever FIPS is on" (D) overstate it; FIPS and production are handled by flags/registry options, not by forcing manifest editing. "Only for AWS" (C) is a provider red herring; the flag-vs-manifest boundary is provider-independent.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Element: The management UI for a single Nutanix cluster (one cluster's local console).
FIPS: A US government cryptography compliance standard; NKP offers a FIPS-validated build variant.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
MachineDeployment: The Cluster API object that owns a pool of worker nodes (like a Deployment, but for machines). Different worker pools are different MachineDeployments.
Q25Verifiedconfidence: high
Kommander is installed:
- AAutomatically with every cluster
- BOnto the management cluster after it exists, via nkp install kommander (optionally with an installer config)correct
- COn each workload cluster
- DInside Prism Central
Answer: B
WhyNKP installs in two layers: first the Konvoy layer creates the Kubernetes cluster, then Kommander (the fleet/management layer) is installed onto that management cluster after it exists, via nkp install kommander. An optional installer configuration file (--installer-config, generated with --init) customizes which platform applications ship and how. Kommander runs on the management cluster, not inside Prism Central and not on every workload cluster automatically.
The trap"Automatically with every cluster" (A) is wrong because workload clusters are attached/managed, not given their own Kommander. "On each workload cluster" (C) confuses managed clusters with the management cluster. "Inside Prism Central" (D) is a Nutanix-flavored distractor; Kommander runs in Kubernetes on the management cluster, not in PC.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Q26Verifiedconfidence: high
The Kommander installer configuration file is the place to:
- ASet BIOS settings
- BEnable/disable individual platform applications and set their overrides (e.g., small environments)correct
- CChoose the hypervisor
- DDefine VPC peering
Answer: B
WhyThe Kommander installer configuration file (apiVersion config.kommander.mesosphere.io/v1alpha1, kind Installation) is generated with `nkp install kommander --init` and applied via `--installer-config`. Its `apps:` section is where you customize each platform application by supplying Helm Chart values inline (`values:`) or via reference (`valuesFrom:`), and where you trim the platform app set for small environments. This is the documented mechanism for enabling/disabling and overriding platform apps at install time.
The trapBIOS settings, hypervisor choice, and VPC peering are infrastructure/hardware concerns that never live in a Kommander platform-app config; they tempt test-takers who conflate the platform layer with the underlying cluster/network provisioning layer.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Helm / HelmRelease: Helm is the Kubernetes package manager (apps packaged as charts). A HelmRelease is a Flux object that installs and manages one of those charts.
Q27Verifiedconfidence: high
Where does the NKP license actually get applied?
- Ankp create cluster flag
- BIn Kommander after installation (UI or CLI)correct
- CIn the machine image
- DIn the registry
Answer: B
WhyNKP ships with a free Starter license, and the actual license (Pro/Ultimate) is applied as a Kommander operation after installation: in the dashboard under Settings > Licensing (remove Starter, Add License, paste the key from the Nutanix Portal), or via the nkp CLI against the management cluster. The tier gates which features and multi-cluster/cross-infrastructure capabilities are exposed. Licensing is never a `nkp create cluster` flag, baked into a machine image, or held in the registry.
The trapThe `nkp create cluster` distractor tempts because licensing feels like a provisioning-time decision; the machine-image and registry options tempt those who assume entitlement travels with the artifacts. All three confuse build/provisioning artifacts with the post-install Kommander control plane.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
Q28Verifiedconfidence: high
Kommander components fail to come up in an air-gapped install. Most probable cause:
- AThe Kubernetes version is too new
- BPlatform app images cannot be pulled because registry overrides/trust were not provided to the Kommander installcorrect
- CToo many workspaces
- DThe bastion was rebooted
Answer: B
WhyIn an air-gapped install, Kommander deploys its platform apps through Flux HelmReleases, which must pull container images and charts from a local/mirror registry rather than public registries. You must point the install at the seeded artifacts and registry (`nkp install kommander --airgapped --kommander-applications-repository ... --charts-bundle ...`) plus registry-mirror URL/credentials/CA trust. If those overrides and trust are not provided, image pulls fail and the platform pods never come up. (Note: NKP 2.12+ on Nutanix infrastructure can auto-deploy an internal registry mirror, but the dependency is still seeded-registry image access.)
The trap"Kubernetes version too new," "too many workspaces," and "bastion rebooted" are generic-sounding infra excuses; they distract from the single recurring air-gap law that broken image pulls trace back to missing registry mirror/trust configuration.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Air-gapped bundle: One downloadable tarball containing every NKP container image plus install artifacts, transferred across the air gap.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Flux: A CNCF GitOps tool that continuously reconciles a cluster to match the manifests in a Git repo.
Helm / HelmRelease: Helm is the Kubernetes package manager (apps packaged as charts). A HelmRelease is a Flux object that installs and manages one of those charts.
Q29Verifiedconfidence: high
Diagnosing a half-broken Kommander, the highest-signal objects to inspect are:
- ANodes' /var/log/messages
- BThe Flux HelmReleases and platform app pods in Kommander's namespacescorrect
- CPrism alerts
- DThe bootstrap cluster (recreate it to check)
Answer: B
WhyKommander installs and reconciles platform applications via Flux (HelmReleases). When Kommander is half-broken, the highest-signal objects are the Flux HelmRelease resources and the platform-app pods in Kommander's namespaces: HelmRelease status names the failing app and the reason (e.g., image pull, values error, dependency not ready), and pod state confirms it. Node syslogs, Prism alerts, and recreating the bootstrap cluster are downstream or destructive and do not directly surface the failing app.
The trap`/var/log/messages` and Prism alerts feel like 'check the logs' instinct; 'recreate the bootstrap cluster to check' is actively harmful (the bootstrap/KIND cluster is ephemeral and already pivoted away). They tempt anyone who hasn't internalized that Kommander is GitOps/Flux-driven.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Bootstrap cluster: A temporary, throwaway kind cluster on the install host. It runs the Cluster API controllers that build the real cluster, then it is deleted.
kind: Kubernetes IN Docker: runs a whole Kubernetes cluster as Docker containers on one machine. Used for the bootstrap cluster and local testing.
Pivot: Moving the Cluster API state out of the temporary bootstrap cluster into the new management cluster, so it manages itself.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Node: A worker machine (a VM or physical server) that runs pods.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
GitOps: Managing apps and infrastructure by storing the desired state in a Git repository and having a controller automatically apply changes.
Flux: A CNCF GitOps tool that continuously reconciles a cluster to match the manifests in a Git repo.
Helm / HelmRelease: Helm is the Kubernetes package manager (apps packaged as charts). A HelmRelease is a Flux object that installs and manages one of those charts.
Section 3 · Day 2 Operations 24 questions
Q30Verifiedconfidence: high
NKP's embedded OIDC identity broker is:
- AKeycloak
- BDexcorrect
- COkta
- Dcert-manager
Answer: B
WhyNKP's embedded OIDC identity broker is Dex. Per Nutanix docs, Dex is an open-source federated OpenID Connect provider that acts as an intermediary, federating upstream identity providers (LDAP, SAML, OIDC, GitHub) into the platform so users authenticate with existing enterprise credentials. It integrates with Kubernetes OIDC auth to supply username/group claims for RBAC.
The trapKeycloak and Okta are real identity brokers/IdPs and tempt by familiarity, but they are not what NKP embeds; cert-manager is a TLS certificate controller, not an identity broker, and is a pure category error distractor.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
OIDC: OpenID Connect: a standard protocol for login and identity.
Identity provider (IdP): Your corporate login system (such as Active Directory or Okta) that holds users and groups.
Q31Verifiedconfidence: high
Corporate group memberships should drive NKP permissions. The mechanism:
- ARecreate users by hand
- BConfigure the external IdP in Kommander and map IdP groups to rolescorrect
- CShare one admin token
- DSync /etc/passwd
Answer: B
WhyNKP defers authentication to external identity providers through Dex, an embedded federated OIDC provider in Kommander that connects to upstream LDAP, SAML, OIDC, or GitHub IdPs. Once a user authenticates, NKP applies authorization by mapping the IdP group claims carried in the OIDC token to roles via (Cluster)RoleBindings, typically referencing the group with an 'oidc:' prefix. This lets corporate group membership drive Kubernetes permissions at scale without recreating users.
The trap'Recreate users by hand' and 'Sync /etc/passwd' are anti-patterns that ignore federation entirely; 'Share one admin token' collapses all identity to a single shared secret with no group mapping. Each tempts a learner who thinks of access as user-by-user rather than group-driven SSO.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Secret: Stores sensitive data like passwords, base64-encoded (which is encoding, not encryption, so add RBAC and encryption-at-rest).
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
ClusterRole: Like a Role, but its permissions apply cluster-wide instead of in a single namespace.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
OIDC: OpenID Connect: a standard protocol for login and identity.
Identity provider (IdP): Your corporate login system (such as Active Directory or Okta) that holds users and groups.
Token: A credential string used for programmatic or automation login to the API instead of an interactive password.
Q32Verifiedconfidence: high
A CI pipeline needs to call NKP-managed clusters. Per the blueprint, it authenticates with:
- AA screenshot of the dashboard
- BTokenscorrect
- CThe root password
- DSAML redirects in curl
Answer: B
WhyProgrammatic and automation access to NKP-managed clusters is done with tokens, not interactive login. NKP/Dex issues OIDC bearer tokens for federated user identity, and for non-interactive CI/CD use the standard Kubernetes pattern is a ServiceAccount token (generated via kubectl create token or embedded in a kubeconfig). The token is presented as a bearer credential on each API call, which a pipeline can carry where a browser-based SAML redirect flow cannot.
The trap'A screenshot of the dashboard' and 'SAML redirects in curl' are nonsense for headless automation: an interactive browser redirect flow does not complete in a scripted curl call. 'The root password' confuses host OS auth with Kubernetes API auth. Tokens are the only credential a pipeline actually presents to the API.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
kubectl: The Kubernetes command-line tool; it talks to the API server to create, inspect, and change resources.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
OIDC: OpenID Connect: a standard protocol for login and identity.
Token: A credential string used for programmatic or automation login to the API instead of an interactive password.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Q33Verifiedconfidence: high
Granting a team admin over ONE workspace but nothing else is done at:
- ACluster RBAC on every cluster
- BThe Kommander/workspace role levelcorrect
- CThe Linux sudoers file
- DPrism Central RBAC
Answer: B
WhyKommander has three access-control scopes: global, workspace, and project. To grant a team administrative rights over exactly one workspace and nothing else, you bind the team's IdP group to a workspace-scoped Kommander role (kommander-workspace-admin) within that workspace's namespace on the management cluster. Kommander then federates the corresponding ClusterRoleBindings downward to all target clusters in that workspace only, so the grant is scoped precisely to the workspace's fleet.
The trap'Cluster RBAC on every cluster' is the manual brute-force version that defeats the fleet plane and does not stay scoped. 'Linux sudoers' and 'Prism Central RBAC' are different control planes (host OS and AOS infra) that do not govern Kommander workspace access. The fleet-plane scope is the Kommander role level.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
AOS: Acropolis Operating System: the core Nutanix software on every node that provides the distributed storage and cluster services.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
ClusterRole: Like a Role, but its permissions apply cluster-wide instead of in a single namespace.
Identity provider (IdP): Your corporate login system (such as Active Directory or Okta) that holds users and groups.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Q34Verifiedconfidence: high
A developer needs to create Deployments in one namespace of one cluster only. That is:
- AA Kommander global role
- BPlain Kubernetes RBAC: a Role + RoleBinding in that namespacecorrect
- CAn Ultimate license feature
- DA Dex connector
Answer: B
WhyPermission to create Deployments confined to a single namespace on a single cluster is a textbook native Kubernetes RBAC case: a namespaced Role granting create/get/list on deployments in the apps API group, plus a RoleBinding in that same namespace tying the subject to the Role. This is the inside-the-cluster, namespace-scoped layer beneath Kommander's fleet abstractions, and it does not require a Kommander global role, a license tier, or a Dex connector.
The trap'Kommander global role' and 'Ultimate license feature' over-reach to the fleet plane for a single-namespace need. 'A Dex connector' confuses authentication (who you are) with authorization (what you can do). Note: the keyed answer is exactly right, but precisely speaking this uses a namespaced Role, not a ClusterRole, so the rationale's phrase 'the cluster roles side' is loose wording, not a wrong answer.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
ClusterRole: Like a Role, but its permissions apply cluster-wide instead of in a single namespace.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
Q35Verifiedconfidence: high
Role inheritance in NKP flows:
- ACluster → project → workspace
- BWorkspace → project → cluster contexts (downward)correct
- CRandomly
- DOnly within Dex
Answer: B
WhyKommander RBAC inheritance flows downward from the widest scope to the narrowest: global roles federate to all clusters in all workspaces, workspace roles federate to all clusters in that workspace (and by default propagate to equivalent project roles), and project roles apply to the project's assigned clusters. A grant made at a broader scope cascades into the narrower contexts beneath it, never the reverse. So the direction is workspace to project to cluster contexts.
The trap'Cluster to project to workspace' inverts the direction (narrow scopes do not grant broad ones). 'Randomly' is a throwaway. 'Only within Dex' confuses the authorization/federation model with the authentication provider; Dex handles login, not role inheritance.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Q36Verifiedconfidence: high
Custom roles exist because:
- ABuilt-in roles cannot be combined with groups
- BBuilt-ins may not match an organization's exact permission boundaries; custom roles + bindings go finercorrect
- CThey are required for FIPS
- DDex demands them
Answer: B
WhyKubernetes ships built-in ClusterRoles (cluster-admin, admin, edit, view) that cover common cases, but they often grant more (or different) access than an organization's exact permission boundaries require. Custom Roles/ClusterRoles plus RoleBindings/ClusterRoleBindings let you express least-privilege, namespace-scoped, org-specific access by naming exactly which apiGroups, resources, and verbs are allowed. RBAC permissions are purely additive with no deny rules, so finer-grained custom roles are how you tighten access rather than loosen the built-ins.
The trapThe distractors invoke unrelated mechanisms: FIPS is a crypto-module compliance mode and has nothing to do with role granularity; Dex is the OIDC identity broker that authenticates users and maps groups but does not 'demand' custom roles; built-in roles can absolutely be bound to groups, so 'cannot be combined with groups' is false.
Plain-English terms in this questionFIPS: A US government cryptography compliance standard; NKP offers a FIPS-validated build variant.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
ClusterRole: Like a Role, but its permissions apply cluster-wide instead of in a single namespace.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
OIDC: OpenID Connect: a standard protocol for login and identity.
Q37Verifiedconfidence: high
Which platform component enforces 'no privileged containers' as an admission rule?
- AVelero
- BGatekeeper (OPA)correct
- CLoki
- DAlertmanager
Answer: B
WhyOPA Gatekeeper is a validating admission controller that evaluates incoming API requests against policy expressed as ConstraintTemplates and Constraints before objects are persisted. The Gatekeeper Library ships a 'privileged-containers' policy (K8sPSPPrivilegedContainer) that denies any Pod whose container, init container, or ephemeral container sets securityContext.privileged: true. This admission-time enforcement is exactly the 'no privileged containers' control referenced in NKP's security tooling.
The trapThe other options are real platform components but in different domains: Velero does backup/restore, Loki stores logs, and Alertmanager routes Prometheus alerts. None of them are admission controllers, so none can block a workload at creation time.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Gatekeeper / OPA: Open Policy Agent Gatekeeper enforces admission policies (for example, no privileged containers) by checking resources when they are created.
Admission: The step when a resource is created where a webhook can validate or reject it; Gatekeeper plugs in here.
Prometheus: The metrics database that scrapes and stores time-series numbers (CPU, requests, and so on) from your apps and the cluster.
Alertmanager: Takes alerts fired by Prometheus and routes them to email, Slack, PagerDuty, or a webhook.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Q38Verifiedconfidence: high
The NKP logging stack's log STORE is:
- APrometheus
- BLokicorrect
- Cetcd
- DElasticsearch always
Answer: B
WhyIn NKP's logging stack the log STORE is Grafana Loki, which ingests log chunks (collected by the Alloy/promtail agent and orchestrated by the Logging Operator) and indexes them by label and timestamp; Grafana is the query and viewing layer via LogQL. Prometheus and its etcd-backed control plane are for metrics and cluster state, not log storage, and NKP does not use Elasticsearch as its log backend. By default NKP stores Loki data on Rook Ceph, and it can be repointed to S3-compatible Nutanix Objects.
The trap'Elasticsearch always' is the classic trap because EFK/ELK is the legacy logging mental model many engineers carry over; NKP chose the Loki/Grafana/Logging-Operator (PLG-style) stack instead. Prometheus and etcd tempt because they are real cluster components, but they are metrics and key-value state stores, not log stores.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
etcd: The cluster's key-value database; the single source of truth holding all cluster state and configuration.
Prometheus: The metrics database that scrapes and stores time-series numbers (CPU, requests, and so on) from your apps and the cluster.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Logging Operator / Fluent Bit: The components that collect container logs from across the cluster and ship them into Loki.
Object storage (S3): Storage accessed by the S3 API as buckets and objects. It is where Velero stores backups; examples include Nutanix Objects and MinIO.
Q39Verifiedconfidence: high
Logging in NKP is:
- AAlways on
- BA platform application set you enable per workspace/clustercorrect
- CMandatory for licensing
- DPart of the CSI driver
Answer: B
WhyIn NKP, logging is delivered as a set of platform applications (Logging Operator, Loki, Grafana, the log-forwarding agent) that an administrator enables and configures at the workspace or cluster level; it is not turned on automatically. NKP documents this under Platform Applications and Workspace-level Logging, where you opt the logging stack into a workspace and tune retention/storage. Because it is an optional, enable-on-demand application set, it is independent of licensing and unrelated to the CSI storage driver.
The trap'Always on' and 'Mandatory for licensing' both appeal to the assumption that an enterprise platform must ship logging enabled and tied to entitlement; in reality NKP makes it opt-in per workspace. 'Part of the CSI driver' confuses persistent-volume provisioning with observability, two unrelated subsystems.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
PV / PVC: A PersistentVolume is the actual storage; a PersistentVolumeClaim (PVC) is a pod's request for some. They let data outlive a pod.
CSI: Container Storage Interface: the standard plugin layer connecting Kubernetes to storage systems, including taking volume snapshots.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Logging Operator / Fluent Bit: The components that collect container logs from across the cluster and ship them into Loki.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Q40Verifiedconfidence: high
Restricting which logs a tenant can see is delivered by:
- AMulti-tenant logging (scoped flows/access)correct
- BDeleting other tenants' logs nightly
- COne Grafana per pod
- DTLS
Answer: A
WhyNKP's Multi-Tenant Logging scopes both log collection (flows) and log viewing/access so a given tenant only sees logs from its own namespaces, enforced through tenant-scoped Loki tenancy and Grafana access. This is the supported mechanism for isolating one team's logs from another's in a shared platform. It works by partitioning the logging pipeline per tenant namespace, not by destroying other tenants' data or spinning up one Grafana per pod.
The trap'Deleting other tenants' logs nightly' is an absurd, destructive non-solution that confuses access control with data retention. 'One Grafana per pod' overcomplicates a job done by tenant scoping. 'TLS' tempts because it sounds security-adjacent, but transport encryption protects data in transit, it does not partition who can view which logs.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Multi-tenancy: Serving multiple isolated teams or customers on shared infrastructure without them seeing each other.
Q41Verifiedconfidence: high
Loki needs durable, scalable backend storage. Blueprint-aligned targets:
- ARAM disks
- BS3-compatible object storage / Nutanix Unified Storagecorrect
- CThe bastion's home directory
- DGitHub
Answer: B
WhyGrafana Loki separates ingestion/query compute from long-term chunk storage, which it expects to live on durable, scalable object storage. In NKP the documented persistence path is S3-compatible object storage, specifically Nutanix Objects (part of Nutanix Unified Storage), configured via the Loki application config override. Object storage gives durability, redundancy, and retention beyond the lifecycle of any pod or node, which is exactly what a production logging backend needs.
The trapRAM disks (volatile, not durable), a bastion home directory (not scalable or shared), and GitHub (a code host, not a log store) all sound like 'somewhere to put data' but none provide durable, scalable, S3-style object persistence that Loki's chunk store requires.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Bastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Node: A worker machine (a VM or physical server) that runs pods.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Object storage (S3): Storage accessed by the S3 API as buckets and objects. It is where Velero stores backups; examples include Nutanix Objects and MinIO.
Q42Verifiedconfidence: high
Under heavy log volume the correct response is:
- ADisable logging
- BScale the logging stack components (collectors, Loki)correct
- CShorter pod names
- DMove logs to etcd
Answer: B
WhyLoki is built for horizontal scalability: under heavy log volume you add more replicas of the stack components (collectors/agents and the Loki read/write/ingester/distributor/querier roles) rather than throttling or dropping data. In microservices mode each role is a separate, independently scalable process; in simple-scale mode you scale the read/write/backend targets. Scaling out preserves log fidelity while increasing ingest and query throughput.
The trapDisabling logging defeats the purpose of an observability stack; shortening pod names does nothing for ingest capacity; and pushing logs to etcd is actively harmful since etcd is the control-plane key-value store, not a log sink. The correct instinct under load is always 'scale the component that is saturated.'
Plain-English terms in this questionetcd: The cluster's key-value database; the single source of truth holding all cluster state and configuration.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Q43Verifiedconfidence: highselect 2
Velero's TWO foundational dependencies in NKP:
- AA target object storage location with working credentialscorrect
- BA GPU node pool
- CVolumeSnapshotClasses for CSI snapshots of PV datacorrect
- DA second Prism Central
- EPublic internet
Answer: A, C
WhyVelero has two distinct planes. Kubernetes objects (manifests/metadata) are written to a BackupStorageLocation, which is an S3-compatible object store, and that location needs valid credentials. Persistent-volume data is protected separately through CSI volume snapshots, which require a VolumeSnapshotClass for the cluster's CSI driver (Velero selects one based on labels/annotations). Together, object storage plus CSI VolumeSnapshotClasses are the two foundational dependencies for a working Velero backup of both metadata and PV data.
The trapA GPU node pool and a second Prism Central are unrelated infrastructure that sound 'enterprise' but have nothing to do with backup mechanics. 'Public internet' is a trap because backups commonly target an on-prem/internal S3 endpoint (Nutanix Objects), so internet access is not required.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
PV / PVC: A PersistentVolume is the actual storage; a PersistentVolumeClaim (PVC) is a pod's request for some. They let data outlive a pod.
CSI: Container Storage Interface: the standard plugin layer connecting Kubernetes to storage systems, including taking volume snapshots.
VolumeSnapshotClass: Defines how CSI takes point-in-time snapshots of persistent-volume data. Velero uses it to back up the data inside volumes.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Object storage (S3): Storage accessed by the S3 API as buckets and objects. It is where Velero stores backups; examples include Nutanix Objects and MinIO.
MachineDeployment: The Cluster API object that owns a pool of worker nodes (like a Deployment, but for machines). Different worker pools are different MachineDeployments.
Q44Verifiedconfidence: high
Nightly backups at 02:00 are expressed as:
- AA bash loop on the bastion
- Bvelero schedule create with a cron expressioncorrect
- CA Grafana alert
- DAn LCM policy
Answer: B
WhyRecurring Velero backups are defined with a Schedule resource created via 'velero schedule create NAME --schedule="<cron>"'. For 02:00 nightly the cron expression is "0 2 * * *". The Schedule controller then creates a Backup at each cron tick, so the cron-shaped --schedule flag is the exact CLI vocabulary the exam expects.
The trapA bash loop on the bastion is fragile and unmanaged (no TTL, no controller, no retry). A Grafana alert is monitoring, not backup orchestration. An LCM policy governs Nutanix Life Cycle Manager firmware/software updates, not Velero backups. Only the native Velero schedule with a cron expression is correct.
Plain-English terms in this questionBastion host: A hardened jump-box machine inside a restricted or air-gapped network that you run the install from. It holds the CLI, the image bundle, and the bootstrap cluster, with network reach to Prism Central, the registry, and the nodes.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Q45Verifiedconfidence: high
Recovering namespace team-a from last night's backup:
- Avelero restore create --from-backup <name> (scoped as needed)correct
- Bkubectl undo
- CReinstall NKP
- DSnapshot the AHV VMs
Answer: A
WhyVelero restores are always created from a named existing backup with 'velero restore create --from-backup <backup-name>'. To recover a single namespace you scope it with '--include-namespaces team-a', which restores only that namespace's resources (and its PV data via the snapshot/data-mover plugins). This named-backup-plus-scoping pattern is the standard Velero recovery vocabulary.
The trapThere is no 'kubectl undo' command. Reinstalling NKP rebuilds the platform but does not restore workload state. Snapshotting the AHV VMs is a hypervisor-level operation that bypasses Kubernetes object and PVC consistency, so it is not how you recover a namespace. Only the Velero restore-from-backup CLI is correct.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
AHV: Nutanix's built-in hypervisor, their alternative to VMware ESXi.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
kubectl: The Kubernetes command-line tool; it talks to the API server to create, inspect, and change resources.
PV / PVC: A PersistentVolume is the actual storage; a PersistentVolumeClaim (PVC) is a pod's request for some. They let data outlive a pod.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Q46Verifiedconfidence: high
Backups succeed but PV data is missing from them. Check:
- AThe exam blueprint
- BVolume snapshot class configuration (CSI snapshots not happening)correct
- CGrafana version
- DNode count
Answer: B
WhyWhen Velero backups succeed but persistent-volume data is missing, the object/resource backup path is working but the CSI volume-snapshot path is broken. Velero relies on a VolumeSnapshotClass whose driver name matches the PV's CSI driver, identified via the label velero.io/csi-volumesnapshot-class: "true" or a default-class annotation. If no matching VolumeSnapshotClass exists (or CSI snapshotting isn't enabled), Velero captures Kubernetes resources but no PV data, so checking the snapshot class is the correct first stop.
The trapDistractors are deliberately off-topic noise (exam blueprint, Grafana version, node count). They tempt a test-taker who panics and reaches for an unrelated knob instead of reasoning that object data present + volume data absent isolates the failure to the snapshot subsystem.
Plain-English terms in this questionKubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
PV / PVC: A PersistentVolume is the actual storage; a PersistentVolumeClaim (PVC) is a pod's request for some. They let data outlive a pod.
CSI: Container Storage Interface: the standard plugin layer connecting Kubernetes to storage systems, including taking volume snapshots.
VolumeSnapshotClass: Defines how CSI takes point-in-time snapshots of persistent-volume data. Velero uses it to back up the data inside volumes.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Q47Verifiedconfidence: high
The monitoring stack trio is:
- ALoki, Fluent Bit, Grafana
- BPrometheus (metrics), Alertmanager (routing), Grafana (dashboards)correct
- CVelero, Dex, Traefik
- DNCC, LCM, Pulse
Answer: B
WhyNKP's metrics/monitoring stack is the kube-prometheus-stack trio: Prometheus scrapes and stores metrics, Alertmanager deduplicates and routes alerts to receivers, and Grafana renders dashboards. This is distinct from the logging stack, where Fluent Bit collects logs and ships them to Loki, also visualized in Grafana. Velero (backup), Dex (auth/OIDC), and Traefik (ingress) are separate platform applications, not the monitoring trio.
The trapOption A swaps in the logging-stack components (Loki, Fluent Bit) plus Grafana, which is the most seductive distractor because Grafana legitimately appears in both stacks. Option C mixes unrelated platform apps, and D lists Nutanix infrastructure tools (NCC, LCM, Pulse) that belong to AOS/Prism, not the Kubernetes observability stack.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
AOS: Acropolis Operating System: the core Nutanix software on every node that provides the distributed storage and cluster services.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
OIDC: OpenID Connect: a standard protocol for login and identity.
Prometheus: The metrics database that scrapes and stores time-series numbers (CPU, requests, and so on) from your apps and the cluster.
Alertmanager: Takes alerts fired by Prometheus and routes them to email, Slack, PagerDuty, or a webhook.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Logging Operator / Fluent Bit: The components that collect container logs from across the cluster and ship them into Loki.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Q48Verifiedconfidence: medium
Fleet-wide health from one pane is achieved through:
- ALogging into each cluster's Grafana
- BCentralized metrics on the management clustercorrect
- CAn email digest
- DPrism Element
Answer: B
WhyIn NKP, the management cluster is the central control plane that hosts cluster managers and aggregates observability across attached/managed clusters. Fleet-wide health from a single pane comes from centralizing metrics on the management cluster (NKP federates/aggregates Prometheus data for a highly available, long-term metrics view), not from visiting each cluster's local Grafana. This is what gives a single dashboard view across on-prem, cloud, edge, and air-gapped clusters.
The trapOption A (logging into each cluster's Grafana) describes exactly the per-cluster silo that centralized monitoring is designed to eliminate, so it tempts anyone who hasn't internalized the management-cluster role. Email digest is a notification channel, not a health pane, and Prism Element is per-AOS-cluster infrastructure UI, unrelated to multi-cluster Kubernetes fleet observability.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Element: The management UI for a single Nutanix cluster (one cluster's local console).
AOS: Acropolis Operating System: the core Nutanix software on every node that provides the distributed storage and cluster services.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
ClusterRole: Like a Role, but its permissions apply cluster-wide instead of in a single namespace.
Prometheus: The metrics database that scrapes and stores time-series numbers (CPU, requests, and so on) from your apps and the cluster.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Q49Verifiedconfidence: high
Scraping a Customer application's own metrics into the platform stack involves:
- AEditing Prometheus' binary
- BCustom service-level metrics (ServiceMonitor-style configuration)correct
- CPulse
- DA new license
Answer: B
WhyTo scrape a customer/application's own metrics into the platform's Prometheus, you declare a ServiceMonitor (or PodMonitor) custom resource that selects the app's service via labels and names the metrics port and path. The Prometheus Operator continuously reconciles these CRDs into Prometheus scrape configs, so you never edit Prometheus directly. This is the Kubernetes-native pattern for custom service-level metrics.
The trapOption A (editing the Prometheus binary) is an absurd anti-pattern that tempts only someone who doesn't know the Operator model; you never patch the binary or even hand-edit config in an operator-managed stack. Pulse is Nutanix telemetry phone-home, and 'a new license' is a money distractor, both unrelated to in-cluster scrape configuration.
Plain-English terms in this questionKubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Service: A stable virtual IP and DNS name that load-balances traffic to a set of pods (pods come and go, the Service address stays).
Prometheus: The metrics database that scrapes and stores time-series numbers (CPU, requests, and so on) from your apps and the cluster.
ServiceMonitor: A small config object that tells Prometheus which app endpoint to scrape for custom metrics.
Q50Verifiedconfidence: high
Sending critical alerts to PagerDuty/webhook/email is configured in:
- AThe CSI driver
- BAlert rules + notification endpoints (Alertmanager configuration)correct
- CDex
- DKIB
Answer: B
WhyAlerting splits into two halves: Prometheus evaluates alerting rules to decide when an alert fires, then forwards firing alerts to Alertmanager. Alertmanager owns deduplication, grouping, silencing/inhibition, and routing to receiver integrations such as PagerDuty, email, and generic webhooks. So configuring where critical alerts are sent means defining alert rules plus Alertmanager notification endpoints (receivers and the routing tree).
The trapThe CSI driver (storage), Dex (OIDC authentication), and KIB (Konvoy Image Builder, for machine images) are all real NKP/Kubernetes components, which makes them plausible to someone who recognizes the names but doesn't know their function. Only Alertmanager handles alert routing and notification endpoints.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
CSI: Container Storage Interface: the standard plugin layer connecting Kubernetes to storage systems, including taking volume snapshots.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
OIDC: OpenID Connect: a standard protocol for login and identity.
Prometheus: The metrics database that scrapes and stores time-series numbers (CPU, requests, and so on) from your apps and the cluster.
Alertmanager: Takes alerts fired by Prometheus and routes them to email, Slack, PagerDuty, or a webhook.
Q51Verifiedconfidence: high
Cluster Autoscaler triggers scale-UP when:
- ACPU is above 50% anywhere
- BPods are unschedulable due to insufficient node resourcescorrect
- CGrafana says so
- DThe admin is asleep
Answer: B
WhyThe Kubernetes Cluster Autoscaler scales UP when pods fail to schedule on any existing node due to insufficient resources (Pending/Unschedulable pods). It explicitly does NOT use CPU/memory utilization as a scale-up signal; the FAQ states metric-based autoscalers 'don't care about pods' and are unsuitable for this. Scale-DOWN is the utilization-driven side: a node is removed when its requested CPU+memory falls below the scale-down utilization threshold (default 50%) for the unneeded-time window and its pods can move elsewhere, all bounded by the pool's min/max.
The trapOption A ('CPU above 50% anywhere') is the classic confusion: 50% is real but it is the scale-DOWN utilization threshold, not a scale-UP trigger, and it applies per node, not 'anywhere.' Test-takers who half-remember the 50% number get pulled to A. C and D are throwaway humor distractors.
Plain-English terms in this questionKubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Node: A worker machine (a VM or physical server) that runs pods.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Cluster Autoscaler: Automatically adds nodes when pods cannot be scheduled and removes idle nodes, within a min and max you set per node pool.
Q52Verifiedconfidence: high
Autoscaling configuration in NKP is:
- AGlobal only
- BPer node pool, with provider-specific configuration (Nutanix/AWS/vSphere)correct
- CPer pod
- DHard-coded
Answer: B
WhyIn NKP, autoscaling is enabled per node pool by specifying minimum and maximum node counts; the autoscaler then keeps the pool between those bounds. The underlying mechanism is Cluster API per-provider (CAPX for Nutanix AHV, plus AWS/vSphere providers), so the configuration details and capacity hints are provider-specific even though the per-pool min/max model is consistent. Scale-from-zero, for example, requires per-provider capacity annotations so the autoscaler can simulate scheduling against a virtual template.
The trap'Global only' and 'per pod' invert the actual granularity: autoscaling is node-pool scoped, not cluster-global and not pod-level (HPA is pod-level, a different control). 'Hard-coded' contradicts the explicit min/max user configuration.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
AHV: Nutanix's built-in hypervisor, their alternative to VMware ESXi.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Node: A worker machine (a VM or physical server) that runs pods.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
MachineDeployment: The Cluster API object that owns a pool of worker nodes (like a Deployment, but for machines). Different worker pools are different MachineDeployments.
Cluster Autoscaler: Automatically adds nodes when pods cannot be scheduled and removes idle nodes, within a min and max you set per node pool.
Q53Verifiedconfidence: high
The safe upgrade sequence for an NKP estate is:
- AWorkload clusters then management
- BManagement cluster (and Kommander) first, then workload clusters; air gaps seed the new bundle firstcorrect
- CAlphabetical
- DOnly Kommander ever upgrades
Answer: B
WhyThe supported NKP upgrade sequence is top-down: upgrade the management cluster (Kommander and the management-cluster platform applications) first, then upgrade the managed/workload clusters (their platform applications, then the Kubernetes/NKP version and node OS images). In air-gapped estates you seed the new release bundle into the local/private registry before anything tries to pull it, otherwise the upgrade stalls on missing images. This ordering keeps the control plane that orchestrates the fleet ahead of the fleet it manages.
The trap'Workload clusters then management' is the seductive reverse: people assume you upgrade leaf clusters first to 'test' before touching the controller, but that breaks the management/Kommander-orchestrated model. Alphabetical and 'only Kommander upgrades' are nonsense distractors.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Air-gapped: An environment with zero internet access, isolated on purpose for security. Software and container images must be physically carried in.
Air-gapped bundle: One downloadable tarball containing every NKP container image plus install artifacts, transferred across the air gap.
Private registry / seeding: A private image registry is a local store of container images inside your network. Seeding it means pushing the bundle's images in so air-gapped clusters can pull images without internet.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Control plane: The brain of a cluster: the API server, etcd, scheduler, and controller-manager that decide and store what the cluster should be doing.
Node: A worker machine (a VM or physical server) that runs pods.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Section 4 · Fleet Management 22 questions
Q54Verifiedconfidence: high
The TOP-level isolation construct in Kommander is the:
- ANamespace
- BWorkspacecorrect
- CProject
- DStorageClass
Answer: B
WhyIn NKP Kommander the top-level organizational/isolation construct is the Workspace, which groups clusters, governs them with shared configuration and RBAC, and hosts platform/catalog applications and dashboards. Projects sit beneath workspaces and subdivide them (the hierarchy is Global > Workspace > Project), mapping to platform admins, team leads, and developers respectively. A Kubernetes Namespace and a StorageClass are in-cluster primitives, not Kommander's fleet-level isolation tier.
The trapNamespace and Project both tempt because they are real isolation units, but Namespace is in-cluster (below NKP's fleet model) and Project is a sub-division of a Workspace, not the top. StorageClass is unrelated to tenancy.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
StorageClass: Defines a type of dynamically-provisioned storage. A cluster needs a default one or apps that request storage sit Pending.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Q55Verifiedconfidence: medium
Tenant A and Tenant B must never share dashboards, apps, or admins. Layout:
- AOne workspace, two projects
- BTwo workspaces (one per tenant), with per-tenant login URLscorrect
- CTwo namespaces
- DTwo clusters in one project
Answer: B
WhyWhen two tenants must share nothing (dashboards, applications, admins), the correct NKP design is one Workspace per tenant, because the Workspace is the boundary that scopes clusters, applications, dashboards, and RBAC. Putting both tenants in one workspace (split only by projects) leaks workspace-level admins, applications, and dashboards across tenants, so 'one workspace, two projects' is insufficient for hard isolation. Namespaces and a shared project likewise sit below the tenancy boundary.
The trap'One workspace, two projects' is the strong distractor: projects do partition developer access, but they live inside a single workspace and therefore share workspace admins, catalog apps, and dashboards, exactly what the scenario forbids. Namespaces and 'two clusters in one project' isolate even less.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Q56Verifiedconfidence: high
A workspace's 'infrastructure provider' is best described as:
- AThe physical switch vendor
- BStored credentials/endpoint Kommander uses to deploy managed clusters into a target platform for that workspacecorrect
- CThe CSI driver
- DA Dex connector
Answer: B
WhyIn NKP/Kommander an infrastructure provider is the stored credential plus endpoint object (for Nutanix, Prism Central credentials and address) that Kommander uses to provision managed/workload clusters into a target platform. Providers are configured per workspace, and NKP Pro can add multiple providers of the same type (for example two or more Prism Central instances). It is neither a physical switch reference, a CSI driver, nor a Dex connector (Dex/connectors are identity, CSI is storage).
The trapDistractors swap in adjacent infrastructure concepts: CSI driver (storage plumbing), Dex connector (identity federation), and a literal hardware/switch reading. All are real NKP-adjacent terms but none is the deploy-target credential/endpoint wiring.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
CSI: Container Storage Interface: the standard plugin layer connecting Kubernetes to storage systems, including taking volume snapshots.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Q57Verifiedconfidence: high
Granting cluster-admin-like rights across every current AND future cluster in a workspace is done via:
- APer-cluster kubeconfig edits
- BWorkspace-level access control (role bindings that federate to member clusters)correct
- CSSH keys
- DA Gatekeeper policy
Answer: B
WhyKommander defines RBAC once at a scope (Global, Workspace, Project) and federates it to target clusters. A workspace-scoped Cluster Role binding federates ClusterRoles/ClusterRoleBindings to every target cluster in the workspace, and personas/policies created in a workspace are federated to all attached clusters, so clusters joining later inherit the binding automatically. Editing per-cluster kubeconfigs, SSH keys, or a Gatekeeper policy would not deliver this federated, future-inclusive RBAC.
The trapThe per-cluster kubeconfig answer tempts admins thinking in raw kubectl terms; SSH keys conflate node access with Kubernetes RBAC; Gatekeeper is admission-control policy, not authorization grants.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
kubectl: The Kubernetes command-line tool; it talks to the API server to create, inspect, and change resources.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
ClusterRole: Like a Role, but its permissions apply cluster-wide instead of in a single namespace.
Gatekeeper / OPA: Open Policy Agent Gatekeeper enforces admission policies (for example, no privileged containers) by checking resources when they are created.
Admission: The step when a resource is created where a webhook can validate or reject it; Gatekeeper plugs in here.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Q58Verifiedconfidence: high
Workspace applications can be:
- AEnabled for the workspace and optionally per cluster within itcorrect
- BOnly global
- COnly per pod
- DLicensed separately each
Answer: A
WhyWorkspace (platform) applications in NKP/Kommander are enabled at the workspace level, which deploys them to all clusters in that workspace; you can also enable or customize an application on specific clusters within the workspace via AppDeployment resources. So the correct framing is workspace-enabled with optional per-cluster enablement. They are not global-only, not per-pod, and not separately licensed per app.
The trap'Only global' overstates scope; 'only per pod' confuses workloads with platform apps; 'licensed separately each' invents a per-app licensing model. The right answer pairs workspace default scope with the per-cluster override capability.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Q59Verifiedconfidence: high
Deploying a managed workload cluster is initiated from:
- APrism Element
- BKommander (UI) or the nkp CLI, into a chosen workspacecorrect
- CThe attached cluster itself
- DKIB
Answer: B
WhyDeploying a managed/workload cluster is a management-plane (fleet) operation driven from Kommander, either via the NKP UI (Clusters > Add Cluster > Create Cluster) or the nkp CLI (nkp create cluster), targeting a chosen workspace. It is not initiated from Prism Element, from the workload cluster itself (which does not yet exist), or from KIB (Konvoy Image Builder, which only builds machine images).
The trapPrism Element tempts because Nutanix admins live there, but NKP cluster lifecycle runs from the management cluster/Kommander; KIB is an image-prep tool, not a deploy orchestrator; the attached cluster cannot deploy itself.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Prism Element: The management UI for a single Nutanix cluster (one cluster's local console).
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Q60Verifiedconfidence: high
A workload cluster deploy to vSphere needs templates; the same deploy to Nutanix needs subnets/images via Prism Central. This illustrates:
- AA bug
- BThe impact of target provider environments on deploymentscorrect
- CLicense differences
- DCNI choice
Answer: B
WhyNKP uses Cluster API, so the target infrastructure provider determines the required parameters and available capabilities: a vSphere deploy needs a VM template, while a Nutanix deploy needs subnets and an OS image selected through Prism Central. This is the expected, by-design impact of the target provider environment on a deployment, not a bug, a licensing artifact, or a CNI decision.
The trap'CNI choice' is a tempting near-miss because CNI is also configured at cluster create time, but CNI is pod networking, not the provider-specific machine inputs. 'License differences' and 'a bug' are throwaway distractors.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
CNI: Container Network Interface: the plugin that gives pods their networking. If it is broken, nodes stay NotReady.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q61Verifiedconfidence: medium
A workload cluster deployment fails instantly with authorization errors before any Machines exist. Check:
- AThe workspace's infrastructure provider credentialscorrect
- BLoki retention
- CThe project quota
- DVelero
Answer: A
WhyIn NKP, infrastructure provider credentials (Prism Central / cloud API keys) are configured at the workspace level and are consumed by Cluster API when it provisions a workload cluster. If those credentials are missing, wrong, or under-privileged, CAPI fails the request at the API/authorization stage before it ever asks the infra provider to stand up any Machine or VM. Loki retention, project quota, and Velero are post-provisioning or unrelated concerns, so an instant auth failure with zero Machines points squarely at provider wiring on the workspace.
The trapProject quota (C) tempts because quota also blocks deployment, but a quota breach produces a quota/admission error, not an authorization error, and usually after the request is accepted. Loki and Velero are pure distractors (logging/backup) with no role in provisioning auth.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
Admission: The step when a resource is created where a webhook can validate or reject it; Gatekeeper plugs in here.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Velero: The Kubernetes backup-and-restore tool. It backs up cluster resources to object storage and, with CSI snapshots, the data inside persistent volumes.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q62Verifiedconfidence: highselect 2
Attaching an existing conformant cluster requires (pick TWO):
- ANetwork reachability from the management cluster OR a tunneled attachmentcorrect
- BRebuilding the cluster with KIB images
- CA kubeconfig with sufficient privilegecorrect
- DAn Ultimate license is never needed
- EDeleting its existing workloads
Answer: A, C
WhyTo attach an existing cluster, Kommander needs to reach its API server, either directly (network reachability from the management cluster) or through a tunnel/TunnelConnector when the target sits behind network restrictions, plus a kubeconfig with enough privilege (effectively cluster-admin) to install the federated platform components. Since DKP/NKP 2.6, any x86-64 CNCF-conformant cluster can attach as-is; you do not rebuild it with KIB images and you do not delete its running workloads. Managing external/non-Nutanix clusters (EKS, AKS, GKE) is an NKP Ultimate capability, so 'Ultimate is never needed' is false in the general case.
The trapRebuilding with KIB (B) and deleting workloads (E) play on the false belief that attaching is destructive, but attach is non-disruptive and reversible (detach leaves the cluster running). 'Ultimate is never needed' (D) tempts because attaching another NKP-built cluster can be done at Pro, but external clusters require Ultimate, so the absolute statement is wrong.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
KIB (Konvoy Image Builder): NKP's tool that bakes machine images (an OS plus the Kubernetes components and hardening) that cluster nodes boot from.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
API server: The single entry point to a cluster. Every tool (kubectl, the UI, controllers) talks to it.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
EKS / AKS / GKE: The managed Kubernetes services run by AWS (EKS), Azure (AKS), and Google (GKE).
Q63Verifiedconfidence: medium
EKS attachment has extra steps compared to a generic cluster because:
- AEKS is not Kubernetes
- BCloud IAM/auth must be prepared ('EKS: Preparing the Cluster') so Kommander can authenticatecorrect
- CEKS lacks namespaces
- DIt requires FIPS
Answer: B
WhyAmazon EKS uses AWS IAM as its authentication layer, so before Kommander can attach and federate platform apps it must be able to authenticate to the EKS API server. That means preparing the cluster's IAM/aws-auth mapping (and aws-iam-authenticator-based kubeconfig) so the management cluster's identity is granted cluster access, an extra step a generic conformant cluster does not need because it ships its own static kubeconfig credentials. EKS is fully Kubernetes-conformant, has namespaces, and does not require FIPS, so the only real differentiator is the cloud IAM/auth wiring.
The trap'EKS is not Kubernetes' (A) and 'EKS lacks namespaces' (C) are factually false. 'Requires FIPS' (D) is an unrelated compliance distractor. The single true differentiator is IAM-based authentication, which is why B is correct.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
FIPS: A US government cryptography compliance standard; NKP offers a FIPS-validated build variant.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
API server: The single entry point to a cluster. Every tool (kubectl, the UI, controllers) talks to it.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
EKS / AKS / GKE: The managed Kubernetes services run by AWS (EKS), Azure (AKS), and Google (GKE).
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Q64Verifiedconfidence: high
Platform apps on a freshly attached cluster sit Pending on storage. The named fix:
- ABigger nodes
- BCreate/designate a default StorageClass on the attached clustercorrect
- CReinstall Kommander
- DDetach and reattach
Answer: B
WhyKommander requires a default StorageClass on a cluster before it can land its platform applications, because several of them (logging, monitoring, etc.) request PersistentVolumeClaims. On a freshly attached cluster with no default StorageClass, those PVCs have nothing to bind to and the apps sit Pending. The documented fix is to identify or create a production-grade CSI StorageClass and mark it default with the storageclass.kubernetes.io/is-default-class: "true" annotation, not to add bigger nodes or reinstall.
The trap'Bigger nodes' (A) tempts when you assume Pending means resource starvation, but storage-Pending is a binding problem, not a CPU/memory one. Reinstall (C) and detach/reattach (D) are sledgehammers that do not address the missing StorageClass and would just reproduce the same Pending state.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
StorageClass: Defines a type of dynamically-provisioned storage. A cluster needs a default one or apps that request storage sit Pending.
PV / PVC: A PersistentVolume is the actual storage; a PersistentVolumeClaim (PVC) is a pod's request for some. They let data outlive a pod.
CSI: Container Storage Interface: the standard plugin layer connecting Kubernetes to storage systems, including taking volume snapshots.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Q65Verifiedconfidence: high
Which operation can Kommander NOT perform on an attached (vs managed) cluster?
- ADeploy platform applications
- BFederate RBAC
- CUpgrade its Kubernetes version / scale its node poolscorrect
- DShow its metrics centrally
Answer: C
WhyAn attached cluster is one Kommander did not create, so Kommander has no Cluster API control over its lifecycle: it cannot upgrade the cluster's Kubernetes version or scale its node pools. The D2iQ docs state it plainly: 'You cannot manage an Attached cluster's lifecycle, but you can monitor it.' What Kommander can still do federates fine across attached clusters: deploy platform applications, federate RBAC/roles, and centralize metrics/observability. Lifecycle operations remain the responsibility of whatever provisioned the attached cluster (e.g., EKS, AKS, or another tool).
The trapAll four options are real Kommander capabilities for managed clusters, which tempts you to pick a federation feature. The distinction hinges on managed vs attached: only lifecycle (upgrade/scale, C) is unavailable for attached clusters, while app deployment, RBAC federation, and central metrics work on both.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Node: A worker machine (a VM or physical server) that runs pods.
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
EKS / AKS / GKE: The managed Kubernetes services run by AWS (EKS), Azure (AKS), and Google (GKE).
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
MachineDeployment: The Cluster API object that owns a pool of worker nodes (like a Deployment, but for machines). Different worker pools are different MachineDeployments.
Q66Verifiedconfidence: high
Decommissioning: the correct pairing is:
- ADetach managed, delete attached
- BDetach attached (keeps running), delete managed (destroys cluster + provider resources)correct
- CDelete both
- DDetach requires recreating the cluster
Answer: B
WhyNKP distinguishes attached from managed clusters. Attached clusters were created outside NKP, so you detach them: detach removes the cluster from NKP/Kommander management while the cluster and its workloads keep running (you then manually disconnect Flux from the management Git repo). Managed clusters were provisioned by NKP, cannot be detached, and are instead deleted, which destroys the Kubernetes cluster and all of its underlying provider/cloud infrastructure resources.
The trapOption A inverts the verbs (you do not detach a managed cluster nor delete an attached one as the primary action). Option C over-destroys both. Option D falsely claims detach is destructive. The trap is conflating detach (non-destructive, attached) with delete (destructive, managed).
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Flux: A CNCF GitOps tool that continuously reconciles a cluster to match the manifests in a Git repo.
Q67Verifiedconfidence: high
'Delete an NKP Cluster with One Command' refers to:
- Akubectl delete ns kommander
- Bnkp delete cluster (CLI teardown of a managed cluster)correct
- Crm -rf /
- DA Prism Central action
Answer: B
WhyNKP 2.12 documents a procedure titled 'Delete a NKP Cluster with One Command,' which uses the NKP CLI: nkp delete cluster --cluster-name <name> (with --self-managed when tearing down a self-managed/management cluster). The single command tears down the managed cluster along with the provider infrastructure resources it provisioned. This is a CLI teardown of a managed cluster, not a Kommander-namespace deletion or a Prism Central action.
The trapOption A (kubectl delete ns kommander) tempts because Kommander is the NKP management component, but deleting that namespace does not cleanly tear down a workload cluster's infrastructure. Option D wrongly attributes Kubernetes lifecycle to Prism Central. Option C is the obvious joke distractor.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Prism Central: Nutanix's console for managing many Nutanix clusters at once. NKP calls its API to provision and manage cluster nodes.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Workload cluster: A cluster that actually runs your applications, provisioned and governed by the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
kubectl: The Kubernetes command-line tool; it talks to the API server to create, inspect, and change resources.
Managed cluster: A cluster NKP created and owns the full lifecycle of, so it can upgrade and scale it.
Q68Verifiedconfidence: high
A cluster deletion hangs indefinitely. Two classic culprits worth checking first are stuck finalizers and:
- AToo many labels
- BInvalid infrastructure provider credentials (cannot destroy unreachable resources)correct
- CGrafana sessions
- DQuota overage
Answer: B
WhyNKP clusters are lifecycle-managed by Cluster API (CAPI), so a hung deletion almost always traces to two causes. First, stuck finalizers: a Cluster, Machine, MachinePool, or infrastructure object keeps its finalizer because a cleanup step failed, leaving the resource in Terminating. Second, the controller cannot reach or destroy the underlying cloud/provider resources, typically because the infrastructure provider credentials are invalid or expired, so the destroy call errors and the finalizer is never removed, orphaning the resources.
The trapLabels (A), Grafana sessions (C), and quota overage (D) are unrelated to teardown mechanics; they sound plausible as generic Kubernetes noise. The trap is picking a benign-sounding operational item instead of the credential/reachability failure that genuinely blocks CAPI's reconcile-delete loop.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q69Verifiedconfidence: high
A project, precisely, is:
- AA Git repository
- BA slice of a workspace projecting shared namespaces + RBAC + quotas + apps onto selected member clusterscorrect
- CA separate management cluster
- DA billing unit only
Answer: B
WhyIn NKP's three-tier multi-tenancy model (Global > Workspace > Project), a Project is a subdivision within a workspace. It provisions a namespace (with associated RBAC role bindings, resource quotas, and network policies) onto the selected member clusters of its workspace, and it can deploy/scope applications to that namespace. Workspaces are the cluster/team-level boundary; projects are the namespace/team-or-app-level slice inside them.
The trapOption A confuses a project with the GitOps repo backing it. Option C confuses a project with a separate management cluster. Option D reduces a governance construct to billing. The trap is mistaking the delivery mechanism (Git/Flux) or infrastructure (clusters) for the logical tenancy slice.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Role / RoleBinding: A Role lists allowed actions within one namespace; a RoleBinding grants that Role to a user, group, or service account.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
GitOps: Managing apps and infrastructure by storing the desired state in a Git repository and having a controller automatically apply changes.
Flux: A CNCF GitOps tool that continuously reconciles a cluster to match the manifests in a Git repo.
Multi-tenancy: Serving multiple isolated teams or customers on shared infrastructure without them seeing each other.
Q70Verifiedconfidence: high
Three teams share one workspace's six clusters; each team needs its own namespace set, ceilings, and deploy pipeline. Model this as:
- AThree workspaces
- BThree projects within the workspacecorrect
- CEighteen clusters
- DThree Dex instances
Answer: B
WhyAll three teams share the same set of six clusters and the same administrative/governance domain, so they belong in one workspace. Each team's separate namespace set, resource ceilings (quotas), and deploy pipeline map exactly to an NKP Project, which provisions per-team namespaces, RBAC, and quotas across the workspace's member clusters. Therefore: one workspace, three projects.
The trapThree workspaces (A) over-isolates and duplicates the cluster fleet management when the clusters are shared. Eighteen clusters (C) confuses logical tenancy with physical provisioning. Three Dex instances (D) confuses identity-provider plumbing with the tenancy/quota construct; NKP runs a single Dex for identity federation, not one per team.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
RBAC: Role-Based Access Control: Kubernetes' permission system that decides who can do what.
Dex: NKP's embedded identity broker. It federates your corporate identity provider (LDAP, SAML, or OIDC) into the platform so people log in with existing credentials.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Q71Verifiedconfidence: high
Project-level quotas and limit ranges:
- AApply only to the management cluster
- BFederate resource ceilings to the project's namespaces across its member clusterscorrect
- CAre advisory
- DBlock attach operations
Answer: B
WhyIn NKP/Kommander, Project Quotas and Limit Ranges are set once at the project level and applied to all of the project's member clusters. They are implemented as a Kubernetes FederatedResourceQuota (named 'kommander'), which is what distributes/enforces the resource ceilings into the project's namespace on each member cluster. This is the multi-cluster generalization of a per-namespace ResourceQuota/LimitRange.
The trapOption A ('management cluster only') tempts because Kommander runs on the management cluster, but the whole point of a project is to federate to member clusters. 'Advisory' (C) confuses ResourceQuota with soft warnings; quotas hard-block admission. 'Block attach operations' (D) confuses resource ceilings with cluster lifecycle.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Management cluster: The long-lived cluster that runs Cluster API and Kommander and manages all the other (workload) clusters.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
Admission: The step when a resource is created where a webhook can validate or reject it; Gatekeeper plugs in here.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Attached cluster: An existing outside cluster (for example EKS) that NKP governs (apps, RBAC, dashboards) but did not create, so it cannot change that cluster's lifecycle.
Q72Verifiedconfidence: high
Project Continuous Deployment in NKP is:
- AJenkins bundled
- BGitOps (Flux-based): a Git repo whose manifests sync automatically to the project's clusterscorrect
- CManual kubectl apply
- DAn Ultimate-only CLI
Answer: B
WhyNKP Project Continuous Deployment is GitOps backed by Flux CD: you point a project at a Git repository and its manifests are continuously, declaratively reconciled to the project's associated clusters. The feature is named 'Continuous Delivery with GitOps' and supports auditable, reversible, canary/A-B/rollback workflows. It is not Jenkins, not manual kubectl, and not gated to a single license tier.
The trap'Jenkins bundled' (A) and 'manual kubectl apply' (C) are pre-GitOps mental models. 'Ultimate-only CLI' (D) tempts those who assume advanced features are paywalled; GitOps/Flux is the standard project deployment path, not a CLI-only Ultimate feature.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
License tiers: NKP comes in tiers: Starter (basic cluster deploys), Pro (adds the production platform-app stack), and Ultimate (adds fleet management, multi-tenancy, NKP Insights, and attaching external clusters like EKS/AKS/GKE).
Deployment: A controller that runs and scales a set of identical stateless pods and handles rolling updates and rollbacks.
kubectl: The Kubernetes command-line tool; it talks to the API server to create, inspect, and change resources.
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
GitOps: Managing apps and infrastructure by storing the desired state in a Git repository and having a controller automatically apply changes.
Flux: A CNCF GitOps tool that continuously reconciles a cluster to match the manifests in a Git repo.
Q73Verifiedconfidence: high
You need one identical Secret present in a project's namespace on all five member clusters, kept in sync. Use:
- AEmail
- BFederated resources at the project levelcorrect
- CA USB stick
- DStatefulSets
Answer: B
WhyTo keep one identical Secret present and in sync in a project's namespace across all member clusters, use project-level federated resources. Kommander projects support project ConfigMaps and Secrets that are distributed to each project namespace via Kubernetes federation (FederatedSecret / FederatedConfigMap), so the same object is stamped and maintained on every member cluster. StatefulSets are workload controllers, not a cross-cluster sync mechanism.
The trap'StatefulSets' (D) tempts because it sounds like persistent/stateful Kubernetes plumbing, but it governs pod identity/storage within one cluster, not cross-cluster object replication. Email/USB (A,C) are obvious manual non-answers.
Plain-English terms in this questionKommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Kubernetes: Open-source system for deploying, scaling, and managing containerized applications across a fleet of machines.
Pod: The smallest deployable unit in Kubernetes: one or more containers sharing a network address and storage.
Namespace: A virtual partition inside a cluster used to isolate and organize resources, and to scope permissions and quotas.
StatefulSet: Like a Deployment but for stateful apps such as databases, giving each pod a stable identity and storage.
ConfigMap: Stores non-sensitive external configuration (like URLs) so you can change settings without rebuilding images.
Secret: Stores sensitive data like passwords, base64-encoded (which is encoding, not encryption, so add RBAC and encryption-at-rest).
Project: A subdivision of a workspace that projects shared namespaces, quotas, RBAC, and apps onto a chosen set of member clusters (the team-level slice).
Q74Verifiedconfidence: high
Enabling a dashboard app fails until its datastore app is enabled. This is:
- AA license bug
- BA platform application dependencycorrect
- CScope confusion
- DA CAPI error
Answer: B
WhyNKP platform applications have explicit dependencies; an app will not become healthy until the apps it depends on are enabled first. The canonical example is the monitoring/logging stack: Grafana (the dashboard) depends on Grafana Loki (the datastore), so you must enable Loki (and its supporting rook-ceph object store) before Grafana works. This is a platform application dependency, not a licensing or CAPI fault.
The trap'License bug' (A) and 'CAPI error' (D) are tempting because failed enablement looks like an error, but the root cause is an unmet declared dependency. 'Scope confusion' (C) is the wrong axis (workspace vs cluster), not the ordering problem here.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Grafana: The dashboard tool that visualizes metrics from Prometheus and logs from Loki.
Loki: The log store: the logging counterpart to Prometheus. Grafana queries it to show logs.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
Platform application: One of the bundled apps NKP deploys onto clusters (Prometheus, Loki, Velero, Gatekeeper, and so on).
Cluster API (CAPI): A Kubernetes project (CAPI) that creates, upgrades, and scales clusters declaratively, by defining clusters as Kubernetes objects.
Q75Verified (confirmed on re-check)confidence: medium
One cluster in a workspace needs different app config than the rest. The blueprint mechanism:
- AFork the app
- BGlobal/workspace scope config with a CLUSTER-scope override on the exception (narrower scope wins)correct
- CA second Kommander
- DManual edits on that cluster
Answer: B
WhyWhen one cluster in a workspace needs different application config than the rest, NKP layers a cluster-scoped override (clusterConfigOverrides) on top of the global/workspace configuration for that specific cluster, so the per-cluster setting customizes only that cluster while the rest inherit the workspace config. You should not fork the app, run a second Kommander, or hand-edit the cluster. The NKP CLI can also enable, disable, and configure applications in addition to the UI editors.
The trap'Fork the app' (A) and 'manual edits' (D) are the anti-GitOps shortcuts the design exists to prevent. 'A second Kommander' (B-as-listed option index 2) over-engineers a problem solved by scope layering.
Phrasing noteThe keyed answer is correct, but tighten the phrasing: the docs describe workspace configOverrides with per-cluster clusterConfigOverrides layered on top for exceptions; they do not state a literal 'narrower scope wins' precedence rule, so present it as 'cluster-scoped override customizes that specific cluster' rather than quoting a precedence law. The CLI enable/disable/configure claim is accurate as a general capability.
Plain-English terms in this questionNKP: Nutanix Kubernetes Platform: Nutanix's enterprise Kubernetes product. It is pure upstream Kubernetes pre-bundled with about 22 CNCF projects (networking, storage, security, logging, monitoring) so you do not assemble them yourself. Formerly D2iQ DKP; it replaces the older NKE/Karbon.
Kommander: NKP's central management layer and web UI. It manages many clusters at once (the fleet), deploys platform apps, and federates permissions. It runs on the management cluster.
Workspace: In Kommander, the top-level isolation boundary that groups clusters, apps, and permissions for one team or tenant.
GitOps: Managing apps and infrastructure by storing the desired state in a Git repository and having a controller automatically apply changes.