Nutanix NCP-CI-AWS flashcards
Nutanix NCP-CI-AWS · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- NC2 bare-metal requirement
- NC2 on AWS runs AHV only on bare-metal EC2 instance families such as i3.metal, because nested virtualization and direct NVMe access are required. Standard virtualized instances are not supported.
- Minimum NC2 cluster size
- A production NC2 cluster needs at least three nodes so that RF2 can tolerate a single node failure. Fewer nodes cannot satisfy resiliency requirements.
- Prism Central placement on NC2
- Prism Central runs as a separate EC2 instance in the same VPC as the cluster it manages, not as a VM inside the AHV cluster.
- NC2 deployment orchestration
- The NC2 console provisions clusters by creating CloudFormation stacks, IAM roles, and bare-metal EC2 instances inside the customer's own AWS account and VPC.
- NC2 data plane ownership
- All workload data stays in the customer's AWS account and VPC. Nutanix hosts only the management console and licensing metadata, not customer VM data.
- Bare-metal quota prerequisite
- Before deployment, verify the AWS account has sufficient bare-metal vCPU quota in the target region and availability zone. Exhausted quota is a frequent cause of failed builds.
- Single AZ cluster scope
- An NC2 cluster lives entirely within one AWS availability zone. Cross-AZ resilience requires a second cluster plus asynchronous replication between them.
- Guest VM traffic path
- AHV NATs guest VM traffic out through the node's elastic network interface, so AWS security groups and network ACLs filter all VM traffic.
- Hybrid connectivity options
- On-premises to NC2 connectivity uses AWS Site-to-Site VPN or Direct Connect attached to a virtual private gateway or transit gateway. NC2 does not create these attachments.
- Subnet IP capacity planning
- The cluster subnet must hold node IPs, Prism Central, and the IPAM pool assigned to guest VMs. Exhaustion blocks VM creation and cluster expansion.
- Egress and NAT gateway
- NC2 needs outbound internet or proxy access for licensing, Prism registration, and updates. A NAT gateway with a stable elastic IP supports allowlisting.
- Reserved AWS subnet addresses
- AWS reserves the first four and last IP address of every subnet. The AHV cluster virtual IP must not be assigned from these reserved addresses.
- Prism Central authentication sources
- Prism Central accepts local users, Active Directory or LDAP directories, and SAML 2.0 identity providers. Roles map to users or directory groups.
- Prism projects for isolation
- Projects bind VMs, users, and roles together so tenants see only their assigned resources. They provide multi-tenant isolation within one Prism Central.
- NC2 IAM role dependency
- NC2 relies on IAM roles and instance profiles created at deployment. Deleting or rotating them breaks snapshots, scaling, and CloudFormation updates.
- Flow Network Security scope
- Flow enforces distributed firewall rules inside AHV based on VM categories, names, or subnets. AWS security groups still filter at the ENI layer independently.
- CloudTrail audit coverage
- AWS CloudTrail records API calls made by NC2 service roles in the customer account, complementing Prism Central task and user audit logs.
- LCM upgrade role
- Lifecycle Manager inventories AOS, AHV, and firmware versions and performs rolling upgrades. Only NC2-validated version sets from the compatibility matrix should be applied.
- NCC health checks
- Nutanix Cluster Check validates cluster health and configuration. Run it regularly and resolve failures before upgrades or disaster recovery tests.
- Scaling an NC2 cluster
- Adding nodes is done from the NC2 console, which provisions additional bare-metal instances. Scale-down must keep the cluster above minimum node count and RF requirements.
- Ephemeral instance store risk
- NC2 storage uses local NVMe instance store tied to the EC2 instance. Stopping or terminating nodes destroys data unless snapshots or replication protect it.
- Idle cluster cost behavior
- Bare-metal instances bill hourly regardless of VM activity. Idle NC2 clusters remain expensive, so capacity and cost reviews should include AWS Cost Explorer.
- Protection domain purpose
- Protection domains group VMs so snapshots are crash-consistent across the group. Local snapshots remain on the same cluster and do not survive cluster loss.
- Async replication RPO
- Asynchronous replication sends snapshots to a remote NC2 cluster on a schedule. The RPO equals the interval between replication runs.
- Nutanix Leap recovery plans
- Leap orchestrates DR with recovery plans defining boot order, IP remapping, and one-click failover to a standby NC2 cluster. Test failover validates plans safely.
- Nutanix Move migration
- Move migrates VMs from VMware, Hyper-V, or AWS EC2 into AHV on NC2. It requires network reachability and sufficient target cluster capacity.
- Leap test failover
- Test failover clones protected VMs into an isolated network on the recovery cluster. Production replication continues and no production traffic is disrupted.
- NearSync replication tradeoff
- NearSync achieves RPO in seconds but demands low-latency links and specific licensing. Cross-region NC2 DR typically uses standard asynchronous replication instead.
- Cluster build failure triage
- Check the NC2 console task log and CloudFormation stack events first. Bare-metal quota, IAM permission errors, and subnet IP exhaustion are the leading causes.
- Prism registration failure checks
- When Prism Central cannot register a cluster, verify outbound NAT or proxy access, DNS resolution, and routability between the cluster VIP and Prism Central IP.
- EC2 instance status check
- A failed EC2 instance status check indicates host-level AWS failure. The node must be replaced rather than repaired from inside the guest.
- Support log collection
- Gather Prism log bundles and NCC output, then include the NC2 cluster ID and AWS region in the support case. Add CloudTrail logs for AWS-layer issues.