Cisco 300-745 SDSI: Security Architecture Starts with Constraints

A network can contain modern firewalls, endpoint controls, identity services and cloud inspection while still failing an important security objective. The components may not protect the same data flows, trust assumptions may differ among teams, or the architecture may provide no safe recovery method when a control fails. Cisco 300-745 SDSI, Designing Cisco Security Infrastructure, examines the work that precedes product configuration: defining requirements, understanding risk, selecting security patterns, and proving that the resulting controls function together.

Cisco describes 300-745 SDSI v1.0 as a current 90-minute CCNP Security concentration exam. It earns the Designing Cisco Security Infrastructure specialist credential and can meet the professional program's concentration requirement when combined with the core 350-701 SCOR. Its published scope includes secure infrastructure and applications, events, risk and requirements, as well as AI, automation and DevSecOps. That makes SDSI fundamentally different from the operations-oriented 300-710 Secure Firewall exam or the deployment-focused 300-715 ISE exam: selecting the right control is not the same task as administering a selected control.

A requirement has to describe an outcome, not a product

Security architecture begins by translating business needs into verifiable objectives. A requirement that says “install a firewall” is not sufficiently precise. Does the organization need to prevent direct database access from user networks, isolate subsidiaries, record privileged changes, or remain available through a data center outage? Each objective implies different trust boundaries and evidence of success. An architect should be able to specify the asset, adversary or failure scenario, protected interaction and acceptable residual risk before selecting a technology.

The distinction between functional and nonfunctional requirements matters. Authentication, segmentation and cryptographic protection express specific control behaviors. Throughput, latency, fault tolerance, manageability, retention and recovery expectations constrain how those controls can operate in production. A design that meets a theoretical confidentiality objective but cannot support a hospital's clinical latency requirements may be unusable. The goal is not to make security subservient to convenience; it is to design a system whose security and operational obligations are compatible.

An architecture decision record should explain rejected alternatives, dependencies and assumptions. For example, centralized inspection might improve consistency while creating a single regional bottleneck. Distributed enforcement can reduce backhaul but requires reliable policy synchronization and logging. The principles of enterprise security architecture are relevant when those tradeoffs are discussed in context, but the SDSI reader must still connect them to concrete network and Cisco ecosystem options rather than copy a generic framework.

Threat modeling locates the trust boundary that matters

Risk is not a single “high, medium or low” label. Threat modeling identifies valuable assets, plausible attack paths, exposed interfaces, existing controls and the consequences of failure. It also distinguishes a malicious user from an accidental administrator error and a third-party service outage. Each scenario suggests different preventive, detective and recovery measures. A broad threat list without mapping to a real system is a document; a threat model linked to a design decision is an engineering tool.

Consider a payment application with a public-facing front end, internal APIs, a shared secrets service and a database. The internet-to-frontend boundary is not the only security division. The API's ability to retrieve secrets, the database's accepted callers and the build pipeline's deployment authority create separate paths for compromise. Model those paths explicitly and determine which control constrains each: identity, network segmentation, workload policy, encryption, monitoring or human approval. An attacker who can compromise a deployment credential may bypass controls that only inspect normal user traffic.

Threat modeling for enterprise applications adds detail to the analysis of misuse cases. Architects should review both direct attack paths and control-plane abuse. If a central controller can push a policy to every firewall, the controller's authentication and audit protections become critical security boundaries. If a cloud account can change logging retention, protect that privilege separately from ordinary workload administration.

Network segmentation must follow application communication

Segmentation is useful when it reduces unauthorized lateral movement while preserving legitimate workflows. A flat network exposes unrelated devices to one another; arbitrary subnet divisions may look organized but fail to enforce meaningful trust boundaries. Design segments around roles, sensitivity, management needs and permitted application paths. Document the required flows before choosing VLANs, VRFs, firewall zones or software-defined policy groups.

Network segmentation for zero trust helps illustrate the principle that address location alone does not establish trust. In practice, an engineer can connect group membership to user identity, device posture or workload context while using network enforcement to limit where traffic may go. However, the enforcement point must actually observe and control the intended path. An east-west flow that never traverses the designated firewall cannot be protected by a rule configured there.

Segmentation also has failure and maintenance implications. Overlapping policies may be hard to reason about, dynamic workloads can change addresses, and distributed controls may converge at different times. The architect should specify how policy changes are reviewed, tested and rolled back. A default-deny stance can be strong, but only if dependencies such as DNS, time synchronization, certificates, monitoring and recovery services are understood. Otherwise, a well-intentioned security change can block the very services needed to diagnose the outage.

Secure access and cloud connectivity require a coherent identity model

The architecture must account for employees, contractors, machines, privileged administrators and service identities. Their assurance levels and failure paths differ. A laptop connecting from a branch may need certificate-based device identity and user MFA; a machine workload may need a short-lived service credential and narrowly scoped permissions; a network engineer may require an auditable administrative session with just-in-time elevation. Treating all three as generic authenticated users erases important differences.

Where Cisco ISE and broader access controls are involved, distinguish authentication from authorization and enforcement. A policy server may accept a device while the network access device fails to apply the expected VLAN, ACL or security-group decision. This is why 802.1X, MAB and profiling should be framed as part of a full access lifecycle, not as proof that every attached device is trustworthy.

Cloud access extends the model across network and organizational boundaries. A design may include remote users, public SaaS, private applications and hybrid workloads. Decide which traffic is inspected, how identity is carried, where encryption terminates, how log access is governed and what happens when a regional security service fails. Secure access service edge architecture can be valuable in this discussion, but avoid suggesting that purchasing an SASE-branded service automatically closes all application, identity and data gaps.

DevSecOps and automation must protect the pipeline itself

Infrastructure and application changes move rapidly through automated pipelines. Security controls that work only during an annual audit are insufficient if production identity, routing or container policy changes daily. The architect should include code review, automated tests, secret scanning, artifact integrity, policy-as-code and deployment gates appropriate to change risk. A low-risk documentation update need not trigger the same approvals as a change that opens a privileged network segment to the internet.

DevSecOps controls in delivery pipelines provides cross-platform examples of this design logic. For Cisco-connected infrastructure, automation credentials and controller permissions require the same scrutiny as application deployment accounts. A service token able to rewrite every network policy is a powerful asset: constrain its access, log its uses, define ownership and rotate or revoke it when no longer needed. Validation should examine the resulting network state rather than assume that a successful API response guarantees enforcement.

Architecture reviews should additionally test the decision's reversibility. It is easier to approve a new filtering policy when there is a known deployment window, baseline evidence and a clear rollback boundary. It is harder to reverse a distributed identity change after hundreds of endpoints receive new certificates or tokens. Capture dependencies among secrets, device authorization, directory services and the logging pipeline so that an emergency recovery does not accidentally disable the audit evidence that a later investigation needs. In high-consequence environments, run a tabletop exercise before deployment to expose missing recovery permissions and hidden single points of failure.

AI-assisted operations add another trust boundary. A model that summarizes alerts can be given broader read access than a tool permitted to disable a firewall rule. Use approved data handling, tool allowlists, output validation and human approval for consequential actions. Monitor prompt-injection risk when tools ingest logs, tickets and untrusted documents. An AI agent's apparent fluency does not constitute authorization to change production systems. Architecture should define what inputs and outcomes are trusted before automated remediation is enabled.

Judge security architecture by operational evidence

Architecture is incomplete until its controls can be observed and tested. Define measurable outcomes: unauthorized paths remain denied, legitimate applications meet service objectives, security events reach reliable logging systems, high-risk privileges require appropriate approvals, and recovery plans work during the loss of a critical control. Test representative adverse conditions, including directory outages, regional connectivity loss, certificate expiry and partial automation deployment. A neat diagram without these checks is a proposal, not proof of resilience.

SDSI preparation should practice writing a compact architecture decision record for a realistic enterprise. State the protected assets, trust boundaries, candidate patterns, operational constraints and verification plan. Explain why a selected control belongs at a particular point and what evidence proves it is effective. An engineer who can configure any product but cannot articulate why it is placed there has not solved the design problem. 300-745 SDSI rewards the ability to connect risk and requirements to coherent, supportable infrastructure—security built into the system's reasoning rather than added as a late layer of equipment.