For many VMware administrators, networking is the point where VMware Cloud Foundation starts to feel different.

Most of us entered the VMware world through vSphere. We became comfortable with ESX, vCenter, clusters, DRS, HA, vMotion, datastores and virtual machines. That was the world we knew. We could build clusters, troubleshoot hosts, move workloads, manage capacity and keep platforms running.

Then VMware Cloud Foundation brings NSX into the centre of the conversation.

Suddenly the language changes.

People start talking about Tier-0 Gateways, Tier-1 Gateways, Segments, Distributed Firewall, Edge Nodes, Transport Zones, VPCs, Transit Gateways, North-South traffic and East-West traffic.

At first, it can feel like a different discipline altogether.

But it is not.

NSX is not there to make networking complicated.

NSX exists because traditional data centre networking was not designed for the speed, automation and security model required by modern private cloud.

To understand NSX properly, we need to step back and look at the problem VMware was trying to solve.

Why Traditional Networking Became a Bottleneck

In a traditional VMware environment, the virtualisation team could build servers quickly.

A project team asks for five virtual machines. The VMware administrator creates the VMs, attaches them to port groups, allocates CPU and memory, connects storage, installs the operating system, and the compute side is largely complete.

But the application is not ready yet.

The team still needs VLANs.

They need firewall rules.

They need routing.

They may need load balancing.

They may need isolated networks for testing.

They may need connectivity between environments.

They may need security policies between application tiers.

This is where delivery slows down.

The VMware administrator can create the VM in minutes, but the network change may take days or weeks because the configuration often sits outside the virtualisation platform. It requires coordination with network teams, firewall teams, security teams and sometimes external providers.

This is not because those teams are slow.

It is because physical networking was built for stability and control, not rapid application delivery.

Cloud changed the expectation.

In AWS, Azure or Google Cloud, teams expect to create networks, subnets, routing, firewalls and isolated environments through software. Nobody raises a ticket to configure a physical switch every time a new application environment is required.

VMware needed to bring that same operating model into the private data centre.

That is the background to NSX.

What NSX Really Means

The simplest way to understand NSX is this:

NSX virtualises the network in the same way ESX virtualised compute.

Before ESX, an application usually depended on a physical server. If you needed another application environment, you often needed another server. ESX changed that model by abstracting compute from hardware. Virtual machines could run on shared physical infrastructure while still behaving like independent servers.

NSX applies the same idea to networking.

Before NSX, network services were strongly tied to physical infrastructure. VLANs lived on switches. Routing lived on routers. Firewalls lived on firewall appliances. Load balancing lived on load balancer appliances.

NSX abstracts those services into software.

That means networking becomes programmable.

Security becomes programmable.

Routing becomes programmable.

Firewalling becomes programmable.

This is the foundation of software-defined networking.

The physical network still matters. NSX does not remove the need for physical switches, uplinks, routing or resilient underlay design. What NSX does is reduce the dependency on physical change every time the application environment needs to evolve.

In a VMware Cloud Foundation environment, this becomes critical because VCF is designed to operate as a private cloud platform, not just a virtualisation estate.

Why NSX Is So Important in VMware Cloud Foundation

In older VMware environments, NSX was often seen as an optional product.

Some customers used it for micro-segmentation.

Some used it for overlay networking.

Some used it for security.

Some did not use it at all.

In VMware Cloud Foundation, that mindset changes.

NSX becomes part of the platform architecture.

VCF is trying to deliver a cloud operating model. A cloud operating model needs automated networking, consistent security, workload mobility, tenant isolation and predictable lifecycle management.

Without software-defined networking, VCF would still depend heavily on manual physical network change. That would break the promise of cloud-like operations.

This is why NSX is so central to VCF.

vCenter gives you the compute control plane.

vSAN gives you software-defined storage.

SDDC Manager gives you lifecycle and domain management.

NSX gives you the network and security fabric.

Once you understand that, NSX stops looking like a separate product and starts looking like a core layer of the private cloud.

The Three Planes of NSX

One of the most important concepts to understand in NSX is the idea of planes.

This is common in networking architecture, but it can feel abstract at first.

NSX is easier to understand when you separate it into three areas: the management plane, the control plane and the data plane.

Each plane has a different job.

If you understand which plane is responsible for which job, troubleshooting becomes much easier.

The Management Plane

The management plane is where configuration is created and stored.

When an administrator logs into NSX Manager and creates a Segment, configures a Gateway, defines a firewall policy, creates a VPC or changes routing configuration, they are working with the management plane.

The management plane is about intent.

It records what you want the network to look like.

For example, you might say:

I want a Segment called App-Web.

I want it connected to a Tier-1 Gateway.

I want that Tier-1 Gateway connected to a Tier-0 Gateway.

I want a firewall rule that allows web traffic from the internet to the web tier.

I want database traffic only from the application tier.

The management plane stores those decisions.

In traditional networking, these decisions might be spread across multiple switches, routers and firewalls. In NSX, the configuration is centralised and policy-driven.

NSX Manager is the most visible part of the management plane. It provides the interface and API through which administrators and automation tools define the desired state of the network.

In VCF environments, some NSX capabilities are also surfaced through vCenter and VMware Cloud Foundation workflows. This is part of VMware’s broader direction, making private cloud operations more integrated and less fragmented.

For the VCF exam, it is important to remember that the management plane is not where packets are forwarded. It is where configuration is defined.

That distinction matters.

If an administrator creates the wrong policy, that is a management plane problem.

If the policy is correct but not distributed properly, that may involve the control plane.

If everything is configured correctly but traffic still does not flow, the issue may be in the data plane, routing, firewall enforcement or the underlying physical network.

The Control Plane

The control plane is responsible for distributing network state and making forwarding information available across the NSX environment.

If the management plane says what the network should look like, the control plane helps the environment understand how to make that happen.

It deals with questions such as:

Where does this workload live?

Which ESX host is running this virtual machine?

Which routes should be known?

Which tunnel endpoints are involved?

Which Gateway should handle this traffic?

Which distributed components need updated forwarding information?

The control plane is not the user interface.

It is also not the place where the actual application traffic is forwarded.

Its job is to distribute intelligence.

A good analogy is air traffic control.

The management plane decides that a new airport route exists.

The control plane ensures that the relevant towers and systems know how flights should be directed.

The data plane is the actual aircraft moving passengers.

In NSX, the control plane is what allows a distributed software network to behave consistently across many ESX hosts and Edge Nodes.

This is extremely important because modern VCF environments are distributed by design. Workloads may live across multiple hosts, clusters or workload domains. The network must understand where those workloads are and how traffic should reach them.

For the exam, remember that the control plane is about network state, route distribution and communication between NSX components. It is the layer that helps translate desired configuration into usable network behaviour.

The Data Plane

The data plane is where traffic actually moves.

When a virtual machine sends traffic to another virtual machine, that is data plane traffic.

When a workload reaches an external network, that is data plane traffic.

When a packet is routed, switched, filtered or forwarded, the data plane is involved.

In NSX, the data plane exists across ESX hosts and NSX Edge Nodes.

This is one of the most powerful parts of the architecture.

Instead of forcing all traffic through a central physical appliance, NSX can perform many services in a distributed way. Routing and firewalling can happen close to the workload, directly in the hypervisor.

This is why NSX scales well.

Traffic does not always need to hairpin through a central device. East-West traffic between workloads can often be handled locally and efficiently.

For troubleshooting, the data plane is where you ask practical questions.

Can the VM reach its default gateway?

Is the Segment connected correctly?

Is the distributed firewall allowing the traffic?

Is routing working between Tier-1 and Tier-0?

Is the Edge Node forwarding North-South traffic?

Is the physical network receiving the advertised routes?

This is where architecture becomes real.

Segments, The New Starting Point for Workload Networking

When you connect a virtual machine to a network in NSX, you usually connect it to a Segment.

A Segment is a logical Layer 2 network.

For VMware administrators, the easiest comparison is a port group or VLAN-backed network, but that comparison only goes so far.

A traditional VLAN depends on the physical network.

The VLAN must exist on the physical switch.

The trunk must carry the VLAN.

The upstream network must understand the VLAN.

A Segment, by contrast, is created in software.

The physical network still provides transport, but the logical network exists inside NSX. This allows administrators to create application networks quickly without waiting for physical switch configuration every time.

For example, you might create a Segment for web servers, another for application servers and another for database servers. Each Segment provides network separation. Each Segment can have its own security rules and connectivity model.

This is the beginning of cloud-like networking.

Instead of asking the network team to build every network manually, platform teams can define logical networks as part of the environment.

Tier-1 Gateways, The Local Gateway for Applications

Once workloads are connected to Segments, they usually need routing.

This is where Gateways come in.

A Tier-1 Gateway is typically the first routing point for application networks.

Think of Tier-1 as the local router for a group of application Segments.

For example, an application may have a web Segment, an app Segment and a database Segment. Those Segments may all connect to the same Tier-1 Gateway. The Tier-1 Gateway provides routing between those networks and connects them upward toward the rest of the environment.

This gives administrators a clean way to organise applications.

A development environment can have its own Tier-1 Gateway.

A production application can have its own Tier-1 Gateway.

A DMZ environment can have its own Tier-1 Gateway.

This design creates separation and control.

The Tier-1 Gateway can also be associated with services such as NAT, load balancing and firewalling depending on design and licensing. From an exam point of view, the most important idea is that Tier-1 usually sits close to the workload and connects application networks upward toward Tier-0.

Tier-0 Gateways, The Bridge to the Outside World

The Tier-0 Gateway sits above the Tier-1 Gateway.

If Tier-1 is close to the application, Tier-0 is close to the physical network.

Tier-0 provides North-South connectivity. That means traffic entering or leaving the NSX environment usually passes through Tier-0.

A Tier-0 Gateway commonly connects to the physical network using dynamic routing such as BGP. It can advertise routes from NSX to the physical network and learn routes from the physical network into NSX.

This is one of the most important NSX concepts for VCF administrators.

Traffic from a VM to the internet may follow this path:

The VM sends traffic to its Segment.

The Segment connects to a Tier-1 Gateway.

The Tier-1 Gateway forwards upward to Tier-0.

Tier-0 forwards toward the physical network through Edge Nodes.

The physical network then routes the traffic to the next destination.

This hierarchy is central to NSX.

If you understand Segment to Tier-1 to Tier-0 to physical network, you understand the foundation of NSX routing.

NSX Edge Nodes, Where Centralised Services Live

When people first learn NSX, they often ask where Tier-0 and Tier-1 Gateways actually run.

The answer depends on the type of service.

Some routing is distributed and happens on the ESX hosts.

Some services require Edge Nodes.

An NSX Edge Node is an appliance that provides centralised networking services. Edge Nodes are commonly used for North-South routing, NAT, VPN, load balancing and connectivity to the physical network.

In a production design, Edge Nodes are usually deployed in clusters for resilience.

This matters because not every NSX function is distributed across all ESX hosts. Some services need a centralised service router component, and that is where Edge Nodes become important.

For the exam and for real environments, always ask:

Is this traffic handled in a distributed way on the ESX host, or does it need to go through an Edge Node?

That question often leads you to the correct troubleshooting path.

Distributed Routing, Why NSX Does Not Behave Like Traditional Networks

Distributed routing is one of the most powerful ideas in NSX.

In traditional networking, routing usually happens on a physical router or Layer 3 switch. Traffic must travel to that device before it can be routed.

NSX changes this model.

With distributed routing, routing can happen directly in the hypervisor, close to the virtual machine.

This is especially useful for East-West traffic, which is traffic moving between workloads inside the data centre.

Imagine a web server and an application server running on the same ESX host but on different logical networks. In a traditional model, traffic might leave the host, reach a router, then come back. That is inefficient.

With distributed routing, NSX can route that traffic locally.

This reduces latency.

It reduces unnecessary network hops.

It improves scale.

It also means the network becomes much more closely tied to the hypervisor.

For vSphere administrators, this is the mental shift.

The ESX host is no longer just running virtual machines.

It is participating in the network fabric.

Distributed Firewall, Security at the Workload Level

Traditional firewalls protect the edge of the network.

They are very good at inspecting traffic entering or leaving an environment.

But modern threats do not always stay at the edge.

Once an attacker compromises one system, they often try to move laterally. They move from server to server, from application tier to database tier, from user subnet to management subnet.

This lateral movement is difficult to control with only perimeter firewalls.

NSX Distributed Firewall solves this by placing firewall enforcement close to the workload, inside the hypervisor.

Instead of sending traffic to a central firewall, policy can be enforced at the virtual NIC level.

This is a major architectural shift.

Every workload can have its own security boundary.

A web server can be allowed to talk to an application server on a specific port.

The application server can be allowed to talk to a database server.

Everything else can be denied.

This is the foundation of micro-segmentation.

Micro-Segmentation, Security Designed for Modern Threats

Micro-segmentation is often explained badly.

It is not simply “more firewall rules.”

It is the practice of reducing unnecessary communication between workloads.

The old data centre model often trusted everything inside the network. Once traffic was internal, it was often allowed more freely.

That model no longer works.

Modern security assumes that compromise is possible. The goal is to reduce the blast radius.

If one server is compromised, it should not automatically be able to talk to every other server.

Micro-segmentation allows organisations to define security based on application behaviour rather than network location alone.

This is why NSX became so important to VMware’s security story.

Security is no longer only at the perimeter.

Security follows the workload.

For VCF administrators, this matters because networking and security are now joined together. You cannot fully understand NSX networking without understanding distributed security.

North-South and East-West Traffic

Two terms appear constantly in NSX conversations: North-South and East-West.

North-South traffic is traffic entering or leaving the environment.

A user accessing an application from outside the data centre is North-South traffic.

A VM reaching the internet is North-South traffic.

An application calling an external API is North-South traffic.

This traffic usually involves Tier-0, Edge Nodes and the physical network.

East-West traffic is traffic that stays inside the data centre.

A web server talking to an application server is East-West traffic.

An application server talking to a database server is East-West traffic.

A Kubernetes node talking to another Kubernetes node is East-West traffic.

This traffic often benefits from distributed routing and distributed firewalling.

Understanding the difference between North-South and East-West traffic helps you troubleshoot faster.

If the issue is external access, think Tier-0, Edge Nodes, BGP, NAT, upstream routing and physical connectivity.

If the issue is workload-to-workload traffic, think Segments, Tier-1, distributed routing, distributed firewall and local workload connectivity.

VPCs in VMware Cloud Foundation 9.1

VCF 9.1 continues VMware’s move toward a more cloud-like operating model, and one of the most important concepts in that direction is the Virtual Private Cloud, or VPC.

Many people already know the term from AWS.

A VPC is an isolated logical network environment. It gives a team, tenant or application group its own private networking space inside a larger shared platform.

In a traditional enterprise environment, creating this level of isolation could involve multiple VLANs, firewall contexts, routing changes and manual coordination.

With VPCs, the goal is to make that experience simpler and more self-service.

A platform team can provide isolated network environments to application teams without giving each team direct control over the underlying infrastructure.

This is important for large enterprises, service providers and internal platform teams.

It allows VCF to behave more like a private cloud platform rather than a traditional virtualisation environment.

In simple terms, VPCs help VMware Cloud Foundation move from “the infrastructure team builds everything manually” toward “the platform provides controlled self-service.”

Transit Gateways, Connecting VPCs Without Creating Chaos

As soon as you create multiple VPCs, another question appears.

How do they communicate?

If every VPC connects directly to every other VPC, the design quickly becomes messy.

This is where Transit Gateway concepts become useful.

A Transit Gateway acts as a central routing point between multiple isolated environments.

Instead of building many individual connections, traffic can pass through a central routing hub.

This simplifies connectivity.

It improves control.

It makes routing easier to manage at scale.

For VCF 9.1, this matters because VMware is strengthening the private cloud networking model. VPCs provide isolated environments. Transit Gateway capabilities help connect those environments in a controlled way.

For administrators, the key is not to memorise terminology.

The key is to understand the design pattern.

Isolation is useful.

Connectivity is also required.

Transit Gateway helps balance both.

How to Troubleshoot NSX Like an Architect

Many administrators troubleshoot NSX by jumping straight into the interface and clicking around.

That usually wastes time.

A better method is to follow the traffic.

Start with the workload.

Can the VM reach its own default gateway?

If not, check the VM network adapter, Segment connection, IP configuration and local firewall.

If the VM can reach the gateway, check whether it can reach another workload on the same Segment.

If same-Segment traffic works but routed traffic fails, look at Tier-1 connectivity and distributed routing.

If internal routing works but external access fails, move upward to Tier-0, Edge Nodes, NAT, BGP and the physical network.

If routing looks correct but traffic still fails, check the Distributed Firewall and Gateway Firewall policies.

If everything looks correct inside NSX, do not forget DNS, upstream routing, physical switch configuration and external firewalls.

The best NSX administrators do not guess.

They follow the packet.

That mindset is also extremely useful for the VCF exam.

What the VCF Exam Is Really Looking For

The VCF Admin exam is not trying to turn every VMware administrator into a network architect.

But it does expect you to understand how networking works inside a modern private cloud platform.

You should understand what NSX does.

You should understand why Segments exist.

You should understand why Tier-1 and Tier-0 Gateways are separate.

You should understand when Edge Nodes are involved.

You should understand the difference between distributed and centralised services.

You should understand why distributed firewalling matters.

You should understand how VPCs support cloud-like networking in VCF 9.1.

Most importantly, you should understand traffic flow.

Because once you understand traffic flow, the terminology becomes easier.

NSX is not just another networking product.

It is the layer that allows VMware Cloud Foundation to behave like a true private cloud platform.

In Part 4, we will move into storage and vSAN, looking at how VMware Cloud Foundation delivers software-defined storage, why storage policies matter, how stretched clusters fit into the design, and what administrators should understand before sitting the VCF 9 exam.

Understanding vCenter, ESX Communication and the Hidden Services That Run VMware Cloud Foundation

Most VMware administrators spend years working inside vCenter.

They create virtual machines.

Build clusters.

Configure DRS.

Manage HA.

Perform vMotion migrations.

Monitor workloads.

Yet surprisingly few administrators fully understand what happens behind the scenes.

When you click “Power On Virtual Machine” inside vCenter, what actually happens?

When you add an ESX host to vCenter, how does communication work?

When authentication fails, where do you begin troubleshooting?

Understanding these concepts will not only help you pass the VCF certification exam, but will also make you significantly more effective when troubleshooting production environments.

Understanding vCenter’s Real Purpose

Many administrators think of vCenter as a graphical interface.

In reality, vCenter is the orchestration engine of the compute platform.

Without vCenter, ESX hosts still run.

Virtual machines continue running.

Applications continue serving users.

But many advanced capabilities disappear.

There is no central inventory.

No Distributed Resource Scheduler.

No vMotion orchestration.

No centralised permissions.

No cluster-level management.

No lifecycle operations.

vCenter acts as the management plane responsible for coordinating all of these services.

In VCF environments, this role becomes even more important because vCenter is one of the foundational services that SDDC Manager relies upon.

A useful way to think about it is this:

ESX runs workloads.

vCenter coordinates workloads.

SDDC Manager coordinates the platform.

Each layer has a different responsibility.

Understanding that hierarchy is essential.

The Hidden Services Behind Every Click

One of the most common certification questions involves understanding the communication path between vCenter and ESX.

This is not something most administrators think about every day.

Yet when something breaks, understanding these services becomes incredibly valuable.

Three services matter more than any others:

hostd

vpxa

vpxd

If you understand these three services, you understand most of VMware’s management architecture.

hostd – The Brain of the ESX Host

Every ESX host runs a service called hostd.

Think of hostd as the local management service for the host.

It knows:

Which virtual machines exist.

Which datastores are mounted.

Which networks are available.

Which services are running.

Which hardware resources are available.

Even if vCenter completely disappears, hostd continues operating.

This is why you can connect directly to an ESX host using the VMware Host Client.

The Host Client communicates directly with hostd.

This is an important exam concept.

Many candidates incorrectly assume vCenter is required for host administration.

It is not.

vCenter simplifies administration.

hostd performs administration.

vpxa – The Translator

When an ESX host is added to vCenter, another service enters the picture.

This service is called vpxa.

Think of vpxa as a translator.

vCenter does not communicate directly with hostd.

Instead:

vCenter communicates with vpxa.

vpxa communicates with hostd.

vpxa acts as the intermediary.

This architecture allows VMware to maintain consistent communication between the management platform and individual hosts.

When vCenter needs to power on a virtual machine, migrate a workload, or change a configuration, the request flows through vpxa before reaching hostd.

Many troubleshooting scenarios ultimately come down to failures in this communication chain.

vpxd – The vCenter Engine

Running inside vCenter itself is a service called vpxd.

This is effectively the heart of vCenter.

vpxd processes administrative requests.

It coordinates inventory updates.

It manages cluster operations.

It orchestrates automation workflows.

It communicates with ESX hosts through vpxa.

When vCenter becomes slow, unstable, or unresponsive, vpxd is often one of the first services administrators investigate.

From an exam perspective, remember:

hostd lives on ESX.

vpxa lives on ESX.

vpxd lives on vCenter.

If you can remember that relationship, you will solve many architecture questions correctly.

Why Certificates Matter More Than Most Administrators Realise

Certificates appear repeatedly throughout the VCF blueprint.

That is not accidental.

Certificates underpin trust across the entire platform.

Every component communicates securely.

vCenter trusts ESX.

ESX trusts vCenter.

SDDC Manager trusts vCenter.

NSX trusts SDDC Manager.

Identity services trust certificates.

Automation services trust certificates.

Without certificates, secure communication breaks.

This becomes especially important during VCF upgrades and lifecycle operations.

Many upgrade failures can ultimately be traced back to certificate problems.

Expired certificates.

Incorrect common names.

Certificate authority issues.

Trust chain failures.

One of the best habits a VCF administrator can develop is proactively monitoring certificate health before issues occur.

Single Sign-On: The Foundation of Identity

Most administrators log into vCenter every day without thinking about what happens behind the scenes.

They enter a username.

They enter a password.

Access is granted.

Simple.

Behind the scenes, however, VMware’s identity architecture is doing considerable work.

Single Sign-On exists to centralise authentication across the platform.

Instead of maintaining separate credentials for every component, administrators authenticate once and gain access based on assigned permissions.

This becomes especially important in larger environments.

Imagine managing:

Multiple vCenters.

Multiple workload domains.

Multiple NSX instances.

Multiple operational teams.

Without centralised identity management, administration quickly becomes chaotic.

Enhanced Linked Mode

Historically, organisations deployed multiple vCenter instances.

This created management challenges.

Enhanced Linked Mode helps solve this problem.

Multiple vCenter instances can appear through a unified interface.

Administrators gain visibility across environments without constantly changing connections.

For enterprises running large VMware estates, this capability significantly simplifies operations.

From a certification perspective, understand why Enhanced Linked Mode exists.

The exam often rewards architectural understanding over memorisation.

Identity Broker and the Future of Authentication

Identity Broker represents VMware’s move toward modern identity integration.

Traditional Active Directory authentication remains important.

But enterprises increasingly require:

Federated authentication.

Multi-factor authentication.

External identity providers.

Cloud-based identity services.

Identity Broker provides the abstraction layer that allows VMware Cloud Foundation to integrate with modern identity platforms.

As organisations adopt zero-trust security models, this component becomes increasingly important.

Expect Identity Broker to become more prominent in future VCF releases.

What Changed in VCF 9 and 9.1 for Identity and Management?

One of VMware’s major goals with VCF 9 is simplifying operations.

Historically, administrators spent considerable time maintaining infrastructure components individually.

VCF 9 moves toward platform-centric operations.

Identity services become more integrated.

Certificate management becomes more automated.

Lifecycle management becomes more consistent.

Authentication becomes more unified.

VCF 9.1 continues this trend by reducing operational complexity and increasing automation throughout the management stack.

The direction is clear.

Less manual administration.

More platform automation.

More consistency.

More resilience.

What VMware Is Really Testing

Most candidates study vCenter features.

The exam often tests architecture.

There is a difference.

Memorisation asks:

“What does this feature do?”

Understanding asks:

“Why does this feature exist?”

VMware increasingly rewards administrators who understand the platform.

Why does hostd exist?

Why does vpxa exist?

Why does vCenter exist?

Why does SSO exist?

Why does Identity Broker exist?

Why are certificates critical?

When you understand those answers, the architecture becomes logical.

And once the architecture becomes logical, passing the exam becomes much easier.

In Part 3, we move into one of the most important domains in modern VMware Cloud Foundation:

Networking.

We will explore vSphere Standard Switches, Distributed Switches, NSX Segments, Tier-0 Gateways, Tier-1 Gateways, VPCs, Transit Gateways, Micro-Segmentation, and the networking architecture that powers modern private cloud platforms.

Most VMware administrators start their VCF journey by asking the wrong question.

“What do I need to memorise to pass the exam?”

The better question is:

“What problem was VMware Cloud Foundation created to solve?”

Once you understand the answer, the certification becomes dramatically easier.

More importantly, you become a better administrator.

Because VMware Cloud Foundation is not simply another VMware product.

It is VMware’s attempt to solve one of the biggest problems facing modern infrastructure teams:

Complexity.

The Problem VMware Is Trying to Solve

Think back to a traditional VMware environment.

You might have:

A vCenter Server.

Several ESX clusters.

A SAN managed by the storage team.

Physical networking managed by the network team.

Firewalls managed by the security team.

Monitoring tools managed by operations.

Automation tools deployed separately.

Backups configured independently.

Every component works.

But every component also has its own lifecycle.

Its own upgrade path.

Its own support matrix.

Its own dependencies.

Its own operational procedures.

Over time these environments become increasingly difficult to maintain.

Upgrading vSphere becomes a project.

Upgrading networking becomes another project.

Upgrading storage becomes another project.

Soon the infrastructure team spends more time maintaining infrastructure than delivering value.

VMware looked at this challenge and asked:

“What if the entire private cloud operated as a single platform?”

That idea became VMware Cloud Foundation.

Understanding VMware Cloud Foundation

Many people describe VMware Cloud Foundation as:

vSphere + vSAN + NSX + SDDC Manager

Technically that is correct.

But it misses the real value.

VMware Cloud Foundation is an operating platform for private cloud.

Just as Azure operates public cloud infrastructure.

Just as AWS operates public cloud infrastructure.

VCF provides a consistent operating model for on-premises infrastructure.

The platform combines compute, networking, storage, security, automation, operations, lifecycle management, identity management, and Kubernetes into a single architecture.

This is the first mindset shift required for the certification exam.

Do not think in products.

Think in platforms.

The exam increasingly tests how components interact rather than how individual features operate.

Why vCenter Still Matters

One misconception I frequently hear is:

“VCF replaces vCenter.”

It does not.

In fact, vCenter remains one of the most important components in the entire platform.

VMware vCenter continues to act as the control plane for compute operations.

Every ESX host ultimately reports into vCenter.

Every virtual machine is managed through vCenter.

Every cluster, datastore, resource pool, DRS recommendation, HA action and vMotion operation flows through vCenter.

Even in VCF 9, vCenter remains the heart of compute management.

The difference is that vCenter is no longer expected to manage the entire private cloud lifecycle.

That responsibility now belongs elsewhere.

Enter SDDC Manager

This is where many certification candidates get confused.

They know vCenter.

They understand ESX.

But they struggle to understand why VMware introduced SDDC Manager.

The answer is simple.

vCenter manages infrastructure resources.

SDDC Manager manages the platform.

That distinction is incredibly important.

When VMware Cloud Foundation performs:

Certificate management

Password management

Domain deployment

Lifecycle management

Fleet management

Platform upgrades

Workload domain operations

These activities are orchestrated through SDDC Manager.

Think of SDDC Manager as the cloud operating system.

Think of vCenter as the compute management plane.

Understanding this relationship immediately makes a large portion of the VCF architecture easier to understand.

What Changed in VCF 9?

VCF 9 represented one of the biggest architectural shifts VMware has made in years.

Historically, VMware environments often felt like collections of products.

VCF 9 moved aggressively toward platform integration.

The focus shifted toward:

Unified operations

Fleet-level lifecycle management

Kubernetes integration

AI-ready infrastructure

Security by default

Private cloud as a service

Infrastructure teams increasingly want public-cloud-like operations without losing control of data.

VCF 9 was VMware’s answer to that challenge.

The result is a platform that treats virtual machines, Kubernetes workloads, AI workloads, networking, storage, and security as first-class citizens inside a unified private cloud architecture.

Why NSX Became So Important

Many VMware administrators have spent years focusing primarily on vSphere.

For the VCF exam, that approach can become a problem.

Because modern VMware Cloud Foundation is built around NSX.

In traditional environments, networking often relied heavily on physical infrastructure.

VLANs.

Firewalls.

Routing.

Load balancing.

Security policies.

Much of this was configured outside the VMware stack.

VCF changes that approach.

NSX brings networking into software.

The network becomes programmable.

Security becomes programmable.

Routing becomes programmable.

Load balancing becomes programmable.

This shift is one of the most important concepts in the entire VCF architecture.

Understanding NSX is no longer optional.

It is foundational.

When you deploy a workload domain today, networking is no longer simply “connected.”

It becomes an integrated part of the cloud platform itself.

This is why so many exam objectives focus on troubleshooting NSX gateways, routing, DHCP, VPN services, VPCs, and network operations.

VMware expects administrators to understand how the software-defined network behaves.

Not just how virtual machines connect to it.

What Is New in VCF 9.1?

VCF 9.1 is not a complete redesign.

It is an optimisation release.

VCF 9 introduced the architecture.

VCF 9.1 improves how that architecture operates at scale.

One major improvement is around operational efficiency.

VMware enhanced NVMe Memory Tiering, allowing hot data to remain in DRAM while colder pages move intelligently to NVMe storage. This improves memory efficiency and reduces infrastructure costs without changing how applications behave.

For administrators studying the exam, this matters because VMware continues pushing toward software-defined infrastructure where hardware resources are utilised more efficiently.

VCF 9.1 also introduces significant improvements around Kubernetes scalability.

Supervisors can support dramatically larger Kubernetes deployments, allowing platform teams to manage both containerised and traditional workloads using the same operational model.

Another area receiving major investment is networking.

VCF 9.1 expands VPC capabilities, transit gateway functionality, IP address management, and multi-site connectivity options directly through vCenter and NSX.

This is important because VMware is positioning VCF not simply as a virtualisation platform, but as a complete private cloud platform.

The networking layer is becoming increasingly intelligent and increasingly automated.

vCenter in VCF 9.1

Even vCenter receives important improvements.

One particularly useful enhancement is the ability to resize vCenter resources through a simple API-driven process rather than requiring more complex operational procedures.

This may sound like a small feature.

But it reflects VMware’s broader strategy.

Reduce operational friction.

Reduce manual administration.

Increase automation.

The same philosophy appears throughout VCF 9.1.

The Most Important Lesson for Exam Candidates

If there is one lesson I would give every VCF certification candidate, it is this:

Stop studying individual products.

Start studying the platform.

Understand how:

ESX supports vCenter.

vCenter supports workload operations.

NSX provides networking.

vSAN provides storage.

SDDC Manager provides lifecycle management.

VCF Operations provides observability.

Identity Broker provides authentication.

VCF Automation provides self-service consumption.

When you understand those relationships, the blueprint begins to make sense.

And when the blueprint makes sense, the exam becomes far less intimidating.

Because VMware is not testing whether you can memorise menu options.

They are testing whether you understand how a modern private cloud platform operates.

That understanding is what ultimately separates a VMware administrator from a VMware Cloud Foundation administrator.

Technology never stands still.

As infrastructure professionals, we are constantly learning, adapting, and evolving alongside the platforms we support.

I’m pleased to share that I have successfully achieved the VMware Certified Professional (VCP) – VMware Cloud Foundation Administrator certification. This certification validates my knowledge and practical understanding of VMware Cloud Foundation, the platform that is rapidly becoming the foundation of modern private cloud infrastructure.

Why VMware Cloud Foundation Matters

Over the past few years, organisations have faced increasing pressure to modernise their infrastructure while maintaining security, resilience, operational efficiency, and control over their data.

VMware Cloud Foundation brings together the core building blocks required to deliver a modern private cloud platform:

• vSphere for compute virtualisation

• vSAN for software-defined storage

• NSX for networking and security

• SDDC Manager for lifecycle management and automation

Rather than managing these components independently, VMware Cloud Foundation provides an integrated platform that simplifies deployment, operations, upgrades, and lifecycle management.

For many organisations, VMware Cloud Foundation is becoming the strategic platform for private cloud transformation.

Why I Pursued This Certification

My career has been built around enterprise infrastructure, virtualisation, cloud technologies, and platform operations.

Having worked across large-scale VMware environments, including multi-site estates, private cloud platforms, and infrastructure modernisation programmes, I wanted to deepen my expertise in the latest VMware Cloud Foundation architecture and operational model.

This certification provided an excellent opportunity to strengthen my understanding of:

• VMware Cloud Foundation architecture

• Management and workload domains

• SDDC Manager operations

• Lifecycle management

• Storage and networking integration

• Security and operational best practices

• Private cloud design principles

As organisations continue their journey toward private cloud and hybrid cloud strategies, these skills are becoming increasingly valuable.

What I Learned

One of the most valuable aspects of studying for the VMware Cloud Foundation Administrator certification was understanding how all the platform components work together as a single integrated solution.

The certification goes beyond individual products and focuses on operating VMware Cloud Foundation as a complete private cloud platform.

Key learning areas included:

• Platform architecture and design

• Deployment methodologies

• Lifecycle management processes

• Monitoring and troubleshooting

• Security and governance

• Operational readiness

• Day-to-day administration

These are all critical areas for organisations running production VMware Cloud Foundation environments.

Looking Ahead

This certification is not the destination, it is another step in the journey.

My focus now is continuing to expand my expertise in:

• VMware Cloud Foundation 9

• Private cloud transformation

• Infrastructure modernisation

• Automation and operational excellence

• AI-ready infrastructure

• Cloud operating models

I am particularly interested in helping organisations plan and execute their transition to modern private cloud platforms while ensuring operational simplicity and long-term business value.

Thank You

A huge thank you to the VMware community, fellow vExperts, customers, colleagues, and technical professionals who continue to share knowledge and support one another.

The VMware community has always been one of the strongest technology communities in the industry, and I am grateful to be part of it.

Learning never stops.

Onwards to the next challenge.

#VMware #VMwareCloudFoundation #VCF #VCP #PrivateCloud #CloudInfrastructure #vExpert #Virtualization #Infrastructure #CloudComputing #DigitalTransformation