Cisco 300-745 SDSI: Security Infrastructure Design That Survives Change

The Cisco 300-745 SDSI exam assesses the ability to design security infrastructure rather than simply configure a single security product. Cisco calls it Designing Cisco Security Infrastructure and lists version 1.0 as an active 90-minute CCNP Security concentration. Candidates must reason about secure infrastructure, applications, risk and events, requirements, artificial intelligence, automation, and DevSecOps. The goal is a design whose assumptions, constraints, and controls can be explained and tested—not a diagram with as many security technologies as possible.

A candidate pursuing CCNP Security combines a qualifying concentration with 350-701 SCOR, which provides the broader foundation in network, endpoint, content, cloud, and secure access technologies. SDSI changes the perspective. Instead of being asked why inspection matters, the designer should explain where inspection belongs, what must be visible, how exceptions are governed, and how the architecture behaves when a region, identity service, or enforcement component fails. This makes the exam relevant to security architects, technical leads, and engineers moving from product operations into enterprise-level design.

Begin with requirements and risk, not a shopping list

Security requirements come from applications, data classification, identities, regulatory obligations, business continuity objectives, and an organization's tolerance for loss. A hospital and a software developer might use similar firewalls but have very different needs for availability, privacy, third-party access, and change windows. Establish which assets matter, who is allowed to use them, what threats are plausible, which evidence regulators or auditors expect, and what recovery characteristics are needed before selecting technologies.

Distinguish functional requirements from nonfunctional constraints. An application may require partner access to a reporting API; its security requirements might include strong service identity, protected traffic, traceable authorization, rate limits, and revocation. Nonfunctional constraints might cover latency, throughput, availability, observability, and support staffing. A design that protects confidentiality but prevents the application from meeting a real-time service-level objective can still be a failed design. Record the trade-off explicitly and verify that the business owner accepts it.

Risk modeling should separate likelihood and impact from simple vulnerability counting. A low-frequency event with severe consequences may require an architectural control even when the observed incident count is small. Conversely, deploying a complex inline system to address a low-impact and unlikely threat can introduce disproportionate operational risk. Use threat scenarios, probable attack paths, trust boundaries, and failure analysis to justify controls. The design should make it possible to show which risk each control reduces and which residual risk remains.

Design segmentation and secure connectivity together

Segmentation can be implemented through VLANs, VRFs, security groups, identity-aware policies, firewall zones, workload labels, and application gateways. The choice depends on the network and workload architecture; a subnet boundary is often a useful routing device but not a sufficient indicator of identity or application trust. For example, a user browsing an internal HR application and a service account transferring payroll data may originate from the same campus, yet they need different authorization and monitoring.

Start by listing legitimate communication patterns among applications, users, infrastructure services, and third parties. Then identify enforcement points at which those paths can be controlled without creating unnecessarily brittle dependencies. Infrastructure design must account for where packets actually traverse the controls, including alternate routes and failover paths. An elegant policy that is bypassed by a standby data-center route is not effective. The access-control-list fundamentals support simpler network boundaries, whereas more contextual enforcement can be added through identity and application-aware systems.

Security architecture also depends on the connectivity model. Branch access, private application access, cloud connections, and internet-bound SaaS each may have different inspection and identity paths. Centralizing all traffic can simplify one form of visibility while increasing latency and creating concentration risk. Direct access can improve locality but requires distributed policy consistency. The technical comparison should include data paths, failure conditions, administrative trust, and incident evidence, rather than a preference for centralization or distribution as an ideology.

Integrate identity, endpoint security, and cloud controls

Identity is an architectural plane. Privileged users, service accounts, devices, and workloads need reliable authentication and suitably scoped authorization. Trust should be re-evaluated when role, endpoint state, or access context changes. A device enrolled last year should not automatically remain compliant after losing its management agent. Access policies also need survivability rules when an identity provider becomes unavailable, particularly for safety-critical services or emergency operations.

The practical Cisco ISE concentration explains how network-access identity can be implemented, but SDSI asks whether that identity signal reaches the correct enforcement points and remains trustworthy across the whole estate. Correlate an authorized network connection with application-level identity and security telemetry. If a user is allowed onto an employee VLAN, that fact alone should not permit unrestricted API calls to sensitive applications.

Cloud security introduces a shared-responsibility boundary and rapidly changing resources. Identity permissions, cloud logging, encryption keys, network reachability, and workload metadata are often configured through separate control planes. An architecture needs continuous asset discovery and policy validation so that a newly deployed workload inherits appropriate protection. The cloud shared responsibility discussion illustrates why a provider's infrastructure security does not replace customer choices about identity, data, and service configuration.

Plan observability and response before incidents occur

A design cannot be considered manageable if investigators cannot reconstruct important events. Specify which systems produce identity records, packet or flow summaries, workload events, endpoint detections, DNS evidence, application logs, and configuration-change records. Then decide where those records are normalized and correlated, who can access them, how long they remain, and what happens when collection is delayed. Retention alone is insufficient if a critical data source lacks consistent timestamps or asset identifiers.

Detection and response processes should follow the actual threat model. For ransomware movement, identity anomalies, new remote execution paths, changes to privileged groups, and lateral traffic may matter more than an isolated malware alert. For data exfiltration, egress patterns, authorized destinations, and classification of accessed records become central. Create response playbooks that can isolate an endpoint, revoke a credential, or block a specific flow while preserving evidence. A plan that depends on an unavailable management system during the incident needs a documented alternate path.

Measure the system with meaningful security and service metrics: time to detect a high-confidence event, time to enforce a containment decision, completeness of asset coverage, latency introduced by inspection, and recovery of critical applications. A high event count does not prove good detection. Likewise, a quiet console may mean there is no problem, or that sensors are blind. Test those explanations with deliberate detection exercises and sensor-health checks.

Incorporate AI, automation, and DevSecOps cautiously

Cisco's SDSI scope includes AI and automation because contemporary security architecture has to govern systems that act on rapidly changing evidence. AI-assisted analysis can summarize alerts and propose hypotheses, but a generated explanation is not a verified incident finding. Security teams should know what data enters a model, how access to prompts and results is controlled, what human approval is required for impactful actions, and how erroneous recommendations are detected. Safeguards are particularly important when an automated remediation can disable production connectivity.

Infrastructure as code can express repeatable firewall objects, cloud policies, routing configurations, and monitoring resources. Reviewable changes, test environments, drift detection, and approval gates reduce the risk of one-off console modifications. The DevSecOps security practices for infrastructure as code and CI/CD show why security checks belong in the delivery workflow, not only at the final deployment stage. An automated policy must still be evaluated for excessive privileges, unintended connectivity, secret exposure, and rollback safety.

Do not assume automation solves an inadequate policy design. A script can consistently apply a dangerous allow-all rule to every site, making the problem more widespread. Preserve configuration provenance and test negative cases as deliberately as positive ones. For AI-driven recommendations, record confidence, supporting evidence, and the authorized operator who approved the final action. Those governance mechanisms connect technical controls to accountability.

Defend a design through an explicit failure scenario

Imagine a company acquiring a regional business with its own identity directory, two data centers, public cloud workloads, and hundreds of remote employees. The initial temptation is to connect all networks and add a central security gateway. A better SDSI analysis defines data classifications, user populations, inter-business application dependencies, regulatory boundaries, allowable cross-domain services, and cutover risk. It then selects phased identity federation or migration, segmentation policy, cloud guardrails, and telemetry integration appropriate to those constraints.

Test the proposed design against a stolen remote user credential, a compromised workload, a regional outage, and a failed automation rollout. For each, ask which control prevents or limits the event, which signal proves the control operated, and how normal business processes resume. The security program should not require every branch to traverse an unavailable central enforcement device to access locally authorized emergency services unless that dependency has been deliberately accepted.

A practical design review should separate identity availability from authorization correctness. An authentication service can be healthy while group membership, device posture, or token claims grant access outside an intended boundary. Map the identity flow for employees, contractors, application workloads, and emergency administrators. For each group, define the authoritative directory, expected MFA or workload credential, access-expiry mechanism, and logging source. Then test what happens when federation becomes unavailable: existing tokens may remain valid for a period even though new sign-ins fail. This distinction affects containment, business continuity, and revocation strategy. Architecture decisions should identify where access decisions are made and where they are enforced, rather than treating identity as a single box on a network drawing.

SDSI preparation benefits from decision records as much as configuration labs. Take two realistic network architectures, produce a requirements matrix, compare viable enforcement locations, document the residual risks of each option, and write the verification evidence needed for acceptance. This shifts the candidate from product selection to reasoned architecture—the essential distinction between the design concentration and hands-on specializations such as 300-710 SNCF.