NCA-V6-10 Practice Questions

Cluster Lockdown is a security feature within Nutanix AOS designed to harden the cluster by restricting access. When enabled, it disables password-based SSH login to all Controller VMs (CVMs) for every user, which explicitly includes the default nutanix and admin accounts. Access is then only permitted through SSH public key authentication, significantly enhancing security by preventing brute-force password attacks and ensuring that only authorized individuals with pre-configured keys can access the CVM command line.

B. STIG: A Security Technical Implementation Guide (STIG) is a security standard or hardening methodology, not a specific Nutanix feature that you enable to block password access.

C. RBAC Policy on PC: Role-Based Access Control (RBAC) in Prism Central defines user permissions for actions within the Prism interface, not the underlying SSH authentication method to a CVM.

D. Data-at-Rest Encryption: This feature encrypts data on the physical disks to protect against data theft but does not affect user authentication or login procedures for the CVMs.

---

1. Nutanix AOS 6.5 Security Guide: In the "Securing a Cluster" section, under the sub-section "Cluster Lockdown," the documentation states, "When you enable cluster lockdown, password-based login to the CVMs is disabled for all users, including the default nutanix and admin users. You can only log in to the CVMs by using SSH with public key authentication." (Document available via the Nutanix Portal).

2. Nutanix University - Nutanix Certified Associate (NCA) 6.5 Student Guide: The "Securing a Nutanix Cluster" module describes Cluster Lockdown as the feature used to disable password-based SSH access and enforce key-based authentication for enhanced security.

Windows Defender Credential Guard is a security feature that uses Virtualization-Based Security (VBS) to isolate secrets and credentials. A primary prerequisite for enabling VBS on a guest virtual machine running on Nutanix AHV is that the VM must be configured with UEFI firmware. UEFI provides the modern boot environment and security features, such as Secure Boot, that are necessary for VBS to function correctly. Creating the VM with the older Legacy BIOS will not meet the firmware requirements for Credential Guard.

A. Live Migration: This is a cluster feature for VM mobility between hosts without downtime and is not a prerequisite for enabling a guest OS security feature.

C. HA: High Availability is a cluster-level resiliency feature that restarts VMs on a healthy host after a failure; it is unrelated to guest OS VBS requirements.

D. Legacy BIOS: This is the older firmware standard that lacks the necessary capabilities, such as Secure Boot, which are required to enable VBS and Credential Guard.

1. Nutanix University - Nutanix Certified Associate (NCA) v6.5: The courseware section on "Creating and Managing Virtual Machines" specifies that modern guest OS security features, including Virtualization-Based Security (VBS), require the VM to be configured with UEFI boot.

2. AHV Administration Guide v6.5 - Creating a VM (AHV): In the "Boot Configuration" section for VM creation, the documentation states, "Virtualization-based security (VBS) uses the hypervisor to help protect the guest OS. To enable VBS, you must configure the VM to use UEFI boot." This directly links UEFI as a mandatory setting for VBS-based features like Credential Guard.

3. Nutanix Security Guide v6.5 - Guest VM Security: This guide details the requirements for enabling security features within guest VMs. In the section discussing VBS, it explicitly lists UEFI firmware as a prerequisite for the virtual machine.

Virtual machines with attached Volume Groups (VGs) are considered non-migratable. VGs provide block storage to VMs via the iSCSI protocol, with the connection terminating on the local Controller VM (CVM) of the host where the VM resides. During host maintenance or upgrades, a live migration would sever this iSCSI session, leading to data unavailability for the VM. Consequently, the Acropolis Hypervisor (AHV) cannot live-migrate these VMs. The administrator is prompted to take manual action, which typically involves shutting down the VM before the host can enter maintenance mode.

A. VMs without NGT: The absence of Nutanix Guest Tools (NGT) does not prevent a VM from being live-migrated; it only limits access to advanced management features.

B. VMs marked as an Agent: While Agent VMs are also not migrated, this is due to a specific configuration policy. VMs with VGs are non-migratable due to a fundamental technical limitation.

C. Memory Overcommitted VMs: Memory overcommitment is a standard hypervisor resource management feature and does not block the live migration of a virtual machine.

1. Nutanix University, Nutanix Hybrid Cloud Fundamentals Courseware (NHCF 6.5), Module 5: Acropolis Storage Services. The course material explains that Volume Groups provide iSCSI services from the local CVM, a configuration that inherently prevents live migration of the attached VM.

2. Nutanix, AHV Administration Guide v6.5, Section: Volume Group Management > Limitations of Volume Groups. The guide explicitly states, "Live migration of guest VMs that are directly attached to a volume group is not supported."

3. Nutanix, Prism Web Console Guide v6.5, Section: VM Management > Managing a VM (AHV) > Updating a VM. This section details VM configurations and notes that features like direct iSCSI attachment (Volume Groups) impact VM mobility operations such as live migration.

4. Nutanix, AHV Administration Guide v6.5, Section: VM Management > Agent VMs. This document clarifies the behavior of Agent VMs: "AHV does not migrate agent VMs. When you place a host in maintenance mode, agent VMs on that host are powered off..." This confirms they are not migrated but distinguishes them from VMs with technical migration constraints like VGs.

Upon initial deployment, a Nutanix AHV cluster configures the default virtual switch (vs0) with an active-backup bond for its uplinks. In this mode, only one physical network interface in the bond is active at a time. If the active interface fails, traffic automatically fails over to a passive (standby) interface in the bond. This configuration is the default because it provides network redundancy and high availability without requiring any special configuration, such as LACP, on the upstream physical switches, ensuring maximum compatibility with various network environments.

A. Balance-SLB: This mode provides load balancing based on the source MAC address but is not the default; it must be configured manually.

C. Balance-TCP: This mode provides advanced load balancing but requires the physical switch ports to be configured for LACP, making it an optional, not default, configuration.

D. No Uplink Bond: An uplink bond is created by default to ensure network high availability for the CVM and host; not having a bond would introduce a single point of failure.

1. Nutanix AHV Administration Guide v6.5, Load Balancing in a Bond, Page 63: "By default, an AHV host configures the active-backup load balancing mode for all bonds. In active-backup mode, one NIC is active and the other NICs are passive."

2. Nutanix University, Nutanix Hybrid Cloud Fundamentals Courseware, Module 4: Networking, Section: "AHV Networking": The course material explicitly states that the default bond mode for a new AHV deployment is active-backup to ensure out-of-the-box compatibility and resilience.

3. Nutanix Networking Best Practices Guide, AHV Bond Modes, Section: "Active-Backup": "This is the default bond mode in AHV. Active-backup provides a simple active/passive configuration that is tolerant of link failure."

Prism Element's Network Visualization feature provides a graphical representation of the physical network topology, showing how Nutanix nodes are connected to the physical switches. To gather the necessary information from the switches (such as model, firmware version, and port connections), Prism Element uses the Simple Network Management Protocol (SNMP). Therefore, when adding a physical switch in Prism Element for monitoring and visualization, you must provide the switch's IP address and the correct SNMP credentials (e.g., community string for SNMPv2c or user credentials for SNMPv3).

A. DNS Configuration: DNS is used for name resolution across the cluster and network but is not a specific requirement for Prism to query a switch for visualization data.

B. NTP Configuration: NTP is essential for time synchronization within the Nutanix cluster but is not used for communicating with or configuring a physical switch in Prism.

C. SMTP Configuration: SMTP is configured in Prism to send email alerts and notifications; it is not used to retrieve information from a network switch.

1. Nutanix Prism Web Console Guide (AOS 6.5): In the "Network Visualization" section, under the subsection "Adding a Network Switch," the guide explicitly states the required fields for adding a switch. These include the IP Address and SNMP information (Version, Port, Community for SNMPv2c, or Security Level/User Name for SNMPv3). This confirms that SNMP configuration is mandatory. (Reference: Prism Web Console Guide v6.5, Chapter: Visualizing the Network, Section: Adding a Network Switch).

2. Nutanix University - Nutanix Certified Associate (NCA) 6.5 Study Guide: The guide describes Prism's capabilities, including network visualization. It explains that this feature relies on protocols like LLDP and SNMP to discover and map the physical network connections between Nutanix nodes and the top-of-rack switches. (Reference: Nutanix Certified Associate (NCA) 6.5 Study Guide, Module 3: Managing the Nutanix Cluster, Section: Prism Element).

Redundancy Factor 3 (RF3) is a data protection mechanism that maintains three copies of data across a Nutanix cluster, allowing it to tolerate the simultaneous failure of any two nodes or disks. To achieve this level of resilience and maintain a quorum for metadata operations, a Nutanix cluster must have a minimum of five nodes. If the cluster has fewer than five nodes, the option to change the Redundancy Factor to 3 will be unavailable or greyed out in the Prism interface, as the architectural prerequisite is not met.

A. Check that the cluster has been properly licensed.

Redundancy Factor is a core feature of the Nutanix architecture and is available in all license tiers (Starter, Pro, and Ultimate). It is not a feature restricted by licensing.

C. Check hardware availability of the nodes.

While nodes must be healthy for the change to complete successfully, a temporary hardware issue would likely cause the task to fail, not prevent the option from being selected in the first place.

D. Check AOS version and upgrade, if needed.

RF3 has been a standard feature in AOS for many years. It is highly unlikely that a cluster would be running a version so old that it does not support RF3, making the node count the primary prerequisite.

1. Nutanix Prism Web Console Guide (AOS 6.5): In the section Modifying Cluster Details > Increasing the Cluster Redundancy Factor, the documentation states, "To change the redundancy factor to 3, the cluster must have at least five nodes."

2. Nutanix University - Nutanix Hybrid Cloud Fundamentals Courseware: In the module Data Resiliency, the course material explains that for a Fault Tolerance level of 2 (achieved with RF3), a minimum of 5 nodes are required. This is based on the 2n+1 formula for quorum, where n is the number of failures to tolerate.

3. Nutanix Data Protection and Recovery Guide (AOS 6.5): Under the section Data-at-Rest Resiliency > Redundancy Factor, it is specified that "Redundancy factor 3 requires that the cluster has at least five nodes."

Deduplication is most recommended for workloads that generate large amounts of redundant data. Full clone Virtual Machines (VMs), particularly in Virtual Desktop Infrastructure (VDI) environments, are a prime use case. Each full clone contains a complete, independent copy of the base operating system and applications, resulting in significant data duplication across the cluster. Nutanix deduplication can identify and eliminate these redundant data blocks at the storage layer, leading to substantial capacity savings.

A. Server workloads: This is too general. While some server workloads benefit, high-performance transactional workloads like databases are often poor candidates for deduplication due to potential performance impact.

B. Linked Clone VMs: Linked clones already achieve space efficiency by sharing a common base disk at the hypervisor level, which lessens the incremental benefit of storage-level deduplication.

D. Cold data: While post-process deduplication specifically targets cold data, the primary recommendation is based on the workload type that generates the data, not just the data's temperature.

1. Nutanix University, Nutanix Certified Associate (NCA) 6.5 Study Guide: In the "Data Efficiency" module, the guide specifies that deduplication provides the most benefit for VDI workloads, particularly those using full clones, due to the high degree of data redundancy.

2. Prism Web Console Guide (AOS 6.5), Section: Data Efficiency (Compression, Deduplication, and Erasure Coding): This guide states, "Deduplication is best suited for VDI workloads, specifically for full clones, and for persistent desktops where the data is largely the same across VMs."

3. Nutanix Tech Note, Data Efficiency (document ID TN-2032): Section "Deduplication" explains that the technology is most effective in environments with many copies of the same data, citing full clone VDI deployments as the canonical example. It contrasts this with linked clones, where much of the data is already shared.

Life Cycle Management (LCM) is a Nutanix Prism feature designed to track and seamlessly update the software and firmware of all components within a Nutanix cluster. It inventories the versions of AOS, hypervisors (like AHV), and firmware for hardware components such as BIOS, BMC, and drives. LCM then provides a simplified, one-click framework to apply updates, ensuring compatibility and reducing the administrative overhead and risk associated with manual upgrade processes. Its primary purpose is to maintain the health and security of the infrastructure stack by simplifying these complex upgrade procedures.

A. To optimize server performance: Performance optimization is a function of features like the Distributed Storage Fabric (DSF), data locality, and intelligent tiering, not the primary purpose of LCM.

B. To manage network configurations: Network configurations, including VLANs and virtual switches, are managed within Prism Element or Prism Central's network visualization and management tools, not through LCM.

D. To automate application deployment: Application deployment and lifecycle automation are the primary functions of Nutanix Calm, which uses blueprints to orchestrate applications, a distinct task from infrastructure updates.

---

1. Nutanix Prism Central Guide (pc-v2023.3): In the "Life Cycle Management (LCM)" section, it states, "Life Cycle Manager (LCM) tracks software and firmware versions of all entities in the cluster... LCM identifies and displays software and firmware that are not at the latest version and allows you to update them from the Prism Central web console." This directly supports the function of simplifying software and firmware upgrades.

2. Nutanix University, Nutanix Certified Associate (NCA) v6.5 Study Guide: In Chapter 4, "Managing the Nutanix Cluster," the guide describes LCM as the tool for "performing inventory and updating software and firmware on the cluster." This reinforces that its core function is managing the upgrade lifecycle of the infrastructure stack.

The Life Cycle Manager (LCM) Framework is the core component that orchestrates the inventory and update processes for all other software and firmware on the Nutanix cluster. When performing an upgrade at a dark site (a site without internet connectivity), it is imperative to first update the LCM Framework itself. This ensures that LCM has the latest dependency information, compatibility matrix, and procedural logic to correctly identify and apply all subsequent updates to other components like NCC, AOS, or firmware. An outdated framework might not recognize newer software bundles or could mismanage the upgrade sequence.

A. MSP: The Microservices Platform (MSP) is a component that is updated by LCM, but the LCM Framework must be updated first to manage the MSP upgrade process correctly.

B. Foundation: Foundation is a tool used for initial node imaging and cluster creation. It is not a component that is upgraded through the standard LCM workflow on a running cluster.

C. NCC: While running a Nutanix Cluster Check (NCC) health check is a critical prerequisite before starting any upgrade, the NCC software itself is a component that LCM upgrades after the LCM Framework is up-to-date.

1. Nutanix Life Cycle Manager Dark Site Guide (v2.6): In the section "Upgrading Software at a Dark Site (Prism Element)," the procedure explicitly states: "If an update for the LCM Framework is available, LCM shows that first. Always update the LCM Framework before you update any other component." (Page 11)

2. Nutanix University, Nutanix Enterprise Cloud Administration (ECA) v6.5 Courseware: The module on "Cluster Maintenance and Management" describes the LCM process. It emphasizes that for LCM to function correctly and be aware of all possible upgrades and their dependencies, the LCM framework itself must be the first component to be updated. This is a foundational step in the LCM workflow.

The Nutanix OpLog is a core component of the Distributed Storage Fabric (DSF) that functions as a persistent write buffer. It is structured as a staging area on low-latency SSDs within each Controller VM (CVM). The OpLog's primary purpose is to absorb bursts of random write I/O from user VMs. Once a write is committed to the local OpLog and replicated to another CVM's OpLog in the cluster, it is acknowledged to the hypervisor. This process provides low-latency write performance. The OpLog then coalesces these random writes and drains them sequentially to the persistent storage tier, the Extent Store, optimizing backend disk performance.

B. Persistent data storage: The Extent Store is the long-term persistent data storage tier, whereas the OpLog is a temporary write staging area.

C. Global metadata: Cluster-wide metadata is managed by Medusa, a distributed key-value store, and Zookeeper, not the OpLog.

D. Dynamic read cache: The Unified Cache is the component responsible for caching read data; the OpLog is exclusively for write operations.

1. The Nutanix Bible: In the "IO Path Overview" section, the OpLog is explicitly defined: "The Nutanix architecture has a persistent write buffer, similar to a file system journal, called the OpLog... The OpLog is built on top of a staging area of SSD drives." This confirms its role as a persistent write buffer.

2. Nutanix University, Nutanix Hybrid Cloud Fundamentals Course Guide v6.5: In Module 3, "Distributed Storage Fabric," the I/O path is detailed. The guide states, "For random writes, the data is sent to the OpLog... The OpLog acts as a write cache on SSD." (Section: I/O Operations). This source verifies its function as a write buffer on SSD.

3. Nutanix Acropolis Advanced Administration and Performance Management Guide (AOS 6.5): In the "Nutanix I/O Path" chapter, the guide explains, "For most random writes, the Nutanix cluster writes the data to the oplog, which is a fast, persistent write buffer on an SSD." This directly supports the answer.