Study guide
13.4 Creating Support Cases, Required Documentation, and Insights
Nutanix Certified Associate NCA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Nutanix Cloud Platform & HCI Foundations
1.1 Nutanix NCA Exam Overview, Format, and Objectives 1.2 Hyperconverged Infrastructure (HCI) vs. Traditional 3-Tier Architecture 1.3 The Nutanix Enterprise Cloud Portfolio (NCI, NUS, NCM, EUC, NC2)
2 Chapter 2: Platform Architecture & Distributed Core Services
2.1 Hardware Building Blocks: Nodes, Blocks, Clusters, and Quorum 2.2 Controller VM (CVM) Architecture, Datapath, and Autopathing 2.3 Core Distributed Services: Cassandra, Stargate, Curator, Zookeeper, and Genesis
3 Chapter 3: Prism Administration & Cluster Operations
3.1 Prism Element vs. Prism Central Architecture and Interface Navigation 3.2 Entity Management, Categories, and Role-Based Access Control 3.3 Nutanix Licensing Tiers, Add-ons, and Pulse Telemetry
4 Chapter 4: AOS Distributed Storage Fabric & Data Placement
4.1 Storage Pools, Storage Containers, and vDisk Virtual Architecture 4.2 Redundancy Factor (RF2 vs. RF3), Failure Domains, and Fault Tolerance 4.3 Data Locality Mechanics and Intelligent Lifecycle Management (ILM)
5 Chapter 5: Storage Optimization & Business Continuity
5.1 Storage Efficiency: Compression, Deduplication, and Erasure Coding (EC-X) 5.2 Space-Efficient Redirect-on-Write (ROW) Snapshots and Zero-Byte Clones 5.3 Protection Domains, Consistency Groups, and Disaster Recovery Replication
6 Chapter 6: AHV Virtual Machine Lifecycle Management
6.1 AHV VM Provisioning, Resource Allocation (vCPU, vRAM, Disks), and Boot Types 6.2 Nutanix Image Service and Virtual Machine Templates 6.3 Nutanix Guest Tools (NGT) Architecture, Features, and Deployment 6.4 AHV High Availability (HA), Acropolis Dynamic Scheduling (ADS), and Affinity Rules
7 Chapter 7: AHV Networking & Flow Security Fundamentals
7.1 AHV Virtual Networking Architecture, Open vSwitch (OVS), and Bridges 7.2 Host Network Uplinks, Virtual Switch Configuration, and NIC Bonding Modes 7.3 Virtual Networks: Managed vs. Unmanaged Networks and IPAM 7.4 Nutanix Flow Network Security & Microsegmentation Fundamentals
8 Chapter 8: Cluster Maintenance, Health Monitoring & Support
8.1 Nutanix Cluster Health Monitoring, Alerts, and Events Engine 8.2 Nutanix Cluster Check (NCC) Architecture and Execution 8.3 Life Cycle Manager (LCM) and Rolling Non-Disruptive Upgrades 8.4 Nutanix Support Ecosystem: Diagnostics, Log Gathering, and Support Bundles
9 Chapter 9: Recognizing Nutanix Solutions, Hypervisors & the Product Portfolio
9.1 Supported Hypervisors for NCI and Feature Supportability 9.2 NCI Core Components, Configurations, and Common Deployment Scenarios 9.3 Nutanix Unified Storage: Files, Objects, and Volumes Use Cases 9.4 Nutanix Database Service (NDB) and Database Automation 9.5 Nutanix Kubernetes Platform, Enterprise AI, and End-User Computing
10 Chapter 10: Nutanix Tools — Migration, Deployment, and Validation
10.1 Nutanix Move: Cross-Hypervisor and Cloud Migration 10.2 Foundation and Foundation Central: Imaging and Cluster Deployment 10.3 X-Ray, Collector, and the Objective 1.3 Tool Inventory
11 Chapter 11: Cluster Configuration, Security & Hardware Maintenance
11.1 Cluster Services Configuration: DNS, NTP, SMTP, and SNMP 11.2 Cluster Security Options: Lockdown, Encryption, and the Recycle Bin 11.3 Node Maintenance Mode, Host Shutdown, and Cluster Shutdown 11.4 Cluster Expansion: Node Types and In-Node Expansion Capabilities 11.5 Out-of-Band Management and Remote Console Access
12 Chapter 12: Storage, Network, and Software Administration Tasks
12.1 Volume Groups, vDisk Placement, and Live vDisk Migration 12.2 Network Visualizer, Physical Switch Monitoring, and Network Segmentation 12.3 The Software Compatibility Matrix and Upgrade Path Planning 12.4 Taking and Managing VM Snapshots in Prism 12.5 License Operations: State, Assignment, Reclamation, and Expiry
13 Chapter 13: Performance Analysis, Reporting & Support Operations
13.1 Prism Analysis: Metric Charts, Entity Charts, and Custom Reports 13.2 Custom Alert Policies and Behavioural Anomaly Detection 13.3 Interpreting Workload Performance: CPU Contention, CPU Ready, Memory, and I/O Latency 13.4 Creating Support Cases, Required Documentation, and Insights
13.4 Creating Support Cases, Required Documentation, and Insights
Key Takeaways Explain This Topic AI
Support cases are opened through the Nutanix Support Portal, which requires an account associated with the entitled assets.
A case needs the cluster identification, an accurate problem description with timestamps, the business impact, and diagnostic data such as a Logbay bundle and NCC output.
Nutanix publishes support priority definitions with associated response times, and the priority should reflect real business impact.
Nutanix documentation comes in distinct types: administration guides, release notes, best practice and solution documents, knowledge base articles, and field and security advisories.
Insights uses Pulse telemetry for predictive health and support automation, including proactively identifying clusters exposed to a known issue.
Last updated: September 2026
13.4 Creating Support Cases, Required Documentation, and Insights
Objective 4.3 — "leverage support functions" — is the most practical objective on the blueprint. It is also the one a Tier 1 administrator, the blueprint's named candidate profile, will use most.
Before You Open a Case
A short triage pass resolves a meaningful share of issues and materially improves the cases that do get opened:
Read the alert properly — severity, entity, and timestamp (section 8.1).
Run the relevant NCC health check. NCC output frequently names the condition and points at a knowledge base article (section 8.2).
Search the Knowledge Base. NCC results often cite a specific KB number.
Check whether it self-resolved. Many Nutanix alerts auto-resolve when the condition passes.
If the issue persists, open a case — and everything gathered above goes into it.
Creating the Case
Cases are opened through the Nutanix Support Portal , using an account associated with your organization's entitled assets. That association is what links a case to a supported cluster, which is why a new administrator's first support interaction is often about portal access rather than the technical issue. The blueprint references "Common Nutanix Support Portal Access Issues" for that reason.
Required documentation for a case
This is a named knowledge statement — "identify the required documentation for support cases" — so know what belongs in one:
- Item Why it is needed
- Cluster identification (cluster ID / serial / block serial) Ties the case to the right entitled asset
- Software versions — AOS, hypervisor, Prism Central, NCC Determines known issues and applicable fixes
Problem description with timestamps "Slow" is unusable; "latency rose from 2 ms to 40 ms at 14:20 on 3 September" is actionable
- Business impact Drives the priority assigned to the case
- NCC health check output The platform's own diagnosis of itself
- Log bundle (Logbay) The evidence, scoped to the relevant time window (section 8.4)
- Steps already taken Prevents support repeating work you have already done
Tip
Scope the log bundle to the incident window. Logbay lets you specify a time range and filter by service tags. A bundle covering the twenty minutes around the event is far more useful — and far faster to upload and analyse — than one covering a week.
Priority and Response Times
Nutanix publishes support priority definitions and associated response times . The principle to carry into the exam:
The highest priorities are reserved for genuine production-down or severely degraded situations with real business impact.
Lower priorities cover degraded but functioning systems, and questions or requests for guidance.
Priority should reflect actual impact. Inflating priority on a low-impact case is self-defeating: it degrades the queue for everyone, and it is exactly what makes an organization's genuine emergency harder to prioritize.
Note the distinction from section 13.2: alert severity is Critical, Warning, Info and is a property of a cluster alert. Case priority is a property of a support case. They are different scales and a question may test that you do not conflate them.
Nutanix Documentation Types
"Identify the various Documentation types" is its own knowledge statement, and each type answers a different kind of question:
Type Answers
Administration guides "How do I perform this task?" — the per-release product guides (AHV Admin Guide, Prism Web Console Guide, Security Guide)
- Release notes "What changed, what is fixed, what is known broken in this build?"
- Best practice guides / solution documents "How should I design this?" — workload-specific guidance
- Reference architectures / validated designs "What is a proven, tested design for this use case?"
- Knowledge Base (KB) articles "I have this specific symptom — what is it and how do I fix it?"
- Field advisories "Is there a known hardware or software issue I should act on proactively?"
- Security advisories "Is there a vulnerability affecting my version, and what is the fix?"
- Compatibility and Interoperability Matrix "Is this combination of versions supported?" (section 12.3)
Some of these require Support Portal access, which the blueprint notes explicitly in its introduction to the objectives.
Important
Match the question to the document. A symptom → KB article. A design decision → best practice guide. What changed in this build → release notes. Is this supported → the matrix. Proactive hardware or software risk → field advisory. Exam items in this objective are usually exactly this matching exercise.
- Insights: Predictive Health and Support Automation
- The final knowledge statement is "leverage Insights for predictive health and support automation."
Insights is the cloud-side analytics service that consumes Pulse telemetry (sections 3.3 and 8.4). Because Nutanix receives configuration and health data from a large installed base, it can reason about your cluster against patterns seen across all of them.
What that enables:
Proactive identification of exposure. When a defect is discovered, Nutanix can identify which clusters are running the affected combination and notify those customers rather than waiting for each to hit the problem.
Predictive hardware failure detection , from drive and component telemetry.
Automatic case creation for certain conditions — a failed drive can raise a case and dispatch a replacement without anyone reporting it.
Configuration and health recommendations benchmarked against the wider installed base.
Pulse is the prerequisite
All of this depends on Pulse being enabled . Disable Pulse and the cluster becomes invisible to Nutanix: no proactive notification, no automatic case creation, no predictive failure detection, and a slower reactive support experience because every case starts from scratch.
That is why Objective 4.2 asks you to "verify Pulse status" and to "describe the benefits of Pulse." The benefit is not telemetry for its own sake — it is that support becomes proactive instead of reactive.
Tip
Alert-triggered log collection ties the whole chapter together: certain alerts can automatically collect the relevant logs at the moment of the event. That matters because the most valuable diagnostic data is captured while the problem is happening , not hours later when somebody gets round to opening a case.