I85PREP
⌘ K
NCA-GENL study materials
NCA-GENL study resources

Three Audit Findings and One Weekend Window

NCA-GENL · Put your knowledge to work in context.

All case studies

Three Audit Findings and One Weekend Window

A six-node AOS 6.5.1 cluster managed by Prism Central 6.5 hosts 210 VMs. An internal audit makes three findings: data at rest must be encrypted; management access must be limited to two jump hosts and the Prism Central address; and all AOS nodes must be on a supported release within the quarter. The platform team confirms a KMIP-compliant key management server is available and already used by the backup product. LCM reports an AOS upgrade to 6.8 is available for all six nodes. Encryption has never been enabled. The cluster was bought with the standard drive configuration, and the hardware bill of materials lists a drive model with no self-encrypting-drive designation. The security team wants all three findings closed in a single weekend window, in the order encryption, then upgrade, then lockdown, because 'the window is hard to get'.

1. What must be confirmed before encryption at rest can be enabled, and what is the consequence if the drives are not self-encrypting?

Read the worked answer

Prerequisites to confirm:

  • Self-encrypting drives (SEDs). Nutanix data-at-rest encryption relies on the drives performing the encryption, managed through the cluster. Check the actual drive models reported by the cluster, not just the purchase order, and confirm SED capability per node.
  • A reachable KMIP-compliant key management server with credentials and certificates the cluster trusts, reachable from every CVM, and itself highly available. If the KMS is unavailable when nodes reboot, the cluster cannot unlock - this is the availability risk that must be signed off, not glossed over.
  • Supported version combination of AOS and Prism Central, plus free capacity for the data rewrite and a maintenance window long enough for it.

If the drives are not SEDs: encryption cannot be enabled in place. No amount of configuration substitutes for the hardware capability. The finding becomes a hardware project - drive or node replacement - and the audit response must say so with dates and a compensating control in the interim (for example, restricting physical access and tightening management-plane controls). Promising to 'turn on encryption' on non-SED hardware is the failure mode to avoid; verify the BOM against what the cluster reports before committing to any date.

2. Critique the proposed order (encryption, then upgrade, then lockdown) and give the order you would use with the reasoning.

Read the worked answer

The proposed order is backwards, and cramming all three into one weekend maximizes risk.

Problems with it:

  • Doing encryption first means doing the riskiest, most I/O-intensive change while the cluster is on an older release that may handle it less well, immediately before a rolling reboot.
  • The LCM upgrade then reboots every CVM on a cluster that has just rewritten its data and now depends on an external KMS being reachable throughout.
  • Applying lockdown last, with no validation time left, means the first thing you debug on Monday is a management-access change nobody has tested.

Order I would use:

  1. Validate the KMS end to end - connectivity from each CVM, certificate chain, redundancy, and a documented recovery procedure for a KMS outage.
  2. Upgrade AOS with LCM in its own window. Confirm NCC clean beforehand, then verify cluster health and resiliency afterward.
  3. Enable encryption in a separate window. It rewrites data, is I/O heavy, and needs time to complete and be verified per node.
  4. Apply lockdown last, after everything else is stable, with console/IPMI access confirmed and a rollback step written down.

If only one weekend exists, close one finding properly rather than three badly. Auditors accept a sequenced plan with dates; they do not accept a self-inflicted outage.

3. What will cluster lockdown actually affect, and what must be on the whitelist before it is enabled?

Read the worked answer

What lockdown does: it restricts management access to the cluster to a defined list of IP addresses or subnets. Inbound connections from anything not on the list are rejected. It does not stop the cluster from making outbound connections, and it is not a substitute for user authentication or role-based access control.

Must be on the whitelist before enabling:

  • The Prism Central address(es). If Prism Central cannot reach the cluster, you lose centralized management, alerting, and Calm/Move operations against that cluster.
  • Both jump hosts, ideally the whole management subnet rather than single addresses, so a jump host rebuild does not lock you out.
  • Backup and replication targets - the backup server or appliance and any remote cluster receiving snapshots.
  • Monitoring and automation endpoints that call the API, including scripts and CI runners.
  • Any disaster recovery or operations tooling that polls the cluster.

Also confirm before enabling: out-of-band console or IPMI access to every node works, NTP and DNS are healthy, and someone has tested access from each whitelisted host. The classic failure is whitelisting Prism Element access but forgetting Prism Central, which silently breaks the management plane without breaking the workload - the outage is discovered days later when the next change is attempted.