Overview
Domain 6 has two official objectives. The first is managing Spectrum-X switch configurations through NVUE templates. NVUE is the object-oriented configuration interface of Cumulus Linux, available through the nv CLI and a REST API. Changes are staged with nv set, reviewed with nv config diff, applied with nv config apply and stored with nv config save in a YAML startup file. Templates let the same structure be filled with per-switch values, such as loopback addresses and ASNs.
The second objective is writing Ansible playbooks to automate tasks such as VLAN creation or RoCE configuration. NVIDIA provides the nvidia.nvue Ansible collection, which talks to the NVUE API, and playbooks can also push rendered YAML or run NVUE commands. At 10%, this domain holds several questions and links directly to the Spectrum settings you configure manually in Domain 2.
How it's tested
Questions show short NVUE command sequences, YAML snippets or Ansible playbook fragments and ask what they do, what is missing, or which approach scales. Expect attention to the pending, applied and saved states of NVUE configuration and to the inventory and variable structure of playbooks.
-
Order the NVUE steps
A sequence of nv commands is shown, and you identify the missing apply or save step, or the effect of each stage.
-
Complete the playbook
An Ansible fragment is given, and you choose the module, variable or task that creates a VLAN or applies RoCE settings.
-
Pick the scalable method
Many switches need the same change, and you choose templates and automation over manual per-switch commands.
An engineer runs nv set bridge domain br_default vlan 30 on a switch with auto save disabled, sees no change in forwarding, and reboots, after which VLAN 30 is still missing. nv set only modified the pending revision. The change needed nv config apply to take effect and nv config save to persist across reboots, so neither stage happened.
Objectives 2
Official objectives from the NVIDIA outline, in outline order.
6.1 Manage Spectrum-X switch configurations through NVUE templatesNVUE revisions, YAML files and templated configuration.
- What it means
- NVUE models the switch configuration as a structured object tree. You can edit it through nv commands or the REST API, view it as YAML, and generate it from templates that combine a common structure with per-device variables.
- What to understand
- NVUE keeps a pending revision for staged changes, an applied revision that is running, and a startup configuration in /etc/nvue.d/startup.yaml. nv config diff compares revisions, nv config apply activates them, nv config save persists them, and nv config replace or patch loads YAML from a file. Templates, often in Jinja2, render per-switch YAML from shared variables so every leaf receives consistent RoCE and QoS settings.
- How it shows up
- A configuration lifecycle or templating scenario is described, and you choose the correct NVUE step or file.
- Common confusion
- Assuming nv config apply always saves to startup; it does only when auto save is on, the default from Cumulus Linux 5.9.
6.2 Write Ansible playbooks to automate network setup tasks like VLAN creation or RoCE configurationAnsible inventories, playbooks and the nvidia.nvue collection.
- What it means
- Ansible automates configuration by running playbooks of tasks against an inventory of switches. For Cumulus Linux, the nvidia.nvue collection provides modules that call the NVUE API, and playbooks can also template YAML files or run commands.
- What to understand
- Store per-switch values in host_vars and group_vars, loop over lists of VLANs, and use the collection's modules so tasks are idempotent and report changed only when something differs. Run with --check for a dry run and --limit to target a subset. Test playbooks against an NVIDIA Air simulation before production, and keep them in version control.
- How it shows up
- A playbook fragment or requirement is shown, and you choose the module, variable placement or run option.
- Common confusion
- Hardcoding switch-specific values in tasks instead of inventory variables, which breaks reuse.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
NVUE
Object-model configuration interface for Cumulus Linux.
- Remember
- Available as the nv CLI and REST API.
- Tested as
- Configuration questions.
- Trap
- Editing raw Linux files alongside it.
-
Pending revision
Staged changes from nv set or nv unset.
- Remember
- Nothing changes until applied.
- Tested as
- Lifecycle questions.
- Trap
- Expecting nv set to act immediately.
-
nv config apply
Activates the pending revision.
- Remember
- Also writes startup.yaml when auto save is on (default from Cumulus Linux 5.9).
- Tested as
- Lifecycle questions.
- Trap
- Assuming it also saves.
-
nv config save
Writes the applied config to startup.yaml.
- Remember
- Needed for persistence when auto save is off.
- Tested as
- Persistence questions.
- Trap
- Skipping it before a reboot with auto save off.
-
nv config diff
Shows differences between revisions.
- Remember
- Review before applying.
- Tested as
- Change review.
- Trap
- Applying without reviewing.
-
startup.yaml
Saved NVUE configuration at /etc/nvue.d/startup.yaml.
- Remember
- Loaded at boot.
- Tested as
- File location questions.
- Trap
- Looking for a running-config text file.
-
Jinja2 templates
Render per-switch YAML from shared structure and variables.
- Remember
- Keep RoCE settings consistent.
- Tested as
- Templating questions.
- Trap
- Copying full configs per switch.
-
nvidia.nvue collection
Ansible modules that use the NVUE API.
- Remember
- Preferred for idempotent tasks.
- Tested as
- Playbook questions.
- Trap
- Using raw shell commands for everything.
-
Inventory variables
host_vars and group_vars hold per-device and shared data.
- Remember
- Keeps playbooks reusable.
- Tested as
- Playbook structure.
- Trap
- Hardcoding values in tasks.
-
Check mode
ansible-playbook --check runs a dry run.
- Remember
- Shows what would change.
- Tested as
- Safe change questions.
- Trap
- Assuming it applies changes.
-
Idempotency
Running a task again makes no further changes.
- Remember
- Reported as ok rather than changed.
- Tested as
- Automation design.
- Trap
- Writing tasks that always report changed.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
NVUE configuration states
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Pending | Changes staged with nv set | Not active yet | Thinking it is live |
| Applied | Running configuration | Saved automatically only if auto save is on | Assuming it is persistent |
| Startup | Saved startup.yaml | Loaded at boot | Forgetting nv config save |
Automation approaches
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Manual nv commands | Per-switch CLI changes | Simple, does not scale | Using it for hundreds of switches |
| NVUE templates | Rendered YAML per switch | Consistent structure | Hardcoding device values |
| Ansible nvidia.nvue | Playbooks calling the NVUE API | Idempotent and repeatable | Mixing in non-idempotent shell tasks |
| NVUE REST API | Direct programmatic access | Building custom tools | Ignoring authentication and revisions |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Set means live
- What candidates pick
- Assume nv set changes forwarding right away.
- Why it looks right
- Many CLIs apply immediately.
- Why it's wrong
- NVUE stages changes in a pending revision until nv config apply runs.
Clue to watch for The change seems to have no effect.
-
Apply means saved
- What candidates pick
- Skip nv config save after applying.
- Why it looks right
- The change is already running.
- Why it's wrong
- With auto save off, the default before Cumulus Linux 5.9, applied changes are lost on reboot unless saved to the startup file.
Clue to watch for The issue appears only after a reboot.
-
Shell tasks are fine
- What candidates pick
- Use shell commands for every switch change in Ansible.
- Why it looks right
- They mirror manual steps.
- Why it's wrong
- Shell tasks are rarely idempotent and always report changed; NVUE modules compare state first.
Clue to watch for Requirement mentions idempotent or repeatable runs.
-
One config per switch
- What candidates pick
- Maintain a full hand-edited config file for each switch.
- Why it looks right
- It looks explicit.
- Why it's wrong
- Templates with variables keep shared RoCE and QoS settings consistent and reduce drift.
Clue to watch for Many switches need the same structure.
-
Check mode applies
- What candidates pick
- Expect --check to push the change.
- Why it looks right
- It runs the full playbook.
- Why it's wrong
- Check mode only predicts changes; nothing is applied to the switches.
Clue to watch for The goal is a safe preview.
Answer framework
Use these steps for NVUE and Ansible automation questions in Domain 6.
- Identify whether the question concerns a single switch's NVUE lifecycle, templated configuration, or fabric-wide automation with Ansible.
- For NVUE lifecycle questions, trace the change through pending, applied and saved states and find which step is missing; an applied change that was never saved is lost after a reboot.
- For templates, separate the shared structure from per-switch variables such as addresses, ASNs and VLAN lists.
- For playbooks, prefer nvidia.nvue modules, store data in inventory variables, and loop over lists for repeated items like VLANs, so one task covers every entry and stays idempotent across reruns.
- Choose a safe rollout: test in NVIDIA Air, run check mode, limit to a few switches, then expand once results are verified.
Practice question
Want more like this? The NCP-AIN practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with the NVUE command reference and cheat sheet, focusing on the configuration lifecycle. In an NVIDIA Air lab, make a change with nv set, inspect it with nv config diff, turn auto save off, apply it, reboot without saving, and observe the result. Then repeat with nv config save. Doing this once fixes the pending, applied and startup states in memory better than reading about them.
Next, export a switch configuration as YAML with nv config show -o yaml and turn it into a Jinja2 template with variables for hostname, loopback, ASN and VLANs. Render it for two leaves and compare the results.
Then read the NVIDIA technical blog on automating networks with NVUE and Ansible and the nvidia.nvue collection documentation. Write a playbook that creates a list of VLANs and applies the RoCE QoS profile, run it twice, and confirm the second run reports no changes. Finally, practice with check mode and --limit. These hands-on steps cover nearly everything this domain tests.
FAQ
How much of NCP-AIN is Automation and Configuration?
Automation and Configuration is 10% of the exam, with two official objectives on NVUE templates and Ansible playbooks.
What is the difference between nv config apply and nv config save?
Apply activates pending changes on the running switch. Save writes the applied configuration to the startup file so it survives a reboot. From Cumulus Linux 5.9, auto save is on by default, so apply also saves unless auto save is turned off.
Where is the NVUE startup configuration stored?
In /etc/nvue.d/startup.yaml on Cumulus Linux, loaded when the switch boots.
What is the nvidia.nvue Ansible collection?
A set of Ansible modules from NVIDIA that configure Cumulus Linux through the NVUE REST API, supporting idempotent tasks.
Why use templates for switch configuration?
Templates keep shared settings such as RoCE and QoS identical while variables fill in per-switch values, reducing configuration drift.
How can I test automation safely?
Run playbooks against an NVIDIA Air digital twin, use check mode for a dry run, and limit the first rollout to a few switches.
Other Artificial Intelligence & Machine Learning certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 6 knowledge
You have covered NVUE configuration states, templates and Ansible playbooks for VLANs and RoCE. Test whether you can spot missing steps in automation scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the NCP-AIN AI tutor Get any concept explained your way