Cisco Secure Workload Installation, Initialization, and Cluster Management
This domain tests the operational steps that turn an appliance image into a working Secure Workload cluster, plus the day-two tasks the exam expects: scale-out, upgrade, backup, and health monitoring.
Pre-flight
- Time: every node needs reachable, synchronised NTP. Clock skew breaks cluster formation and certificate validation before you notice anything else.
- Name resolution: unique hostnames with forward and reverse DNS for all controller and sensor nodes.
- Certificates: replace self-signed certificates with CA-signed ones if the UI must be trusted by browsers; install the full chain, not just the leaf.
- Addressing: plan a stable cluster VIP for UI/API, a separate agent-facing address on sensors, and management versus data interfaces. Node IP addresses must not change after the cluster is formed.
Install and initialize
- Deploy the appliance image on Cisco UCS through CIMC, or as a VM on ESXi/KVM using the documented resource profile.
- Bootstrap the first controller with the cluster definition: site name, VIP, node list, and the registration credentials peers and agents will use.
- Join the remaining controllers and the sensor nodes; the leader distributes configuration to the rest.
- First-run tasks: apply the license, configure authentication (local, LDAP, or SAML SSO), set syslog/mail, and name the root scope sensibly because every later scope hangs beneath it.
- Point agents at the agent-facing address and confirm inventory populates before authoring any policy.
Day-two management
- Scale out by adding sensor nodes for collection capacity and controllers for scale/tenancy; keep three controllers for quorum.
- Upgrade through the UI node by node: controllers first with a health check between each, then sensors, then agents (auto-upgrade policy or manual per platform).
- Back up configuration to an external SCP/FTP target on a schedule and test the restore. The backup carries configuration, not historical flow data.
Worked example
A three-controller, three-sensor cluster needs a version upgrade. Order: take a configuration backup; verify cluster health is green; upgrade follower controllers one at a time, confirming quorum after each; upgrade the leader last (a leader change is expected); upgrade sensor nodes one at a time so collection continues; then roll agents. Upgrading all controllers simultaneously destroys quorum and the UI stops serving.
Traps
- Re-imaging a node to change its role instead of planning controller/sensor roles up front.
- Forgetting that agent version must be compatible with the controller version you upgraded to.
- Debugging "cluster join failed" caused by duplicate hostnames or unsynchronised clocks.