Nutanix NCP-CN Nutanix Certified Professional - Cloud Native (NCP-CN-6.10) Exam Practice Test

The Nutanix Kubernetes Platform (NKP) integrates Velero, an open-source tool, for backup and restore operations as part of its Day 2 operations. The NKPA course explains that after configuring a Backup Storage Location (e.g., an AWS S3 bucket) and creating a backup, administrators can view details of the backup using the Velero CLI. The correct command to view the details of a backup named testbackup is velero backup describe testbackup. This command provides a detailed description of the backup, including its status, resources included, and storage location.

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “To inspect a Velero backup in NKP, use the velero backup describe command to display detailed information about the backup, such as its creation time, expiration, and included resources.” The backup name (testbackup) is specified as created by the team, and no prefix like aws-velero- is indicated in the question, making option C the correct choice.

Incorrect Options:

A. kubectl get backupstoragelocations -n ${testbackup} -o yaml: This command retrieves Backup Storage Location objects, not backup details. The namespace ${testbackup} is also incorrect, as Velero resources are typically in a specific namespace (e.g., velero).

B. velero backup describe aws-velero-testbackup: The backup name is testbackup, not aws-velero-testbackup. The NKPA course does not indicate any prefix for the backup name.

D. kubectl get backupstoragelocations -n ${WORKSPACE_NAMESPACE} -o yaml: This retrieves Backup Storage Locations, not the backup itself, and does not provide backup details.

In an air-gapped NKP installation, the engineer starts with the NKP Air-Gapped Bundle, a tarball containing all necessary components (e.g., container images, binaries, configuration files) for deployment without Internet access. The NKPA course specifies that the first step is to extract this bundle on the bastion host to make its contents available for the installation process. The correct command is tar -xzvf nkp-air-gapped-bundle_v2.12.0_linux_amd64.tar.gz, which extracts the bundle into a directory, revealing the container images, CLI tools, and other resources needed for the deployment.

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “To begin an air-gapped NKP installation, first extract the NKP Air-Gapped Bundle using tar -xzvf .tar.gz on the bastion host to access the installation artifacts.” After extraction, the engineer can proceed with loading container images (e.g., using docker load) and running NKP CLI commands to deploy the cluster, ensuring all dependencies are available locally.

Incorrect Options:

A. nkp push bundle --bundle: This is not a valid command. The bundle must be extracted before its contents can be used.

B. docker load -i konvoy-bootstrap-image-v2.12.0.tar: Loading the bootstrap image is a subsequent step after extracting the bundle, which contains this image tarball.

D. nkp create cluster nutanix: This command creates a cluster but cannot be run until the bundle is extracted and its images are loaded.

The error states:

lua

Copy

Could not find or access '/home/.../nkp-image-builder-.../playbooks/.../artifacts/1.29.6_ubuntu_22.04_x86_64.tar.gz'

This indicates that the OS package bundle (artifacts/1.29.6_ubuntu_22.04_x86_64.tar.gz) has not been created or is missing. Creating the OS package bundle is a prerequisite step in the NIB workflow.

Key Reference:

Nutanix Kubernetes Platform Administration (NKPA) 6.10 – “Creating OS Package Bundles for NIB”

NCP-CN 6.10 Study Guide – “NIB Preparation Prerequisites”

=======

The NKPA 6.10 documentation confirms that workspaces in NKP are used to logically group and standardize configurations across multiple clusters. By creating a production workspace and a development workspace, the organization can control and enforce standardized configurations and policies for all relevant clusters.

Exact extract:

“Workspaces provide logical separation for resources, configuration, and policy management across multiple clusters, enabling standardized operations.”

Attaching an existing Amazon EKS cluster to NKP for fleet management involves integrating the cluster into NKP’s management plane, which requires specific preparatory steps. The NKPA course outlines that the first step is to create a service account with cluster-admin permissions in the EKS cluster. This service account is used by NKP to authenticate and manage the cluster, enabling operations like monitoring, scaling, and application deployment.

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide explains: “To attach an external Kubernetes cluster, such as Amazon EKS, to NKP, a service account with cluster-admin role bindings must be created to allow NKP to interact with the cluster’s API server.” The service account is configured with a token that NKP uses to authenticate requests. The NKPA course provides detailed steps, including creating the service account, assigning the cluster-admin ClusterRole, and generating a token for NKP integration. This step is critical to ensure NKP has the necessary permissions to manage the EKS cluster.

Incorrect Options:

A. Configure a ConfigMap according to EKS configuration: While ConfigMaps may be used for specific configurations, they are not the first step for attaching an EKS cluster. The NKPA course prioritizes service account creation.

C. Configure HAProxy to get connected to EKS clusters: HAProxy is a load balancer, not required for attaching EKS clusters to NKP. EKS uses AWS-native load balancers, and NKP connects via the Kubernetes API.

D. Deploy cert-manager in the EKS clusters: Cert-manager is used for certificate management, not a prerequisite for attaching EKS clusters. The NKPA course does not list it as a required step.

The exhibit shows the NKP UI with the "Create Cluster" option grayed out in a new workspace, indicating that a prerequisite for cluster creation is missing. The NKPA course explains that to create a new Kubernetes cluster in a workspace, an Infrastructure Provider must be configured for that workspace. An Infrastructure Provider defines the underlying infrastructure (e.g., Nutanix AHV, AWS, vSphere) where the cluster will be provisioned, and without it, the Create Cluster option remains disabled in the UI.

The NKP Ultimate license supports creating clusters across various infrastructures, but the workspace must be associated with an Infrastructure Provider to enable cluster creation. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “Before creating a cluster in a new workspace, ensure an Infrastructure Provider is configured for the workspace in the NKP UI; otherwise, the Create Cluster option will be grayed out.” The engineer should navigate to the Infrastructure Providers section in the NKP UI (typically under the Global or Administration view), create a provider (e.g., for Nutanix AHV, AWS, or vSphere), and associate it with the workspace. Once this is done, the Create Cluster option will become available.

Incorrect Options:

A. Create the cluster only using YAML and not the GUI: The issue is not with the GUI itself but with the missing Infrastructure Provider, which affects both GUI and CLI cluster creation. YAML alone does not resolve this.

B. Attach existing clusters instead of creating a new cluster: Attaching existing clusters is an alternative but does not address the requirement to create a new cluster.

D. Ensure NKP is upgraded to a minimum version of 2.12: The NKP Ultimate license implies a recent version, and the course does not indicate that version 2.12 is specifically required for this functionality. The issue is configuration-related, not version-related.

The NKPA course addresses resource contention in Kubernetes clusters, where one application (e.g., ApplicationB) consumes excessive resources, impacting others (e.g., ApplicationA). To mitigate this, the course recommends implementing Quotas and Limit Ranges.

Resource Quotas restrict the total amount of CPU, memory, and other resources a namespace can consume, ensuring fair resource allocation across teams.

Limit Ranges set minimum and maximum resource limits for individual pods and containers within a namespace, preventing any single application from monopolizing resources.

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “To prevent resource contention in NKP clusters, apply Resource Quotas to limit namespace resource usage and Limit Ranges to enforce pod and container resource boundaries.” For example, the administrator can create a ResourceQuota to cap ApplicationB’s namespace resource usage and a LimitRange to restrict its pod resource requests/limits, ensuring ApplicationA has sufficient resources.

Incorrect Options:

B. Setting up Network Policies: Network Policies control network traffic, not resource usage.

C. Configuring RBAC: RBAC manages access permissions, not resource allocation.

D. Implementing Continuous Deployment (CD): CD automates deployments but does not address resource contention.

The primary benefit of a private registry is to ensure security and privacy for container images, especially when dealing with sensitive data and compliance requirements (such as financial or government use cases). While secure connections to public registries like DockerHub or GitHub container registries are possible, using a private registry ensures full control over image access and auditing.

Key reference:

“Private registries ensure images remain within the security and compliance boundaries of the enterprise, avoiding potential risks associated with public SaaS registries.”

The NKPA course outlines the default behaviors of NKP when deploying workload clusters within a workspace, regardless of the provisioning environment (e.g., AWS, Nutanix, Azure). When a workload cluster is deployed in AWS, NKP ensures consistency across the workspace by applying the following default behaviors:

The NKP workload cluster will receive all of the GitOps sources that have been assigned to the NKP workspace (Option A): NKP uses GitOps with Flux to manage cluster configurations and applications. The course explains that GitOps sources (e.g., Git repositories) assigned to a workspace are automatically applied to all clusters in that workspace, ensuring consistent configuration and application deployment. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “New workload clusters inherit all GitOps sources configured for the workspace, enabling Flux to synchronize configurations from the specified repositories.”

The NKP workload cluster will be deployed all of the applications that have been enabled on this NKP workspace (Option D): NKP Platform Applications (e.g., Prometheus, Rook Ceph) enabled in the workspace are automatically deployed to new workload clusters. The NKPA course notes: “When a workload cluster is created, NKP deploys all platform applications enabled in the workspace to ensure consistent functionality across clusters.”

Incorrect Options:

B. The NKP workload cluster will receive all of the NKP RBAC policy: RBAC policies are defined at the workspace or project level and applied to users or groups, not automatically to clusters. Clusters inherit RBAC through user access, not as a default deployment behavior.

C. The NKP workload cluster will also be assigned to all of the NKP projects: Clusters are assigned to specific projects manually, not automatically to all projects in a workspace.

As per the “Nutanix Kubernetes Platform Administration (NKPA)” documentation, during the preparation of the environment for an air-gapped deployment, the first task involves installing critical software packages on the bastion host. The bastion host acts as a jump host in a secure network and requires tools such as yum-utils, bzip2, and wget to facilitate the retrieval and processing of required images and configuration files.

Specifically, in the NKPA 6.10 course under "Preparing the Air-gapped Environment", the documentation clearly states:

"The initial step for configuring the bastion host includes installing required pre-requisites like yum-utils, bzip2, and wget. This ensures that the host has the basic tools to download and manage required container images and other dependencies."

This step is explicitly called out as the first actionable item before proceeding to more advanced tasks like configuring public IP access or creating a bootstrap cluster. The need for these pre-requisite packages is foundational, as they are required to handle image downloading and manipulation in the subsequent steps of the air-gapped installation process.

The NKPA course details NKP’s monitoring stack for collecting and analyzing metrics across attached and managed clusters, which is critical for troubleshooting issues like out-of-memory errors. The engineer needs to collect centralized metrics and set up alerting to identify performance issues. The correct approach is to use Prometheus for metrics collection and Thanos Query for alerting (Option C).

Utilize Prometheus to collect and present centralized metrics on NKP attached and managed clusters: Prometheus is NKP’s default metrics collection tool, deployed as a platform application. It scrapes metrics (e.g., CPU, memory usage) from nodes, pods, and services across all clusters in a workspace, centralizing them for analysis. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “Prometheus is used in NKP to collect and present centralized metrics from attached and managed clusters, enabling detailed performance analysis.” This is ideal for identifying differences in memory usage causing the out-of-memory errors.

Configure Thanos Query to monitor and send out alerts based on the metric thresholds that have been configured within it: Thanos Query, part of NKP’s monitoring stack, aggregates Prometheus metrics across clusters and provides a unified query interface. It also integrates with Alertmanager to send alerts based on configured thresholds (e.g., memory usage > 90%). The NKPA course notes: “Use Thanos Query to monitor metrics across NKP clusters and configure alerts with Alertmanager to notify engineers of performance issues like out-of-memory errors.” This setup helps the engineer proactively address the issue.

Incorrect Options:

A & B. Utilize Fluentd and Fluent Bit: Fluentd and Fluent Bit are logging tools in NKP, used for collecting logs, not metrics. Metrics collection requires Prometheus.

D. Utilize Thanos to collect and present centralized metrics: Thanos does not collect metrics directly; it extends Prometheus by providing long-term storage and query aggregation. Prometheus is the primary collection tool.

When mirroring the NKP bundle to a private registry, the recommended method is to use the nkp bundle push or similar commands with the --to-registry option, specifying the target registry along with the credentials (--to-registry-username and --to-registry-password).

Key reference from documentation:

“Use the --to-registry flag along with --to-registry-username and --to-registry-password to push the NKP bundle to a private registry.”

According to the NKPA 6.10 documentation, the FIPS Compliant Build feature is exclusively available for Enterprise tier licensing. This ensures compliance with NIST security standards and provides hardened cryptographic capabilities throughout the Kubernetes cluster stack.

Exact extract from documentation:

“The FIPS-compliant build feature is included in the NKP Enterprise tier, enabling deployments in environments that require strict security compliance.”

According to the NKPA 6.10 documentation, Rook Ceph is the recommended out-of-the-box storage solution integrated with NKP for persistent data storage, backups, and object storage within the Kubernetes environment.

Key Reference:

“Rook Ceph is integrated with NKP for providing persistent storage and backup support within the cluster.”

NKP uses Cluster API (CAPI) to provision and manage Kubernetes clusters across supported infrastructures, including Nutanix AHV, vSphere, AWS, and GCP. CAPI components, such as controllers and providers, are deployed to manage the lifecycle of clusters on these platforms. However, when NKP attaches to a managed Kubernetes service like Azure Kubernetes Service (AKS), CAPI components are not deployed because AKS is managed by Azure, and NKP only integrates with the cluster for fleet management, not provisioning.

The NKPA course explains: “For managed Kubernetes services like AKS, NKP attaches the cluster to its management plane without deploying CAPI components, as the underlying infrastructure is managed by the cloud provider.” The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide reinforces this: “CAPI is used for NKP-managed clusters on Nutanix, vSphere, AWS, and GCP, but not for attached managed services like AKS.”

Incorrect Options:

A. vSphere: NKP deploys CAPI components (e.g., CAPV provider) to manage vSphere-based clusters.

B. GCP: NKP deploys CAPI components (e.g., CAPG provider) for GCP-based clusters.

C. Nutanix: NKP deploys CAPI components (e.g., CAPA provider for AHV) for Nutanix AHV clusters.

The exhibit shows the NKP UI with a list of clusters, including "arca," "demo," and "production," each with a three-dot menu on the right side. The NKPA course explains that to delete a cluster directly from the NKP UI, the engineer should use the Delete option available in the cluster’s three-dot menu. This action initiates the deletion process, removing the cluster from NKP management and freeing up any associated licenses (e.g., CPU core-based licenses, as per NKP licensing).

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “To delete a cluster in NKP via the UI, navigate to the cluster list, click the three-dot menu for the target cluster (e.g., demo), and select ‘Delete’ to remove the cluster and its resources.” The UI in the exhibit aligns with this process, showing the three-dot menu next to the "demo" cluster, which includes the Delete option. This is the most straightforward method to delete the demo cluster and reallocate resources to the arca cluster.

Incorrect Options:

A. Download kubeconfig and use kubectl delete cluster: kubectl delete cluster is not a valid command for deleting NKP clusters. NKP uses the nkp CLI or UI for cluster deletion.

C. Select Detach and ask the cluster owner to delete: Detach is for external clusters (e.g., EKS), not NKP-managed clusters like "demo," which is on Nutanix infrastructure. Detaching does not delete the cluster.

D. SSH to kommander cluster and execute kubectl delete cluster: Kommander is a management component, but kubectl delete cluster is not a valid command for NKP cluster deletion.

The NKPA course recommends using a S3-compatible API for backup and restore operations in production NKP environments, as it integrates with Velero, NKP’s backup and restore tool. Velero supports S3-compatible storage (e.g., AWS S3, Nutanix Objects, or MinIO) as a backup storage location, allowing persistent data, including volumes and cluster resources, to be backed up and restored during disaster recovery scenarios. This approach ensures compatibility with cloud-native backup workflows and provides scalability and reliability for production use cases.

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “For production backup and restore in NKP, use Velero with an S3-compatible API to store backups, ensuring persistent data availability during disaster recovery.” Nutanix Objects, which provides an S3-compatible API, is often used in Nutanix environments for this purpose, but any S3-compatible storage (e.g., an off-site S3 bucket) can be configured.

Incorrect Options:

A. Protection Domain: Protection Domains are a Nutanix AOS feature for VM-level replication, not for Kubernetes backup/restore.

B. Rook Ceph: Rook Ceph provides persistent storage for NKP clusters but is not a backup solution; it can be backed up using Velero with S3 storage.

C. External Storage Class: Storage Classes define how volumes are provisioned, not how they are backed up or restored.

The Nutanix Kubernetes Platform (NKP) uses workspaces to provide isolated environments for different teams or projects, allowing each team to manage its own clusters, applications, and resources independently. According to the NKPA course, creating a new workspace is a key Day 2 operation to support multi-tenancy and isolated development environments, such as those required for the microservices in this scenario.

The course specifies that to create a new workspace, users must navigate to the workspace selection dropdown list in the top menu bar of the NKP user interface (UI) and select Create Workspace. This action opens a form where administrators can define the workspace name, description, and associated resources (e.g., clusters, users, and policies). The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “To create a new workspace in NKP, go to the workspace selection dropdown in the UI and select ‘Create Workspace’ to configure an isolated environment for a team or project.” This process ensures that each microservice team has its own isolated environment for development and testing, with access restricted to their specific workspace.

Incorrect Options:

A. From the Cluster selection, select Add Cluster: Adding a cluster creates a new Kubernetes cluster within an existing workspace, not a new workspace. The NKPA course distinguishes between cluster and workspace creation.

C. From the workspace selection dropdown list in the top menu bar, select Add Workspace: The NKPA course and UI use “Create Workspace” as the standard terminology, not “Add Workspace.”

D. From the Administration selection dropdown list in Infrastructure Providers, select Add Infrastructure Provider: This option is for configuring infrastructure providers (e.g., AWS, vSphere) for NKP, not for creating workspaces.

A bastion host in a dark site environment serves as a secure entry point for managing the NKP deployment, providing access to the cluster infrastructure without direct Internet connectivity. The NKPA course outlines the prerequisites for preparing a Linux VM as a bastion host, focusing on secure access and time synchronization, which are critical for air-gapped Kubernetes deployments.

Get or create SSH Keys (Option B):The bastion host requires SSH keys to enable secure, passwordless access to the NKP cluster nodes and other infrastructure components (e.g., Nutanix AHV hosts). The NKPA course specifies that SSH keys must be generated or obtained and configured on the bastion host to facilitate secure communication during deployment and management tasks. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “For a bastion host in an NKP dark site deployment, ensure SSH keys are created or obtained to enable secure access to cluster nodes and infrastructure.” The engineer can generate SSH keys using ssh-keygen and distribute the public key to the target systems.

Enable NTP Service (Option D):Time synchronization is essential in Kubernetes clusters to ensure consistent logging, certificate management, and scheduling. In a dark site with no Internet access, the bastion host must be configured to synchronize time with an internal NTP (Network Time Protocol) server or act as an NTP server itself. The NKPA course emphasizes enabling the NTP service on the bastion host to maintain accurate time across the air-gapped environment. The NCP-CN 6.10 Study Guide notes: “Enable the NTP service on the bastion host to ensure time synchronization in a dark site NKP deployment, as Kubernetes requires accurate time for proper operation.” The engineer can enable NTP using commands like systemctl enable ntpd and configure it to use an internal time source.

Incorrect Options:

A. Install LDAP Server: LDAP is used for centralized authentication, but it is not a requirement for a bastion host in an NKP dark site deployment. The course focuses on SSH access instead.

C. Install Docker: While Docker is needed on Kubernetes nodes for container runtimes, the bastion host’s role is to provide secure access and management, not to run containers.

Comprehensive and Detailed Explanation From Exact Extract of Nutanix Kubernetes Platform Administration (NKPA) Course:

The NKPA course outlines the process of adding GPU-enabled worker nodes to an existing NKP-managed Kubernetes cluster, such as the production cluster in this scenario. The first step in this process is to ensure that a GPU-compatible OS image is available for the new worker nodes, as GPU support requires specific drivers and configurations (e.g., NVIDIA drivers) that are not included in standard OS images.

The correct first step is to create a GPU-compatible OS image using the command:

text

CollapseWrap

Copy

nkp create image nutanix --gpu \

--gpu-name=${GPU_NAME} \

--cluster=${NUTANIX_CLUSTER_NAME} \

--endpoint=${NUTANIX_PC_ENDPOINT} \

--subnet=${NUTANIX_SUBNET} ubuntu-22.04

(Option D). This command uses the NKP CLI to create a machine image based on Ubuntu 22.04, tailored for Nutanix AHV infrastructure (nutanix) with GPU support enabled (--gpu). The --gpu-name flag specifies the GPU type (e.g., NVIDIA GPU model), and other parameters define the Nutanix cluster, Prism Central endpoint, and subnet for image creation. The resulting image includes the necessary NVIDIA drivers and dependencies, making it suitable for GPU-enabled worker nodes. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “Before adding GPU-enabled workers to an NKP cluster on Nutanix, the first step is to create a GPU-compatible OS image using nkp create image nutanix --gpu, ensuring the image includes the required GPU drivers for the target infrastructure.”

This image is then used in subsequent steps (like Option A) to create a node pool with GPU-enabled workers. Without this image, the node pool creation in Option A would fail due to the lack of a suitable --vm-image.

Incorrect Options:

A. Create a nodepool of workers with GPU: This step requires a pre-existing GPU-compatible OS image (specified via --vm-image). Since the question does not indicate that such an image already exists, creating the image (Option D) must happen first.

B. Add the GPU Operator to the new workers: The NVIDIA GPU Operator can be installed to manage GPU resources, but this step occurs after the GPU-enabled workers are added to the cluster, not as the first step.

C. Configure Multi-Instance GPU (MIG): MIG configuration is an advanced GPU setup step that occurs after the workers are added and the GPU Operator is installed, not as the first step.

The NKPA course details the default node preparation process for NKP cluster nodes, which involves creating a machine image that is compliant with Cluster API (CAPI) standards. The primary tool used in this process is Packer, which automates the creation of machine images by provisioning a base OS image (e.g., Ubuntu or Rocky Linux) with the necessary components for Kubernetes, such as kubeadm, containerd, and other dependencies.

Packer ensures the image is CAPI-compliant by installing the required Kubernetes binaries, configuring the container runtime, and setting up networking and storage components. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “In the default node preparation process for NKP, Packer is used to build a CAPI-compliant OS image, installing Kubernetes components and dependencies for use as an NKP node.” This process is typically orchestrated by NKP Image Builder (NIB) or Kubernetes Image Builder (KIB), both of which rely on Packer for image creation.

Incorrect Options:

B. Ansible is used to make the OS image CAPI-compliant: Ansible is used by KIB/NIB to apply configurations during the Packer build process, but Packer is the primary tool for creating the image. Ansible alone does not make the image CAPI-compliant.

C. Goss is used to harden the OS image: Goss is a validation tool that can be used for image hardening, but it is not part of the default NKP node preparation process. Hardening is an optional step.

D. Terraform is utilized to clone an existing OS image: Terraform is for infrastructure provisioning, not image creation or cloning. Packer handles image creation in NKP.

As stated in the NKPA 6.10 documentation, when using external storage (such as AWS S3) with Loki for log storage, AWS credentials must be provided securely. This typically involves creating a Kubernetes Secret containing the static AWS credentials (access key ID and secret access key), which are referenced in the override ConfigMap to authenticate Loki’s S3 storage backend.

Key reference from documentation:

“For Loki to store logs in an S3 bucket, AWS credentials must be created as a Kubernetes secret and referenced in the storage configuration.”

The scenario describes an isolated environment in Antarctica, implying an air-gapped NKP deployment where the bastion host serves as the primary management point for deploying and managing NKP clusters without Internet access. The NKPA course outlines the essential tools that must be installed on a bastion host to facilitate NKP deployment and management in such environments.

The required programs are kubectl and nkp:

kubectl: This is the Kubernetes command-line tool used to interact with Kubernetes clusters, essential for managing cluster resources, debugging, and applying configurations during and after deployment.

nkp: The NKP CLI (nkp) is the primary tool for deploying, managing, and scaling NKP clusters, including creating bootstrap clusters, deploying clusters, and managing platform applications. In an air-gapped setup, the nkp CLI is critical for executing deployment commands using the Air-Gapped Bundle.

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “For an air-gapped NKP deployment, ensure the bastion host has kubectl and the nkp CLI installed to manage the deployment process and interact with the resulting Kubernetes clusters.” These tools are sufficient for the engineer to deploy and operate NKP in an isolated environment.

Incorrect Options:

A. awscli and nkp: The awscli is specific to AWS environments, but the question does not specify AWS infrastructure. Additionally, in an isolated environment, awscli is less relevant without Internet access.

B. oc and kubectl: oc is the OpenShift CLI, not used for NKP deployments. NKP uses nkp CLI instead.

C. oc and az: az is the Azure CLI, and oc is for OpenShift—neither is relevant to NKP deployment.

As per the NKPA 6.10 documentation under “Application Backup and Recovery with Velero,” Velero is the out-of-the-box backup and restore solution integrated with NKP. To schedule application backups at a specific frequency (in this case, every six hours, equivalent to four times daily), the recommended approach is to use the Velero CLI to create a backup schedule.

The procedure involves:

Using the Velero CLI to create a scheduled backup targeting the specific Kubernetes namespace (victory-finance) rather than the entire workspace.

Specifying the frequency as --schedule="0 */6 * * *" (every six hours).

Providing the cluster’s kubeconfig for authentication.

Exact extract from the documentation:

“Velero’s CLI can be used to create backup schedules for application-specific workloads. Use the namespace parameter to target the namespace where the applications are deployed, and set the cron-like schedule to the desired frequency.”

To create a FIPS-compliant NKP deployment in an air-gapped environment, the following must be done:

Verify the OS (RHEL) itself is in FIPS mode.

When building the image, include both the offline fips and fips overrides to ensure the image and components are built in compliance.

When deploying the cluster, include FIPS-specific references for both Kubernetes and etcd components.

Exact extract:

“For FIPS deployments, ensure the OS is in FIPS mode, and include both offline fips and fips overrides during image creation to ensure compliant images and deployment.”

The NKPA course emphasizes that NKP supports multi-tenancy through workspaces, each of which can be configured with its own Identity Provider (IdP) for authentication. In this scenario, each group (Fin VD, Fin Insurance, Fin Travel) has its own IdP, and the engineer has created separate workspaces for them. To assign the Tenant Administrators role, the engineer must configure a dedicated IdP for each group’s workspace, enabling users to authenticate via their group-specific IdP and assume the Tenant Administrator role.

The course details that NKP uses Dex as the OIDC provider to integrate with external IdPs. For each workspace, the engineer configures a Dex connector to the group’s IdP, maps the IdP groups to NKP roles (e.g., Tenant Administrator), and assigns permissions via role bindings. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “To assign Tenant Administrator roles in NKP, configure a dedicated IdP for each workspace using Dex connectors, mapping IdP groups to the appropriate roles for workspace management.” This ensures that each group’s administrators can access only their designated workspace.

Incorrect Options:

B. Create a role named admin-tenant-X: NKP uses predefined roles like Tenant Administrator, not custom roles with specific naming conventions.

C. Create a role binding and assign it: Role bindings are part of the process, but the primary step is configuring the IdP for authentication, as per the NKPA course.

D. Configure the global Active Directory: The scenario specifies separate IdPs per group, not a global Active Directory for all groups.

For deployments in air-gapped environments where there is no external Internet connectivity, the --airgapped parameter is required. This instructs the NKP deployment to rely solely on internal resources, using pre-staged images and local container registries, ensuring that no external network dependencies cause deployment failures.

In an air-gapped NKP deployment, the Konvoy bootstrap image (used to create the bootstrap cluster) must be available locally on the bastion host or in a private registry. The NKPA course specifies that after extracting the NKP Air-Gapped Bundle, the bootstrap image (e.g., konvoy-bootstrap-image-.tar) is a tarball that needs to be loaded into the Docker daemon on the bastion host before creating the bootstrap cluster.

The most viable command is docker load -i konvoy-bootstrap-image-<version>.tar (Option A). This command loads the tarball into the local Docker daemon on the bastion host, making the image available for the nkp create bootstrap command to use. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “In an air-gapped environment, load the Konvoy bootstrap image on the bastion host using docker load -i to make it available for creating the bootstrap cluster.” After loading, the engineer can optionally tag and push the image to the private registry if needed, but the question focuses on loading the image on the host, which this command accomplishes.

Incorrect Options:

B. docker image tag: This command is syntactically incorrect (version appears twice, and .tar is not part of a tag). Tagging is a subsequent step after loading, not the primary action to load the image.

C. nkp push bundle: This is not a valid command for loading an image; it’s closer to a bundle management action, but the syntax is incorrect.

D. nkp load image: There is no nkp load image command in NKP; loading images is done via docker load.

The NKPA course explains that NKP supports auto-scaling for clusters using Cluster API (CAPI), which manages the lifecycle of Kubernetes nodes. When auto-scaling is enabled, NKP monitors cluster workloads and automatically adjusts the number of nodes based on demand. The behavior involves CAPI creating or deleting nodes as needed to scale the cluster up or down, ensuring optimal resource utilization.

The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “NKP auto-scaling uses Cluster API to dynamically create or delete nodes in response to workload demands, ensuring the cluster scales efficiently.” For example, if the workload increases, CAPI provisions additional worker nodes; if demand decreases, CAPI deletes nodes to reduce costs.

Incorrect Options:

A. CPU is hot-added or hot-removed: Hot-adding/removing CPU is not a Kubernetes auto-scaling behavior; scaling involves adding/removing nodes.

B. Memory is hot-added or hot-removed: Similar to CPU, memory scaling at the node level is not supported in this context.

C. Power-On Status/Mode of a node is changed: Auto-scaling does not involve changing node power states; it adds or removes nodes.

When an attached cluster (e.g., an external cluster like EKS) is stuck in a 'deleting' state in the NKP UI, it indicates an issue with the reconciliation process in the NKP management cluster. The NKPA course explains that attached clusters are represented in NKP as KommanderCluster custom resources in the management cluster. To resolve a stuck deletion, the engineer must manually delete the KommanderCluster resource using kubectl in the context of the NKP management cluster.

The correct command is kubectl delete kommandercluster, executed in the context of the NKP management cluster (not the attached cluster). For example: kubectl delete kommandercluster -n . The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “If an attached cluster is stuck in a ‘deleting’ state, delete the corresponding KommanderCluster resource in the NKP management cluster using kubectl delete kommandercluster to remove it from management.” This ensures the cluster is fully detached and removed from the UI.

Incorrect Options:

A. kubectl delete cluster: There is no cluster resource type in this context; the correct resource is kommandercluster.

B. nkp delete kommandercluster: The nkp CLI does not have a delete kommandercluster subcommand.

D. nkp delete cluster in the attached cluster: This command is for deleting NKP-managed clusters, not detaching external clusters, and it should be run from the management cluster context.

The NKPA course explains that NKP provides a role-based access control (RBAC) system to manage permissions within its platform, in addition to Kubernetes-native RBAC. For a development team needing limited permissions to perform specific tasks (deploying applications, scaling deployments, viewing logs and metrics) within a specific namespace, the appropriate access type in the NKP GUI is an NKP Role.

NKP Roles are predefined or custom roles within the NKP platform that map to Kubernetes RBAC permissions but are managed through the NKP UI for ease of use. They allow granular control over actions within a workspace or namespace, ensuring the team can perform their tasks (e.g., deploy, scale, get logs) without having access to other environments or cluster-wide resources. For example, an NKP Role like “Developer” or a custom role can be configured to grant edit permissions in the team’s namespace while restricting access elsewhere. The Nutanix Cloud Native (NCP-CN) 6.10 Study Guide states: “In the NKP GUI, configure an NKP Role to grant limited permissions to a development team, allowing actions like deploying applications and viewing logs within their namespace while preventing unauthorized changes in other environments.”

Incorrect Options:

B. Cluster Role: A Kubernetes Cluster Role grants permissions across all namespaces, which is too broad for the team’s limited access requirement.

C. Cluster Admin: This grants full administrative access to the entire cluster, far exceeding the team’s needs and violating the principle of least privilege.

D. Kommander Role: Kommander is a management component in NKP, but “Kommander Role” is not a specific access type in the NKP GUI for this purpose.