Skip to content
Neon
Menu

Free self audit

The 124 Requirements Your NCP Bid Must Answer

Start with five requirements to discuss with your architect. Score those answers immediately, then work through the 32 hard gates and the remaining requirements. This self audit covers 124 items extracted from NVIDIA’s published AI-cloud requirements.

Taken from NVIDIA Requirements for AI Clouds. Source snapshot: 2026-08-21. Each item carries its NVIDIA requirement ID. Informational and duplicate rows are excluded. Check the linked source for later changes.

Further reading: design repeatability, bid delay and a proposed CNP03 acceptance test.

Answers stay in your browser until you request a score. We do not store them against your name. A requirement is treated as a hard gate when NVIDIA's own published text uses must, mandatory, required or only. Everything else is scored.

0 of 124 answered

First unanswered

01

Start with five decisions

Start the conversation on provisioning, access, isolation, hardware and storage. Ask the responsible owner for evidence. This short pass does not assess the full design.

  1. CNP03NVLink-Aware Allocation. For NVL72, the API must support NVLink domain-aware allocation.
  2. SEC07Admin Interfaces. All administrative interfaces, whether UI, CLI or API, must be protected by multi-factor authentication.
  3. SEC11Tenancy Model. Hard physical or logical isolation for network, data and compute, with mandatory separation of control planes and tenants, and hierarchical tenancy.
  4. SEC20At-Rest Data Protection. Mandatory encryption of all data at rest, including local NVMe and SSD and network-attached storage, via self-encrypting drives.
  5. HSS01Provisioning APIs. Storage provisioning via vendor portal or API, or via the NCP portal or API.

02

Remaining hard gates

Check these first. Unanswered items remain unknown.

  1. CNP04Resource States. Clear resource states including provisioning, running, degraded, maintenance required, stopping, stopped, terminating and terminated.
  2. CNP06Console Access. Serial console access. Read-only is sufficient, interactive preferred. Output logged with at least one day retention, one month desired.
  3. CNP08Stable Identifiers. All resources, such as nodes and switches, must have a stable and persistent ID that does not change during their lifespan.
  4. CNP09Firmware. Between tenants, all firmware must be brought to a known good state, and all firmware must be cryptographically signed and attested during boot.
  5. CNP10Remote Management. Platform management solutions such as BMC must support Redfish over TLS, with IPMI disabled.
  6. SDN10DNS Private Domain. Each node's DNS resolver must be able to forward a tenant-defined private domain to a tenant-specified DNS server.
  7. K8S01Certified Versions. Official CNCF-certified versions only, no proprietary forks, and passing the standard Kubernetes conformance tests.
  8. K8S14Control Plane Isolation. Per tenant Kubernetes control plane nodes must be separate from worker nodes and outside the tenant cluster or VPC.
  9. K8S15Access Controls. The cluster endpoint must provide network access controls.
  10. K8S21API Extensions. Mandatory support for CRDs and validating and mutating admission controllers.
  11. SEC03Credential-Based Access. External services must support credential-based access including long-lived credentials with configurable expiration and rotation, with ownership attribution.
  12. SEC12BMC Security. Out-of-band management must be on a dedicated restricted network, physically separate or VLAN and VRF isolated, accessible only via a hardened bastion.
  13. SEC14Private Access. No public internet access by default. All API endpoints must be restricted via firewall or private link.
  14. SEC19SOC 2. SOC 2 Type 1 or better is required, covering security, availability and confidentiality across all services and data centre infrastructure.
  15. SEC22Root of Trust and Secure Boot. Mandatory hardware root of trust across all platforms using TPM 2.0, with UEFI Secure Boot enabled.
  16. DIR02NFS Storage. NFSv4 protocol shared storage is required, and access control based on distribution lists requires POSIX.
  17. DIR03Snapshots. The file system must support snapshot and restore functionality.
  18. DIR04LDAP. The file service must support integration with an NVIDIA-managed LDAP.
  19. HSS06RDMA Memory Protection. Storage systems using RDMA must enforce memory protection via authorization keys for both local and remote access.
  20. HSS08Single File System Size. Must be possible to allocate a file system of at least 1 PiB even if the initial request is less, growing beyond 10 PiB as cluster size increases.
  21. HSS13Root-Squash. Root-squash must be enableable, disableable and manageable at any time.
  22. HSS14flock Mount Option. It must be possible to mount the file system with flock.
  23. HSS16High Availability. All services must tolerate any critical component failure in the backend and provide continued client access.
  24. HSS18Client Multipathing. Clients must have multipathing to all storage servers.
  25. HSS19LDAP for NFS. NFS-based high-speed filesystem services must integrate with an NVIDIA-managed LDAP, including group membership for users with more than sixteen groups.
  26. DMS03Access to GPU Storage. The same filesystem mounted on GPU nodes must be mountable on the data mover nodes.
  27. STG03Stable IP Assignment. Storage nodes must support static IP addressing that remains stable during host lifecycle operations and does not reset between maintenance events.
  28. STG06BlueField/DPU Support. For BlueField-based storage architectures, the host provisioning system must support lifecycle management and configuration for BlueField JBOF systems.

03

Compute and network provisioning

  1. CNP01API/CLI Access. API or CLI access to the provisioning system for node lifecycle management, network configuration, inventory and topology discovery, security configuration, and maintenance operations.
  2. CNP02Declarative Resource Interfaces. Appropriate mechanisms for multi-step workflows. A Terraform provider is preferred for tasks such as filesystem provisioning.
  3. CNP05Tagging. Support for user-defined tags and labels, and cloud-init metadata on instances.
  4. CNP07VMs per Node. GPU nodes: one VM per node maximum. General purpose CPU nodes: multiple per node with memory and core count selection.

04

Boot process and disks

  1. BOOT01Image Deployment and Updates. API-driven workflow to deploy, update and manage vendor-provided or custom disk images via bare metal, VM or Kubernetes node pool provisioning.
  2. BOOT02Instance Metadata from Guest OS. Support for cloud-init and instance metadata discovery via link-local addresses or virtual devices.
  3. BOOT03Custom Disk Images. Support for tenant-created custom OS images such as raw and qcow2, with API calls for get, list, create and delete, accessible across projects, clusters and environments.
  4. BOOT04Node Local Storage. GPU and CPU nodes support access to node local storage, NVMe or SSD, for scratch or caching.

05

SDN and virtual networking

  1. SDN01Virtual Networking. Full API and CLI lifecycle management for software-defined private networks, supporting non-conflicting BYOIP including 7.0.0.0/8 and stable private IP allocations.
  2. SDN02Security Groups. VPC-style security groups or equivalent, including IP and CIDR based allow and deny rules, scoped at workload, node, service and subnet or tenant levels.
  3. SDN03Security Operations. Full API and CLI capability to create, read, update and delete security groups, including defined audit processes.
  4. SDN04Tenant Isolation. Hard logical or physical network segmentation for out-of-band management, user traffic and storage-specific operations.
  5. SDN05Floating IP. Ability to switch a floating private IP between nodes via API in under ten seconds without requiring an instance reboot.
  6. SDN06Localized DNS. Tenant-defined localized DNS configuration to enable internal domain resolution to private endpoints such as storage endpoints.
  7. SDN07VPC Peering. Cross-virtual-network connectivity with full bandwidth and no hairpin routing.
  8. SDN08Storage Mesh Connectivity. Unrestricted L3 routing between all storage hosts, enabling full-mesh, all-to-all communication across different subnets without traversing a gateway.
  9. SDN09Observability. Comprehensive logging for network infrastructure including hardware faults, latency and performance fluctuations, and a detailed audit trail of all configuration changes to network filtering rules.

06

Kubernetes as a service

  1. K8S02Version Updates. Support the three most recent minor releases, with new minor versions available within four to six weeks of upstream release, and automated control plane security patching.
  2. K8S03EOL Policy. Defined notification periods for version deprecation.
  3. K8S04Kubernetes Security Response. Participate in the Kubernetes Security Response Committee process, disclose vulnerabilities responsibly, receive embargo notifications and patch during embargo.
  4. K8S05Lifecycle Management, Control Plane. API, CLI or Terraform provider for CRUD provisioning, with control plane bring-up in under thirty minutes.
  5. K8S06Lifecycle Management, Node Pool. API, CLI or Terraform for CRUD, specifying node type, default labels and taints, and the ability to down-scale specific bad nodes.
  6. K8S07API Server Metrics. Share API server metrics in a Prometheus scrapable format so the API server SLO can be measured.
  7. K8S08Versioning. Provider-managed control plane upgrade processes.
  8. K8S09Zero-Downtime Upgrades. Minor version control plane updates without application downtime or maintenance windows.
  9. K8S10Node Upgrades. User-initiated rolling updates that respect pod disruption budgets.
  10. K8S11HA Control Plane. Redundant architecture with etcd separation.
  11. K8S12Backup and Disaster Recovery. Supported recovery within defined RPO and RTO, auditable and testable.
  12. K8S16IAM Integration. Kubernetes service accounts integrate with the platform IAM system so workloads can assume platform-managed identities and roles with appropriate scopes.
  13. K8S17Service Accounts. Standard service accounts and projected tokens as the workload identity mechanism, including a cluster-specific OIDC issuer for workload identity federation.
  14. K8S19Encryption. At-rest encryption for etcd and secrets.
  15. K8S20Logging. Ability to view or export Kubernetes control plane logs including apiserver and kcm.
  16. K8S22CNI. Standard compliance, support for network policies, with IPv4 and IPv6 dual-stack desired.
  17. K8S23CSI. A CSI driver installable by NVIDIA for block, shared filesystem and NFS, supporting static and dynamic provisioning, snapshots and resizing, with tenant cluster scoped credentials.
  18. K8S24DRA. Dynamic Resource Allocation enabled regardless of upstream feature status.
  19. K8S25Operator Support. Standard operator-based management of hardware accelerators and associated drivers, with provider defaults replaceable for GPU and network operators.
  20. K8S26Clusters. Support multiple clusters in the same tenancy and multiple clusters in the same VPC.
  21. K8S27Control Plane Size Pinning. Pin control plane instances to handle a particular load limit.
  22. K8S28Performance. Meet the standard Kubernetes performance test certified up to 5000 nodes, or the maximum cluster size, whichever is smaller.
  23. K8S29LoadBalancer Service Support. Support LoadBalancer services with external and internal load balancers, public and private IPs, and static IP assignment.
  24. K8S30DNS Configuration. Configure Kubernetes internal DNS with conditional forwarding rules for specified DNS zones.
  25. K8S31Configurable CIDR Ranges. Ability to configure the Kubernetes service IP range, node IP range and pod IP range.

07

Identity and access management

  1. SEC01Authentication. Standards-based user authentication via OIDC and SAML 2.0 with federation for SSO, validating signature, issuer, audience, expiration and claims.
  2. SEC04Authorization. Least-privilege RBAC for all managed services and infrastructure, with granular API actions, scopes and function.
  3. SEC05Directory Services. Integration with NVIDIA LDAP so user identities and group membership can be resolved by dependent services.
  4. SEC06Workload Identity. Standard workload, service and node security identities using short-lived credentials, including OIDC-based workload identity federation.
  5. SEC08Audit Logs. Audit logs for security-relevant events retained a minimum of thirty days, with an export mechanism, including tenant, project, region, service, resource ID, actor, timestamp, source IP, action and authorization result.
  6. SEC23Provisioning. SCIM 2.0 for automated user and group lifecycle management from enterprise identity providers.
  7. SEC24Domain-Based IdP Routing. Map multiple email domains to a designated identity provider.
  8. SEC25Organization-Level Policies. Organization-level security guardrail policies that cascade across all subordinate tenant resources and cannot be weakened or bypassed by lower-level configuration.
  9. SEC26SSO Enforcement. Administrators can enforce federated SSO for a tenant, restricting local username and password and other non-federated login for regular users.
  10. SEC27Account Management. A programmatic mechanism to create and manage isolation units, IAM users, service accounts and logs.

08

Cryptography and key management

  1. SEC09Key and Certificate Lifecycle. Secure issuance, distribution, storage, rotation and revocation of cryptographic keys and certificates, with automated rotation at configurable intervals and auditable expiry.
  2. SEC10Key Usage. Use of managed keys and certificates across platform services for encryption, authentication and signing.

09

Network isolation and encryption

  1. SEC13Network Traffic Encryption. Encryption and mutual authentication, mTLS or equivalent, for all east-west and north-south network traffic.

10

Edge network security

  1. SEC15Edge Network Security Policy. All traffic filtered via security groups or customizable ACLs using five-tuple rules.
  2. SEC16Enforcement. Specify the enforcement technology, such as hardware firewalls, SDN or DPUs, and its placement in the packet path.
  3. SEC17Threat Intelligence and Scale. Ability to subscribe to GeoIP threat and embargo feeds and import them into security groups, with maximum supported records and rules disclosed.
  4. SEC18MACsec Protection. Protect links between the data centre and the NVIDIA point of presence.

11

Hardware security and compliance

  1. SEC21Data Sanitization. Data sanitization between tenants or on hardware replacement, including cryptographic erase of all data drives.

12

Break-fix

  1. BFX01Break-fix Lifecycle. Power-cycle individual nodes or reset VM instances, reset GPUs on an individual node, return and report node and rack, cordon a node as unschedulable, and request host replacement when thresholds are breached.
  2. BFX02Break-fix Events. Query upcoming and current maintenance events, retirement notices and historical status, with event details including ticket dates, hardware identifier, category, description, action, account ID, ticket ID and node handover date.
  3. BFX03Diagnostics. Identify serial numbers of installed hardware including chassis, baseboard, network adapters, CPU and GPU, and inspect firmware versions of compute nodes and switch trays.

13

Home directory storage

  1. DIR01UID/GID Quota. Configurable filesystem-wide limit, default user and group quota settings, per-UID and per-GID overrides, and usage accounting.

14

High-speed storage

  1. HSS02Performance. Provision the throughput requested for minimum bandwidth and IOPS.
  2. HSS03Integration. Kubernetes CSI support, and a break-fix API to report storage issues.
  3. HSS04Quota Support. Configurable filesystem-wide limits, default UID and GID quota settings, per-UID and per-GID overrides, and directory quotas with usage accounting.
  4. HSS05Upgrade and Maintenance. Provider-initiated maintenance that NVIDIA can schedule and defer up to two weeks, with non-disruptive upgrades.
  5. HSS07Parallel High Speed Filesystem. A parallel or multi-path high-speed filesystem scaling to thousands of simultaneous clients while sustaining requested performance.
  6. HSS09Multiple Filesystems. More than one filesystem within total capacity, with a minimum filesystem size of 50 TiB or less.
  7. HSS10Filesystem Expansion. Live expansion in capacity, inodes, IO performance and metadata performance, scaling linearly.
  8. HSS11Client. Describe the client, support integration with NVIDIA kernels, provide DKMS-enabled packages for supported Ubuntu releases and ARM64 versions for GB200-ready kernels.
  9. HSS12Quota. Soft and hard quotas by user, group and project directory, with enforcement.
  10. HSS15Audit Changes. Access to changelog data for filesystem auditing and detailed user operations tracking.
  11. HSS17Multi-Node Coherency. One second or less for client attribute and dentry cache updates and invalidates.

15

Data movement systems

  1. DMS01Dedicated K8s Cluster. A provider-managed Kubernetes cluster for the data mover stack, available ahead of GPU cluster bring-up to pre-stage data.
  2. DMS02Data Mover Nodes. Dedicated CPU nodes for the data mover with high performance networking.
  3. DMS04Access to Corporate Network. A dedicated link to the NVIDIA corporate network, preferably with VPN, otherwise with a stable IP for allowlisting.
  4. DMS05Stable Egress IP. A stable IP for allowlisted access to NVIDIA services.

16

Managed storage deployment

  1. STG01Operating System Support. A workflow allowing storage operators to integrate vendor-provided or storage-specific operating system images via bare metal or VM provisioning.
  2. STG02Drive Sanitization Policy. Cryptographically erase data drive contents between storage system tenants with full attestation of host firmware.
  3. STG04Out-of-Band Failure Detection. Detect system failures out of band, including device, network, memory and drive failures.
  4. STG05Topology Observability. Visibility into failure domains, to allow provisioning of storage nodes with physical diversity.

17

Network transport and fabric visibility

  1. NET01Backend Switch Fabric API. An API providing visibility into the backend network switches connecting nodes to the core, each with a unique stable identifier.
  2. NET02NVLink Domain API. For compute nodes supporting NVLink, the API returns the unique identifier of the NVLink domain associated with each node.
  3. NET03Non-Conflicting IP Space. Support BYOIP, provide static IP allocations persisting across restarts, support the 7.0.0.0/8 space, and support advertising and routing of BYOIP prefixes.
  4. NET04Connection to Corporate Network. Bandwidth up to 10 Gbps, transport via private cloud interconnect with BGP, exchanging private IP space.
  5. NET05Connection to Storage. Private cloud interconnect with BGP for high-bandwidth, end-to-end MACsec-encrypted access between GPU clusters and on-premises object storage.
  6. NET06Cluster Local Internet Access. Egress NAT IPs as a static pool dedicated to the tenancy, with redundant upstream paths for connectivity under failure.

18

Capacity and fleet management

  1. CAP01Governance Metrics. Report delivered nodes and GPUs, healthy nodes meeting SLA, reserved capacity allocated to an account or project, and total active in-use capacity.

19

Service delivery SLAs

  1. BM01Benchmarking for Exemplar Cloud. Run per scalable unit, for example a 512 GPU cluster, and achieve within 5% of NVIDIA's target performance on every unit handed off.

18

Review before scoring

Check coverage before scoring. Unanswered requirements remain unknown.

Score the reviewed answers

Unanswered items are counted as unknown, which on a live bid is the same as a gap.