Cisco 300-745 SDSI: Designing Security Infrastructure Around Risk

Security architecture is rarely a choice between one good control and one bad one. A regional office may need cloud collaboration, regulated data access, vendor support, low-latency applications and emergency operations all at once. A design that improves one control can introduce fragile dependencies elsewhere. Cisco 300-745 SDSI—Designing Cisco Security Infrastructure—tests the ability to select and adapt defensible security designs across infrastructure, applications, risk, emerging technologies and automation. It is a current concentration within the Cisco CCNP Security program.

SDSI is not a successor that reproduces every retired security concentration. Cisco introduced it as an architecture-oriented specialist assessment covering secure infrastructure, cloud-native applications, risk, events, requirements, AI, automation and DevSecOps. The current exam is version 1.0. Passing it can earn the Designing Cisco Security Infrastructure specialist credential and satisfy a concentration requirement when paired with SCOR, but its scope differs materially from firewall implementation or the retired VPN concentration. Good preparation starts with requirements, assets and failure consequences rather than choosing a technology product first.

Translate a business requirement into a defensible design

Consider a healthcare platform that must let clinicians view records remotely, exchange data with laboratories and keep sensitive systems isolated from guest and public access. “Deploy zero trust” is not an architecture. The requirements need to identify users and machines, data classifications, service dependencies, acceptable downtime, regulatory constraints and operational teams. Only then can a design choose identity enforcement, network segmentation, application authorization, encryption and monitoring in a coherent combination.

Security risk has dimensions beyond threat likelihood. A control might prevent unauthorized access but leave a clinic unusable during an identity-provider outage. Another design may remain highly available but fail to restrict privileged maintenance access. A credible architecture documents assumptions, expected failure modes and recovery paths. Architecture tradeoffs are useful conceptual support, although Cisco's SDSI objectives emphasize the network and technology-specific decisions in its own program.

Security design reviews should include people who own the application, network, endpoints and incident response. An architecture can satisfy a diagram and still fail because a service's dependencies were unknown. Agree on both required and prohibited communication paths, then assign ownership for configuring, measuring and maintaining each control. Security architecture is as much about enforceable operating agreements as about device placement.

Hybrid workers change the identity perimeter

A conventional perimeter assumes users work on a trusted office network and can reach a private application after crossing one boundary. Hybrid workers, contractors and SaaS services make that model incomplete. The design needs user authentication, endpoint trust, least-privilege access, application-specific authorization and visibility into sessions from different locations. Public internet access and corporate access can coexist, but their inspection and identity boundaries must be explicit.

A consultant works from a personally owned laptop and needs one project-management application. Routing the laptop into a broad private network could expose many unrelated systems. An identity-aware application access model may better fit the requirement, subject to device and authentication controls. The zero-trust design principle describes continuous verification and least privilege; SDSI candidates need to apply that principle to concrete network, identity and application choices rather than use it as a slogan.

Remote-access design also has to survive faults. If every employee session depends on one regional security gateway, that gateway becomes a business continuity risk. Redundancy, local internet breakout, cloud-access policy and DNS behavior must be considered together. Measuring only the security gateway's uptime misses the user's true service experience.

Segmentation should follow application dependencies

Different security zones and microsegments can limit lateral movement after a compromise. The correct granularity depends on the application. Separating a database from a web tier may be helpful, while indiscriminately blocking service discovery, monitoring or backup traffic can break legitimate operations. Begin with observed and approved flows, identify identities and service owners, and then define a policy that permits the necessary communication while rejecting unrelated paths.

Suppose a new containerized service makes calls to an internal payment API and an external fraud-scoring endpoint. A distributed firewall rule that permits any east-west traffic will undermine isolation. A rule scoped too narrowly may prevent DNS, certificate checks or service discovery. The logic of east-west segmentation needs a complete service map, not only the obvious business API. Validate application success and unauthorized denial as part of the same acceptance test.

Segmentation at the network layer is not sufficient on its own. A compromised workload inside an authorized segment may still abuse application credentials. Design complementary controls for workload identity, secrets access, authorization and audit trails. An effective security architecture recognizes which threats each layer can and cannot stop.

Secure the management and control planes deliberately

Infrastructure management interfaces, controllers and routing protocols provide high-value attack paths. The management plane should have constrained reachability, strong administrative authentication, attributable changes and properly protected secrets. The control plane should be protected against malicious or accidental destabilization, including abusive protocol traffic and policy errors. A design that focuses solely on filtering user packets can leave the network itself exposed.

Imagine a compromised workstation inside a supposedly trusted operations VLAN. If it can reach every controller and device administrator interface with reused credentials, an attacker can alter security policy broadly. Role-based access control limits what an authorized account can do, but the architecture must also restrict where such actions can originate and how they are reviewed. Emergency access should be separated and monitored rather than made equivalent to ordinary operations.

Network control-plane protections are also sensitive to availability. Overly restrictive rate limits or routing authentication changes can disconnect legitimate peers and interrupt service. Test enforcement under expected peaks and carefully staged fault conditions. Security is not improved when the protection mechanism unpredictably destroys the network it is intended to defend.

Cloud-native applications need their own enforcement choices

Containers, microservices and serverless platforms move and scale differently from fixed virtual machines. Source addresses may change, workloads may be short-lived and internal service calls may outnumber external requests. A security architecture may combine cloud IAM, workload identity, service policy, API gateways, network controls and application-level protections. The appropriate choice depends on where a reliable identity and enforcement point can be maintained.

For example, protecting a customer-facing API requires more than a perimeter firewall rule. Rate limiting, input validation, API authorization, secrets management and incident telemetry address threats that ordinary network-layer filtering cannot. Cloud-network controls can illustrate some adjacent concepts, but SDSI candidates should remain grounded in Cisco's secure infrastructure and application-design expectations. Avoid assuming product names alone define an architecture.

Inspecting encrypted traffic also raises legal, performance and trust questions. A design that decrypts every connection may cause privacy and certificate-management problems; a design that inspects nothing may leave blind spots. Choose a proportionate approach, identify exceptions and define what alternative signals are available when payload inspection is inappropriate.

Risk and incident response must influence the architecture

Architecture is incomplete if the security operations center cannot distinguish a real attack from normal change activity. Decide which events should be captured, how identities are correlated across systems, where logs are stored and how long relevant evidence remains available. A response team needs enough context to identify an affected asset, its business function, the path used and the action that contained the threat. Incident triage becomes much more effective when the infrastructure was designed to produce actionable evidence.

Suppose an endpoint alert suggests suspicious lateral movement. If all internal systems share one broad subnet and access logs lack user identity, defenders may be forced to isolate an entire site. With defensible segmentation and correlated events, responders can contain a smaller group of systems while preserving critical services. That outcome is an architectural benefit, not merely a monitoring feature.

Risk treatment should be explicit where a perfect technical control is impractical. Document residual risk, owner approval, compensating controls and expiry dates for exceptions. A temporary broad allow rule used during a migration should not become invisible permanent policy simply because nobody remembers why it was created.

Automation and AI should be constrained by design

Infrastructure-as-code and policy automation can make security changes consistent, but they can spread mistakes across many environments. Treat source repositories, review approvals, scanning, secret storage, deployment identities and rollback mechanisms as part of the security architecture. A generated policy that passes syntax validation may still authorize too much traffic. Effective tests should include prohibited paths and failure behavior, not just successful deployment logs.

AI-based assistants and agentic workflows introduce another layer of trust. An automated recommendation may be fluent but wrong, especially when it relies on incomplete inventory or untrusted external content. Do not give a model unrestricted access to change firewalls or rotate administrative credentials. Prefer bounded read operations, typed proposed changes, explicit authorization, audit records and independent validation. The discipline of assigning AI risk ownership fits naturally with this engineering requirement.

SDSI preparation should therefore use design scenarios, not only feature definitions. Take one real application architecture and justify identity, segmentation, secure connectivity, protection of management access, detection, and recovery. Introduce a cloud migration and a remote-work requirement, then explain which decisions need to change and which security invariants must survive. A sound architecture can be defended in terms of measurable protection and availability—not by how many security products appear on the diagram.