NCP-CN Practice Questions

Upgrading a Nutanix Kubernetes Platform (NKP) license is a privileged administrative action. According to the official Nutanix documentation, only a user assigned the Global License Administrator role has the necessary permissions to add and activate a new license key. If the current user session does not have this role, the user must log out and log back in with an account that possesses these specific privileges to access the license management features in the NKP web console and apply the higher-tier license.

A. Contact Nutanix Support: This is not required for a standard license activation, which is a self-service administrative task.

B. Ensure that worker nodes are sized appropriately: While new features may require more resources, node sizing is a separate infrastructure management task, not a prerequisite for activating the license itself.

D. Regenerate the ACME-based certificate for NKP: Certificate management is related to securing communication and identity, not to feature entitlement through licensing.

Nutanix Kubernetes Platform Administration Guide

"Licensing for Nutanix Kubernetes Platform" section. The documentation states

"To add and activate a license

you must be a Global License Administrator." This confirms the requirement for a specific user role to perform the action. (URL: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Kubernetes-Platform-Admin-Guide:Nutanix-Kubernetes-Platform-Admin-Guide/nke-administration-licensing-c.html)

To attach an existing Azure Kubernetes Service (AKS) cluster to Nutanix Kubernetes Platform (NKP) for fleet management, a new service account must be created on the AKS cluster. The default kubeconfig file generated by the Azure CLI (az aks get-credentials) uses an Azure-specific authentication provider that requires interactive login or an existing Azure session. NKP's Kommander component, which runs as a service, cannot use this mechanism. Instead, it requires a self-contained, non-interactive authentication method, which is achieved by creating a service account and using its long-lived authentication token to build a new, compatible kubeconfig file for the attachment process.

B: This is incorrect. The kubelet is a fundamental component of every Kubernetes node, including those in an AKS cluster. KIB-prep is a process for air-gapped NKP installations, not for attaching existing clusters.

C: This is incorrect. Modern AKS clusters use containerd as the container runtime. Furthermore, NKP Kommander interacts with the Kubernetes API server, not directly with the node's container runtime for management.

D: This is incorrect. Cert-manager is a core component of NKP's management plane, but it is not deployed by default on a standard AKS cluster, so there is no inherent conflict to consider.

1. Nutanix Kubernetes Platform Administration Guide: In the section on fleet management

the guide specifies the procedure for attaching existing clusters from cloud providers. It states

"For managed Kubernetes clusters from cloud providers (for example

EKS

AKS

or GKE)

you must create a service account on the cluster and then create a kubeconfig file that NKP can use to access the cluster."

Source: Nutanix Portal (Requires login) -> Documentation -> Nutanix Kubernetes Platform -> Administration Guide. The principle is detailed in the "Attaching an Existing Cluster to NKP" section.

2. D2iQ Kommander Documentation (Foundation for NKP): The process is explicitly detailed

requiring the creation of a ServiceAccount and ClusterRoleBinding on the target AKS cluster to generate a token-based kubeconfig for Kommander.

Source: D2iQ Kommander Documentation

"Attach an AKS Cluster". URL: https://docs.d2iq.com/dkp/kommander/latest/operations/attach-aks/ (Note: NKP is based on D2iQ DKP technology

making this a primary source for technical procedures).

Enabling Federal Information Processing Standards (FIPS) compliance for Nutanix Kubernetes Platform (NKP) is a multi-layered process that begins at the operating system level. Before any NKP components can be installed or configured for FIPS mode, the underlying OS on the nodes must be hardened and prepared according to the specific OS vendor's FIPS guidelines. This foundational step ensures that the core cryptographic modules used by the system are FIPS 140-2 validated, which is a mandatory prerequisite for the entire platform to operate in a compliant manner.

A. Run the command export FIPSENABLED=true: This is a subsequent step used to inform the NKP installer that the environment is FIPS-prepared, but it is not the first action.

B. Run the command nkp cluster create --fips: This command initiates the cluster creation process. It is performed after the environment, including the OS, has been fully prepared for FIPS.

D. Click Enable in the NKP Kommander Web UI, Global Workspace -> Settings -> FIPS menu: This UI action is for managing FIPS on an existing Kommander management cluster, not the initial, foundational step of preparing the OS environment.

1. Nutanix Kubernetes Platform Security Guide v2.7

FIPS Compliance: "To run NKP in a FIPS-compliant manner

you must first prepare your environment. Follow your OS vendor’s instructions to ensure that the OS or OS images are prepared for operating in FIPS mode." This is explicitly stated as the first prerequisite. (URL: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Kubernetes-Platform-Security-Guide-v27:Nutanix-Kubernetes-Platform-Security-Guide-v27)

2. NIST

Security Requirements for Cryptographic Modules

FIPS PUB 140-2

Section 4.2 Roles

Services

and Authentication: This standard outlines that the operational environment is a key part of the cryptographic module's boundary. Preparing the OS is the first step in defining this compliant environment. (URL: https://csrc.nist.gov/publications/detail/fips/140/2/final)

To customize a platform add-on like the logging operator in Nutanix Kubernetes Platform (NKP), you must create a ConfigMap with a specific name (-overrides) in the kommander namespace. The question requires increasing Fluentd's CPU and memory limits. Option B presents a syntactically correct YAML definition for a ConfigMap named logging-operator-logging-overrides. The data key values.yaml contains a properly structured YAML block that sets the fluentd.resources.limits and fluentd.resources.requests to the desired values of 4 CPU and 4Gi memory, which directly addresses the performance issue described.

A: The YAML syntax is invalid (e.g., apiVersion v1, metadataname), and the embedded values under data are malformed and do not follow the required hierarchical structure.

C: This option contains invalid YAML syntax and a malformed, duplicated values.yaml block, making it non-functional. The resource values are also incorrectly assigned.

D: While the outer ConfigMap structure is mostly correct, the embedded values.yaml data is not valid YAML. It is a single line of text without the necessary indentation and structure.

1. Nutanix Kubernetes Platform Administration Guide - Customizing a Platform Add-on: This official guide details the procedure for customizing platform add-ons. It specifies creating a ConfigMap named -overrides in the kommander namespace and providing custom settings in the data.values.yaml key. The structure used in option B aligns with this documented method.

URL: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Kubernetes-Platform-Admin-Guide-v28:ecm-customize-addon-t.html

2. Kubernetes Documentation - Resource Management for Pods and Containers: This official Kubernetes documentation explains the syntax for specifying resource requests and limits within a Pod specification. The resources.limits.cpu

resources.limits.memory

etc.

structure shown in Option B is the standard Kubernetes convention.

URL: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ (Section: "Resource requests and limits of a container")

According to the official Nutanix Karbon Platform (NKP) documentation, when deploying Kubernetes clusters using the Nutanix provisioning method (CAPX), the supported guest operating systems for worker nodes are specific versions of Rocky Linux and Ubuntu. The documentation explicitly lists Rocky Linux 8.7 and Ubuntu 22.04 as the validated and supported platforms. This ensures that the underlying nodes are fully compatible with the Cluster API Provider for Nutanix (CAPX) for automated lifecycle management, scaling, and operations within the Nutanix Cloud Platform.

A: CentOS is not an officially supported guest OS for NKP worker nodes; support has transitioned to Rocky Linux.

C: Flatcar is not listed as a supported guest OS for worker nodes in the official NKP documentation.

D: CentOS is not a supported OS for NKP worker nodes, making this option incorrect as it is no longer the standard.

1. Nutanix Karbon Platform Administration Guide v4.1

Section: Prerequisites for NKP Deployment

Subsection: Supported Guest OS for Worker Nodes. The guide states

"NKP supports the following guest OS for worker nodes: Ubuntu 22.04

Rocky Linux 8.7".

URL: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Karbon-Platform-Admin-Guide-v41:Nutanix-Karbon-Platform-Admin-Guide-v41

The primary purpose of using Nutanix Image Builder (NIB) or Karbon Image Builder (KIB) is to prepare a base OS image with all the necessary software components required by the Cluster API (CAPI) framework. Nutanix Kubernetes Platform (NKP) leverages CAPI for the lifecycle management of Kubernetes clusters. The image building process installs specific versions of kubeadm, kubelet, and containerd onto the image. This makes the resulting image "CAPI-compliant," enabling NKP to successfully bootstrap and manage the virtual machines as Kubernetes nodes.

A: While hardening scripts can be included, the fundamental purpose is installing Kubernetes components for CAPI compatibility, not general OS hardening.

B: Creating a user account is a minor configuration detail within the image creation process, not its primary objective.

C: Tagging is a management action performed in Prism Central to identify the image, not the technical purpose of the image building process itself.

1. Nutanix Kubernetes Platform Administration Guide v4.2 - Image Management: This guide explicitly states

"Nutanix Kubernetes Platform uses the Cluster API (CAPI) framework to create and manage Kubernetes clusters. CAPI requires a pre-built OS image that contains the necessary Kubernetes components

such as kubeadm

kubelet

and a container runtime (containerd)." It then introduces NIB as the tool for this purpose.

URL: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Kubernetes-Platform-Admin-Guide-v42:ecm-image-management-c.html

2. Cluster API - The Machine resource: The official Cluster API documentation outlines the dependency on pre-configured images for bootstrapping nodes

which aligns with the function of NIB/KIB.

URL: https://cluster-api.sigs.k8s.io/user/concepts.html#machine (See sections on bootstrapping).

Nutanix Kubernetes Platform (NKP) uses a GitOps model, powered by Flux, to manage attached clusters. When a cluster is detached using the nkp detach command, NKP removes it from its central management plane. However, this process intentionally does not uninstall the Flux components or disable the GitOps configuration on the detached cluster itself. This ensures that running applications are not disrupted. As a result, the Flux controller on the EKS cluster remains active and continues to synchronize with the management Git repository, applying any new changes. To stop this behavior, the administrator must manually suspend the Flux GitRepository resource on the detached cluster, which halts the synchronization process.

A: The cluster was already successfully detached. Re-running the command, even with --force, is redundant and does not address the residual, active Flux synchronization on the cluster.

B: The nkp delete cluster command is used to destroy clusters provisioned by NKP. It is not the correct command for an attached EKS cluster or for managing post-detachment configurations.

C: The issue is not with application configuration files but with the platform-level GitOps mechanism (Flux) that is still actively applying those configurations from the repository to the cluster.

1. D2iQ Kommander Documentation (Foundation for NKP): The process of detaching a cluster is described in the D2iQ Kommander documentation

which NKP is built upon. It explicitly states that the GitOps configuration remains on the cluster after detachment. "When you detach a cluster... The GitOps configuration that synchronizes your cluster with your Git repository remains on the cluster." This confirms the scenario's premise.

Source: D2iQ Kommander Documentation

"Detach a Managed or Attached Cluster". (Specific URL varies by version

but the principle is consistent).

2. FluxCD Documentation (Core Technology): The command in the correct answer aligns with the official FluxCD documentation for managing resources. Suspending a GitRepository is the standard method to stop reconciliation.

Source: FluxCD Documentation

"Manage Resources > Suspend and resume resources".

URL: https://fluxcd.io/flux/components/source/gitrepositories/#suspending-and-resuming

3. Nutanix Kubernetes Platform Administration Guide: The guide describes the detach command's function as removing the cluster from management

noting that applications continue to run

which implies underlying configurations like Flux are left intact to prevent service disruption.

Source: Nutanix Kubernetes Platform 2.x Administration Guide

"Detaching a Cluster from Management".

Nutanix Kubernetes Platform (NKP) provides an integrated add-on for Velero, an open-source tool designed specifically for backing up and restoring Kubernetes cluster resources and persistent volumes. This out-of-the-box integration allows platform engineers to manage the lifecycle of Kubernetes applications, including disaster recovery, by leveraging a Kubernetes-native solution. Velero captures the state of cluster resources and can back them up to an object store, making it the distributed backup solution for NKP.

A. Tar: This is a generic command-line archiving utility. It is not a Kubernetes-aware solution and is not the distributed backup tool for NKP.

B. Kasten: Kasten K10 is a third-party Kubernetes backup product from Veeam. While it can be used with NKP, it is not the out-of-the-box solution distributed with the platform.

D. Nutanix Snapshot: This is a storage-level feature of the Nutanix AOS platform for protecting VMs. It is not a Kubernetes-native tool for application-aware backup and recovery.

Nutanix Kubernetes Platform 4.1 Documentation

"Data Protection with Velero". This section explicitly states

"Nutanix Kubernetes Platform (NKP) provides an add-on for Velero

an open-source tool for backing up and restoring your Kubernetes cluster resources and persistent volumes." [URL: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Kubernetes-Platform-v41:ecm-kps-dr-velero-c.html]

Velero Official Documentation

"What is Velero?". This describes Velero as a tool to "back up and restore your Kubernetes cluster resources and persistent volumes." [URL: https://velero.io/docs/main/what-is-velero/]

In an air-gapped Nutanix Kubernetes Platform (NKP) deployment, the Konvoy bootstrap image must be made available to the local Docker daemon on the bastion host before initiating the bootstrap cluster creation. The docker load command is the standard and officially documented method for this task. It directly loads an image from a tar archive (.tar file) into the local image cache on the bastion host. This makes the image accessible for the konvoy up command, which creates the temporary bootstrap cluster.

B. docker image tag konvoy-bootstrap-image-.tar version docker.io/konvoy-bootstrap version: This command is syntactically incorrect. docker image tag is used to apply a new tag to an existing local image, not to load an image from a file archive.

C. nkp push bundle --bundle konvoy-bootstrap-image-.tar --to-registry=: This command is for pushing a complete NKP bundle (a collection of many images and addons) to a private registry, a step that the scenario states has already been completed.

D. nkp load image -f konvoy-bootstrap-image-.tar --to-registry=: While this command loads an image, its primary purpose is to immediately push it to a registry. The specific task is to make the image available on the bastion host for bootstrapping, for which docker load is the more direct and prescribed command.

1. Nutanix Kubernetes Platform 2.5 Documentation

Deploying NKP in an Air-Gapped Environment

Section: Preparing the Bastion Host. The documentation explicitly provides the command for this step: docker load -i konvoy-image-bundle-v.tar.

URL: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Kubernetes-Platform-v25:ecm-air-gapped-deployment-bastion-host-prep-t.html

2. Docker Official Documentation

docker load. This documentation confirms that docker load restores images and tags from a tar archive.

URL: https://docs.docker.com/engine/reference/commandline/load/

The scenario requires a solution that supports both the centralized management of multiple Kubernetes clusters and deployment in an air-gapped environment. According to the Nutanix Kubernetes Platform (NKP) licensing model, the NKP Ultimate tier is specifically designed for these advanced requirements. It includes all the features of the Pro tier, such as multi-cluster management, and adds critical capabilities for operating in disconnected, high-security environments, which is essential for a national defense company.

A. NKP Starter: This tier is limited to managing a single Kubernetes cluster and does not support the advanced security features required for an air-gapped deployment.

C. NKP Pro: While this tier enables multi-cluster management across various clouds, it lacks the specific features and support required for deployment in an air-gapped environment.

D. NKP UI: This is not a valid licensing tier. NKP UI refers to the Nutanix Kubernetes Platform User Interface, which is a component of the platform, not a license level.

1. Nutanix Kubernetes Platform (NKP) Software Options: The official Nutanix documentation outlines the features available in each licensing tier. The Ultimate tier is explicitly stated to include "advanced features for air-gapped environments."

URL: https://www.nutanix.com/products/kubernetes-platform/software-options (Accessed under "Compare Software Options" section).

2. Nutanix Kubernetes Platform Solution Brief: This document details the platform's capabilities

differentiating the tiers. It highlights that NKP Ultimate is for customers with the most stringent security and data protection needs

including air-gapped operations.

URL: https://www.nutanix.com/content/dam/nutanix/resources/solution-briefs/sb-nutanix-kubernetes-platform.pdf (Page 4

"Nutanix Kubernetes Platform Software Options").