Eric Sloof

Set up a cloud GPU "practice lab" for NVIDIA NCA-AIIO: deploy a RunPod Pod, connect via JupyterLab/SSH, verify CUDA + GPU, and run quick AI/ops checks you can reuse on the exam.

Why RunPod is Useful for NCA-AIIO Prep

The NCA-AIIO exam leans practical: you should be comfortable with GPU-enabled Linux environments, basic tooling, and connecting to remote compute. RunPod Pods give you a ready-to-use GPU VM-like environment (container-based), JupyterLab for interactive learning, SSH for real "ops-style" workflows, and a repeatable lab you can start/stop when studying.

What You'll Build (End State)

By the end of this tutorial you'll have a running GPU Pod based on an official PyTorch template, working JupyterLab access, working SSH access for terminal-first workflows, and a short "exam-style checklist" of commands to validate GPU/CUDA and environment sanity.

Step 1 — Deploy a GPU Pod (Template-Based)

In the RunPod Console, go to Pods → Deploy. Choose an official RunPod PyTorch template — these come with JupyterLab pre-configured. Expose port 8888/http for JupyterLab, and optionally port 22/tcp if you want classic SSH workflows.





Set a Jupyter password via environment variable: JUPYTER_PASSWORD=your_secure_password.

Tip for beginners: keep it simple — don't customize the container start command unless you know why.

Step 2 — Connect via JupyterLab (Beginner-Friendly)

Open your Pod and click Connect. Under HTTP Services, open Jupyter Lab (typically on port 8888).

If you hit a blank page, wait about 60 seconds and hard refresh — Jupyter can take a bit to come up, especially on first boot.

Step 3 — Set Up SSH (More "Ops-Like")

For NCA-AIIO-style comfort, SSH is worth learning because it mirrors real infrastructure work.

3A) Add Your SSH Key to RunPod

Generate a key on your laptop with this command:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "you@example.com"

Then view your public key:

cat ~/.ssh/id_ed25519.pub

Copy the output into your RunPod account under SSH Public Keys in user settings.

3B) Connect Using the Pod SSH Command

In the Pod's Connect menu, copy the provided SSH command — RunPod shows it for your pod when SSH over exposed TCP is supported — then run it locally.

Note: SSH key injection typically happens at Pod startup. If you add keys after the pod is already running, you may need to redeploy or reset the pod, or manually append the key to ~/.ssh/authorized_keys on the pod.

Step 4 — Your NCA-AIIO GPU Sanity Checklist

These commands are perfect for a study routine. Run them in the Jupyter terminal or over SSH.

4A) Confirm You Can See the GPU

nvidia-smi

Look for the GPU model name, driver version, and GPU memory usage.

4B) Confirm CUDA Toolchain Basics

nvcc --version

Note: some images may not include nvcc by default — that's okay. nvidia-smi is the most important first check.

4C) Confirm PyTorch Sees the GPU

python -c "import torch; print('torch', torch.version); print('cuda?', torch.cuda.is_available()); print('device', torch.cuda.get_device_name(0) if torch.cuda.is_available() else None)"

4D) Quick Environment Inspection (Ops Habit)

uname -a df -h free -h python --version pip --version

This builds the muscle memory you need for troubleshooting exam-style scenarios.

Step 5 — Common Troubleshooting You Should Practice

JupyterLab Won't Load / Blank Page

Wait 60 seconds — first start can be slow. Try a hard refresh with Ctrl+Shift+R or Cmd+Shift+R. Open an incognito window. Check the Pod logs in the console for Jupyter startup lines.

SSH Doesn't Work

The most common causes are port 22 not being exposed or SSH over exposed TCP not being enabled by the template, or an SSH key that was added after pod start and therefore wasn't injected.

Step 6 — Clean Shutdown Habits (Cost + Hygiene)

When you're done studying, stop the Pod to avoid compute charges. Keep in mind that stopped pods can still incur storage costs for disk and volume.

Real-world troubleshooting techniques are showcased, emphasizing the importance of identifying the initial root cause by using SDDC Manager APIs and reference tokens to bypass limited interface details.

Last week I successfully passed the VCAP Operations and VCAP VKS exams. With that, my full set of VCF 9 discipline-aligned VCAP certifications is - for now - complete. All five core disciplines are covered: Operations, Automation, Networking, Storage, and VKS. This feels like the right moment to reflect on what this journey means, and to look ahead at where it leads.

The five disciplines

The 2025 VCAP expansion was the largest in VMware's history: eleven new exams across both role-based and domain-specific tracks. For VCF 9, the five discipline certifications each validate deep, hands-on expertise in a specific technical domain within the platform.

• Storage 
• Networking 
• Automation 
• Operations 
• VKS 

The VKS certification deserves a special mention. Within the new VCF certification framework, the Kubernetes-focused VCAP is a mandatory component on the path to VCDX. This reflects the growing role of modern application platforms - The Kubernetes Supervisor - as an integral part of VMware Cloud Foundation, not an optional add-on.

A fundamentally changed certification landscape

Broadcom has completely overhauled the VMware certification program. Where it once revolved around product-specific knowledge, the new framework is explicitly role- and platform-oriented. Instead of validating isolated component expertise, it now asks professionals to demonstrate understanding of VMware Cloud Foundation as an integrated platform - compute, storage, networking, automation, and observability working as one cohesive system.

This shift is most visible at the VCAP level. The discipline-based VCAPs validate deep technical expertise per domain. The role-based VCAPs - Administrator, Architect, and Support - validate how that knowledge is applied in practice, depending on your day-to-day responsibilities. Together, they form the foundation for the highest level in the program: the VMware Certified Distinguished Expert, or VCDX.

The path from VCAP to VCDX

The formal path to VCDX starts with a role-based VCP as the foundation. From there, candidates complete a set of advanced VCAP certifications - including at least one role-based VCAP and the VKS track. The final step is a live defense, a practical session where architectural insight, problem-solving capability, and real operational experience take center stage. This is not about ticking boxes. It is about proving that you can operate at the highest technical level in real-world VCF environments.

Next milestone: the role-based VCAPs

With all five discipline tracks completed, the focus now shifts to the three role-based VCAPs: Administrator (3V0-11.26), Architect (3V0-12.26), and Support (3V0-13.26). Broadcom has recently announced these as coming very soon - each following the same format of 60 questions over 135 minutes, with a passing score of 300 on a scaled system.

What makes these exams interesting is that they evaluate the same technical foundations from entirely different angles. The Administrator exam focuses on operational execution - lifecycle management, automation workflows, day-2 operations. The Architect exam focuses on design decisions - workload domain strategies, resilience patterns, capacity planning. The Support exam focuses on diagnostic methodology - root cause analysis, log interpretation, structured troubleshooting across the full VCF stack.

For anyone working hands-on with VCF environments, these three tracks represent a logical and valuable next step. They validate not just what you know, but how you apply it.

Why this matters

VCF adoption is accelerating - in sovereign cloud initiatives, in regulated industries, and in large enterprise environments looking for the combination of public cloud automation with full infrastructure control. Organizations need verifiable, role-specific expertise. The new VCAP structure delivers exactly that assurance.

For me personally, this is about more than credentials. Each exam builds the technical foundation needed to contribute meaningfully to the community, to deliver sharp troubleshooting sessions at events like VMUG Connect Amsterdam and Minneapolis, and ultimately to approach the VCDX defense with genuine depth across every relevant domain of the platform.

Next step: VCAP Administrator · Architect · Support → VCDX. Can't wait.

After delivering this session at both VMUG Connect Amsterdam and VMUG Connect Minneapolis, I can honestly say the response exceeded my expectations. The rooms were packed, the questions were sharp, and the feedback was overwhelmingly positive. It's clear that VCF troubleshooting is a topic that resonates deeply with the community right now.

What the session was all about

The goal was simple: move beyond theory and give attendees practical, real-world troubleshooting techniques they could take back to their environments the very next day. The session was built around four core areas.

Preventive Health Checks

Before you can troubleshoot, you need visibility. I walked through three essential tools for keeping your VCF environment healthy. The VCF Diagnostic Tool, a Python-based script that runs locally on your vCenter or SDDC Manager appliance and generates reports in TXT, LOG and JSON format. The VMware Health and Security Toolkit (HST), which gives you a comprehensive security assessment across your entire vSphere environment. And the VCF Build and Integrate Lifecycle Toolkit (BILT), which handles both greenfield validation and brownfield readiness checks before expansions or upgrades.

For post-deployment health monitoring, the SoS Utility remains one of the most powerful tools in the VCF admin's arsenal. Running individual checks like certificate health, connectivity health, NTP synchronization and services health gives you a clear picture of your environment's status at any point in time.

A Real-World Troubleshooting Example

This was the part of the session that generated the most discussion. I walked through an actual customer case — a shoutout to Alexander Bituev from ING Frankfurt for this one — where a workload domain creation failed with a frustratingly vague error in the Fleet Management UI.

The key lesson here was what I call the Golden Rule of VCF troubleshooting: the first error in the log is the root cause. Everything that follows is just noise. Using a simple grep command against the domainmanager.log file, or alternatively drilling into the SDDC Manager API via the built-in Developer Center Swagger UI, reveals the full error chain. In this case the nested error told the complete story: the ESXi host already had vSAN enabled, which blocked the workload domain deployment. The referenceToken shown in the Fleet Management UI is your bridge between the UI and the API — always use it.

New Troubleshooting Features in VCF Operations

VCF Operations has matured significantly and now offers a genuinely powerful set of troubleshooting capabilities. The Diagnostic Findings feature collects data from all VCF platform components every four hours and surfaces both active and historical findings. The Findings Catalog currently contains over 637 checks covering components like vCenter, ESXi, vSAN, NSX and VCF Automation.

The Troubleshooting Workbench is a personal favorite. It correlates events, property changes and anomalous metrics across your entire VCF stack in a single view, making it much faster to identify what changed and when. Combined with the Log Compare feature in VCF Operations for Logs 9.0, which lets you run multiple log queries side by side across different time periods, you have an incredibly powerful toolkit for root cause analysis.

The Storage Operations dashboard provides vSAN cluster health scores from 0 to 100, performance KPIs including IOPS, throughput and latency, and links directly to Broadcom KB articles for remediation. The Network Operations view gives you a holistic topology of your entire NSX environment including the new NSX VPC Dashboard with dropped packet monitoring.

Training and Certification

I also covered the VCF troubleshooting training landscape, which has been significantly expanded. The path runs from the foundational VCF Fundamentals for Technical Support course through the professional-level VCF Troubleshooting course with live lab options, all the way up to the advanced domain-specific playlists that lead to VCAP certifications in Storage, Automation, Operations, VKS and Networking. For those with their sights set even higher, the VCDX Distinguished Expert certification remains the ultimate destination.

The Community Response

Both in Amsterdam and Minneapolis the session sparked great conversations. Whether it was the Golden Rule for log analysis, the referenceToken trick for bridging the Fleet Management UI with the Developer Center API, or the new capabilities in VCF Operations, attendees left with concrete techniques they could apply immediately. That's exactly what VMUG sessions should deliver.

If you missed the session, the slides are available for download, and on SlideShare. 

What an incredible week it has been! This past Thursday, I had the pleasure of presenting at VMUG Connect Amsterdam, held at the iconic RAI Amsterdam. The energy in the room was fantastic, and it was truly invigorating to connect with so many engaged professionals from the VMware community.

My session — "VMware Cloud Foundation Troubleshooting: Real-World Scenarios and Solutions" — focused on practical approaches to maintaining and fixing VCF environments. We explored essential tools for performing preventive health checks on VCF 9, walked step-by-step through real-world troubleshooting examples, and discovered some of the latest troubleshooting features within VCF Operations.

The room was nearly full with around 60 attendees, and the feedback I received afterward was overwhelmingly positive. It is always rewarding to share lessons learned from the field — especially when the audience is so interactive and eager to discuss real-world applications. A big thank you to everyone who attended, asked questions, and shared their own experiences!

It was also wonderful to catch up with so many familiar faces, both from the Netherlands and abroad — including a good number of former students. To top off an already memorable week, I also passed my VCAP-Automation exam 🎉 And a comfortable stay at the Van der Valk Hotel at the Zuidas certainly didn't hurt either.

Next Stop: VMUG Connect Minneapolis 🇺🇸

If you missed the Amsterdam session, don't worry! In just three weeks, I will be delivering this presentation again at VMUG Connect Minneapolis. I am looking forward to bringing these real-world VCF troubleshooting scenarios and practical strategies to the US audience.

After the Minneapolis session, I will make the full presentation slide deck available for download right here on NTPRO.NL — so stay tuned if you want access to all the materials, tools, and references we covered.

Thank you again to the VMUG community for the continued support and engagement. See you in Minneapolis! 👊