Cisco 300-745 SDSI study materials
Cisco 300-745 SDSI study resources

Cisco 300-745 SDSI: Architecture, Components, and Deployment Models of Cisco Secure Workload

Cisco 300-745 SDSI · Work through your exam, one topic at a time.

All guide sections

Architecture, Components, and Deployment Models of Cisco Secure Workload

The Architecture, Components, and Deployment Models domain tests whether you can explain how Cisco Secure Workload collects telemetry, where policy is computed, and which deployment shape fits a given environment. Nearly every question reduces to one split: the control plane (controllers and the policy/analytics engine) versus the data plane (sensors and agents that see or block traffic).

Control plane components

  • Controller nodes run the UI, API, inventory, policy engine and analytics. Production clusters use three controllers so a quorum survives one node loss; one is leader, the others followers.
  • The datastore holds flow records, inventory snapshots and policy versions; flow retention is a sizing input, not an afterthought.
  • Controllers are never inline. Losing a controller degrades visibility and policy authoring, not existing host enforcement.

Data plane components

  • The software agent runs on the workload (Linux, Windows Server, Kubernetes DaemonSet) and reports 5-tuple flows plus process, user and container context.
  • Sensor nodes act as collection points for agents and for agentless feeds such as NetFlow/IPFIX and ERSPAN mirrors.
  • Enforcement is local (the agent programs the host firewall) or external (FMC-managed FTDs, ACI, load balancers, ISE/pxGrid security group tags).

Deployment models

SaaS: controllers are cloud-hosted and only metadata leaves your network. On-premises: a self-managed cluster on Cisco UCS or on ESXi/KVM, required when flow metadata cannot leave the estate. Hybrid: on-premises sensors with SaaS controllers. Multi-site clusters keep a site label per node so you can reason about where telemetry is stored and which sensor an agent reports to.

Worked example

500 Linux VMs across two data centres, no SPAN capacity, requirement to block per process. Agentless is disqualified (no enforcement, no process data), so choose an on-premises cluster with three controllers, at least one sensor node per site, and agents started in visibility mode before enforcement. SaaS controllers would also work if metadata export is permitted.

Traps that cost marks

  • Treating agents as part of the control plane; agents are data plane and optional when you go agentless.
  • Assuming SaaS means packet payloads are uploaded - it does not.
  • Assuming a two-controller cluster is highly available; quorum needs three.
  • Forgetting that external enforcement needs no agent on the workload at all.