Cisco 300-745 SDSI common mistakes
Cisco 300-745 SDSI · Understand the traps and how to avoid them.
Treating the Cisco Secure Workload (formerly Tetration) sensor as a single agent type and assuming every workload runs the same Deep Visibility agent, then answering install and scope questions as if agentless and agent-based collection were interchangeable.
Candidates memorize 'install the agent' as a single step and never internalize that Secure Workload supports multiple sensor types (deep visibility host agents, agentless enforcement/visibility via network fabric, and flow-based ingestion), each with different prerequisites, OS support, and enforcement capability. Exam items deliberately probe which sensor can enforce versus only observe.
What to do instead
Build a comparison table of sensor types: host agent (full process/package visibility and enforcement), agentless enforcement through supported switches/fabric, and flow ingestion (visibility only, no enforcement). For each, note prerequisites (kernel/OS matrix, CPU/RAM, network reachability to the cluster), what telemetry it produces, and whether it can enforce. Re-answer any install or scope question by first naming the sensor type.
Confusing Secure Workload policy objects - treating a 'workspace' as the enforcement unit and an 'application scope' (scope) as just a folder, or assuming a policy is enforced globally once published rather than being bound to a scope and a specific enforcement point.
The product has a layered model: inventory (workloads, labels, tags), application scopes that group workloads by label queries, workspaces that define the policy intent within a scope, and enforcement that is pushed to specific agents or fabric points. Candidates collapse these layers and then pick wrong answers about where a rule takes effect.
What to do instead
Memorize the hierarchy and the direction of flow: labels/tags on workloads → scope (label-based query) → workspace (policy definition, allow-list intent) → published policy → enforcement point (agent or fabric) that receives it. Practice questions by asking 'what object is being created?' and 'which enforcement point receives it?' before reading the answer options.
Assuming Secure Workload policy is default-deny from day one, or conversely that discovery mode blocks traffic; candidates misstate what happens during the 'discovery' versus 'enforcement' phases of the policy lifecycle.
The lifecycle is discovery → policy generation → simulation/analysis → enforcement, and the platform's core value proposition is that it learns flows before enforcing. Candidates who skip the lifecycle memorize 'it's a segmentation tool' and then guess incorrectly about whether an unclassified flow is allowed or dropped at each stage.
What to do instead
Learn the lifecycle as a sequence with explicit states: flows are observed and grouped into clusters, policy is generated as allow-list intent, you can simulate impact before enforcing, and only after enforcement does the default-deny behavior apply to flows outside the allow-list. For each exam scenario, identify the current lifecycle stage first, then reason about the expected traffic outcome.
Mixing up Application Dependency Mapping (ADM) outputs with raw flow logs - assuming ADM shows individual packets or that it requires enforcement enabled, or failing to recognize that ADM clusters are built from observed flows and labels and must be reviewed/curated.
ADM is a modeling feature that consumes flow telemetry and produces dependency maps and policy suggestions. Candidates conflate it with packet capture or with the policy itself, so they misjudge which data source feeds ADM and what actions (merge, split, relabel) an engineer must take.
What to do instead
State ADM's inputs and outputs precisely: inputs are observed flows plus workload labels/tags from sensors and connectors; outputs are dependency graphs and candidate policy clusters that require human review. Drill on which connectors supply flow data (host agents, NetFlow/IPFIX ingestion, fabric) and practice describing the curation steps that turn a raw map into publishable policy.
Answering cluster sizing and high-availability questions by treating the Secure Workload cluster like a generic VM appliance - ignoring the required node count, the role of the control-plane versus data-plane nodes, and the quorum implications of losing a node.
Secure Workload is deployed as a multi-node cluster with defined roles and minimum node counts for production versus lab, and candidates often study installation as a checklist without internalizing why the topology matters. Exam items test whether you know what breaks at reduced node count.
What to do instead
Learn the reference topologies: single-node/lab versus the multi-node production cluster, which nodes serve the UI/API and which handle data ingestion and storage, and the quorum/failure-tolerance rules for each. When a question describes a node loss, first ask which role was lost and whether quorum or ingestion capacity is affected before choosing an answer.
Treating Cisco Secure Firewall Management Center (FMC) and the managed threat defense (FTD) devices as if policy were configured locally on each FTD, or assuming FMC pushes policy in real time without a deploy step.
The management-plane/data-plane split is central to the platform: FMC is the configuration and event management plane, FTD is the enforcement data plane, and changes on FMC require an explicit deploy to reach devices. Candidates who have only used standalone firewalls default to 'configure it on the box' thinking.
What to do instead
Anchor every FTD/FMC question on the split: where is the policy authored (FMC), where is it enforced (FTD), and what action commits it (deploy). Remember that pending changes on FMC are not active until deployed, and that device registration/health must be established before policy can be pushed. Practice classifying each task as authoring, deployment, or enforcement.
Conflating prefilter policy with access control policy - assuming prefilter rules can do full application inspection and intrusion prevention, or that access control rules are evaluated before prefilter/tunnel rules.
Prefilter (formerly prefilter/tunnel policy) handles fast-path decisions like tunnel rules and prefilter block/analyze rules before the main access control policy is evaluated. Candidates lump all 'rules' together and then mis-order evaluation or mis-assign capabilities like file inspection and IPS to prefilter.
What to do instead
Memorize the evaluation order: prefilter/tunnel policy is evaluated first for tunnel and fast-path decisions, then access control policy with its rule order, then the default action. Note that prefilter rules are for early allow/block and tunnel handling, while application-layer inspection, IPS, and file policy live in access control. For ordering questions, walk the packet through each policy layer explicitly.
Getting NAT wrong on FTD/FMC - mixing up the order of NAT versus access control evaluation, confusing manual NAT with auto NAT object placement, or assuming NAT rules are configured on the FTD CLI rather than in FMC.
NAT on FTD is configured as policy in FMC and has specific evaluation ordering relative to access control, plus object NAT versus manual NAT have different matching behavior. Candidates who learned NAT on other platforms carry over incorrect ordering assumptions.
What to do instead
Study the documented packet flow order for FTD (prefilter, then NAT/route lookup stages, then access control as applicable) and the distinction between auto (object) NAT and manual NAT, including where each is defined and how section ordering affects match. Practice tracing a packet through both NAT and access control and stating which policy sees the pre-translation versus post-translation address.
Assuming Secure Workload and Secure Firewall integration is automatic once both exist - not knowing which side initiates registration, what credentials/connectors are required, or what data flows between them.
Integration between the workload platform and the firewall management plane involves explicit configuration (connectors, API credentials, scope-to-device or dynamic object mapping) and candidates treat 'integration' as a checkbox rather than a configured data path.
What to do instead
Learn the integration mechanics as a data flow: what Secure Workload exports (inventory, labels, policy-relevant attributes), how it authenticates to FMC (API user/credentials), and what the firewall does with it (dynamic objects, policy updates). Be able to state which component initiates the connection and what must be pre-configured on each side before integration works.
Diagnosing agent or enforcement problems by guessing at the UI - not knowing where to look for agent connectivity status, flow telemetry gaps, or why a published policy is not taking effect on a specific workload.
Troubleshooting questions reward knowing the observability surfaces: agent status and version, connectivity to the cluster, scope membership of a workload, and whether policy was published to that enforcement point. Candidates jump to 'reinstall the agent' or 'reboot the cluster' without checking scope membership and publish state.
What to do instead
Build a triage order: (1) is the workload in the intended scope by its labels, (2) is the agent installed, running, and connected, (3) is policy published and does the enforcement point show it applied, (4) are flows visible from that workload. For firewall-side troubleshooting, check FMC device health and whether configuration was deployed. Answer troubleshooting items by naming the specific status surface you would inspect first.