Secure Infrastructure Design practice questions

Physical port density on the headend device.

Why it fails: VPN headends are typically bandwidth and session-bound.

The use of DTLS for latency-sensitive traffic.

Why it fails: This is a protocol choice, not a design consideration for architecture scale.

Configuring internal DNS servers for split-tunneling.

Why it fails: This is a configuration task, not an architecture design factor.

Cisco Meraki Dashboard.

Why it fails: Meraki dashboard is for managing Meraki devices, not designing enterprise architectures.

Cisco Webex.

Why it fails: Webex is for collaboration.

Cisco Jabber.

Why it fails: Jabber is a messaging tool.

Port Security.

Why it fails: Port Security tracks MAC, not IP.

Dynamic ARP Inspection (DAI).

Why it fails: DAI targets ARP spoofing, not IP address usage.

DHCP Snooping.

Why it fails: Snooping builds the binding database; IPSG enforces it.

Port Security.

Why it fails: Port Security is for MAC limit, not traffic rate limit.

Rate Limiting (QoS).

Why it fails: QoS handles priority, while Storm Control handles excessive traffic volume.

Broadcast suppression.

Why it fails: Storm Control is the formal name for this feature.

Shared MAC addresses across interfaces.

Why it fails: MAC addresses can be unique or managed by HSRP/failover.

DHCP snooping.

Why it fails: DHCP snooping is for security binding, not visibility.

Standard Layer 3 routing.

Why it fails: Routing does not provide encrypted visibility.

Cloud-Native Policy Mapping

Why it fails: This is not a specific feature name for multi-cloud policy consistency.

Virtual Private Cloud Bridging

Why it fails: Bridging is a layer 2 concept not suitable for multi-cloud policy management.

Multi-Cloud Dynamic Routing

Why it fails: Routing focuses on connectivity, not policy consistency.

Cisco AnyConnect

Why it fails: AnyConnect is a transport mechanism, not a posture engine.

Cisco ASA

Why it fails: ASA is a firewall, not an identity-based posture engine.

Cisco ISE

Why it fails: ISE generally requires the user to be connected to the corporate network via VPN or local link.

IKEv2 Virtual Tunnel Interfaces

Why it fails: VTI is a configuration method, not an address-agnostic feature.

AnyConnect Mobility

Why it fails: AnyConnect is for remote access, not site-to-site.

Dead Peer Detection

Why it fails: DPD is for tunnel maintenance, not tunnel establishment.

Cisco ACI

Why it fails: ACI is for data center fabric, not workforce Zero Trust.

Cisco Webex

Why it fails: Webex is a collaboration tool.

Cisco Catalyst 9000

Why it fails: This is hardware; while it supports features, it is not a Zero Trust 'technology' itself.

Deploy Cisco Identity Services Engine for endpoint posture assessment at branches.

Why it fails: ISE provides identity-based access control and posture assessment, but it is not specifically required to secure direct internet traffic or to inspect data center-bound traffic. While ISE could be part of a broader security design, it does not directly address the stated requirements for cloud-delivered security or firewall inspection of specific traffic flows.

Use Cisco SD-WAN VPN segmentation to separate guest and corporate traffic.

Why it fails: While VPN segmentation in Cisco SD-WAN can separate traffic, the requirement specifically asks for segmentation between guest and corporate traffic. However, the question asks for two design elements to meet the requirements, and segmentation is already implied by the need to separate guest and corporate traffic. But the primary requirements are firewall inspection for data center traffic and cloud-delivered security for internet traffic. VPN segmentation alone does not provide these security functions; it is a supporting mechanism. Therefore, it is not one of the two most critical elements.

Enable Cisco SD-WAN Application-Aware Routing to prioritize business-critical applications.

Why it fails: Application-Aware Routing (AAR) optimizes application performance by selecting the best path based on policies, but it does not provide security inspection or cloud-delivered security. It is a performance optimization feature, not a security control, and therefore does not meet the requirements for firewall inspection or secure internet access.

Cisco Secure Firewall Threat Defense managed by Cisco Defense Orchestrator

Why it fails: Cisco Secure Firewall Threat Defense managed by Cisco Defense Orchestrator provides cloud-based management and stateful inspection, but it does not inherently provide user identity enforcement without integration with an identity source such as Cisco Identity Services Engine or Active Directory. The branch has no local identity server, so the design would still require a remote identity service. This solution does not meet the identity requirement as stated.

Cisco Secure Firewall ASA with Cisco Identity Services Engine integration

Why it fails: Cisco Secure Firewall ASA can enforce identity-based policies when integrated with Cisco Identity Services Engine, but the scenario specifies no separate identity server at the branch. While ISE can be deployed centrally and accessed over the WAN, the branch has a single WAN link and no local staff, making this design dependent on WAN availability for identity. It does not provide a self-contained identity enforcement capability at the branch.

Cisco Secure Firewall Threat Defense with Cisco Firepower Management Center

Why it fails: Cisco Secure Firewall Threat Defense with Firepower Management Center offers stateful inspection and application visibility, but it requires an on-premises management appliance and does not natively enforce user identity policies without an external identity source. The branch has no local management staff, and the design would need additional identity integration. This option therefore does not satisfy the identity and management requirements in the scenario.

Cisco vBond orchestrator

Why it fails: Cisco vBond orchestrator performs initial authentication and orchestrates connectivity between devices and controllers. It validates device serial numbers and certificates during onboarding, but it does not distribute the cryptographic keys used for control plane encryption between vSmart and vEdge devices. The key distribution is handled by another controller, so vBond does not fulfill the described responsibility.

Cisco vManage

Why it fails: Cisco vManage is the management plane component that provides a GUI and API for configuration, monitoring, and policy management. While it plays a role in device onboarding by generating bootstrap configurations, it does not authenticate devices for control plane participation or distribute cryptographic keys for the control plane. Those functions belong to the controller responsible for control plane security, so vManage is not the correct answer.

Cisco vAnalytics

Why it fails: Cisco vAnalytics is a reporting and analytics platform that provides visibility into SD-WAN performance and security. It does not authenticate devices or distribute cryptographic keys for the control plane. Its role is monitoring and analysis, not control plane security. Therefore, it does not meet the requirement to authenticate devices and secure control plane communications in the SD-WAN overlay.

Relying solely on AWS Security Groups for inter-VPC traffic.

Why it fails: Security Groups are stateful instance-level allow lists that permit traffic between VPCs once peered; they perform no deep inspection and enforce no centralised policy. It is tempting because they are native, free and simple. Mitigating lateral movement requires firewall inspection at a centralised choke point.

Implementing an Overlay Network using Cisco ACI Remote Leaf.

Why it fails: Cisco ACI Remote Leaf extends a single ACI fabric's policy domain to remote sites; it does not inspect or segment traffic between AWS VPCs, so lateral movement remains possible. It is tempting for unified on-premises and cloud policy, but AWS VPC-to-VPC inspection needs firewall appliances or a transit gateway architecture.

Deploying individual firewall appliances in each VPC.

Why it fails: Per-VPC appliances inspect local traffic but create separate policy domains, so inter-VPC flows traverse AWS routing without centralised enforcement, and management overhead multiplies. It is tempting for granular control within one VPC. Centralised enforcement across VPCs requires a hub-and-spoke transit design with a shared inspection point.

AnyConnect standalone VPN gateway.

Why it fails: AnyConnect standalone VPN gateways terminate tunnels and enforce network-layer policy, but Cisco+ Secure Connect performs identity-based access control through its cloud security edge with integrated identity provider context. Standalone VPN suits legacy remote-access deployments without SASE's unified policy plane.

Firepower Management Center cloud connector.

Why it fails: Firepower Management Center cloud connector integrates firewall policy management with Cisco+ Secure Connect; it does not perform identity-based access control. That role belongs to the identity provider integration brokering authentication and policy. The connector is tempting because it links on-premises firewalls to the cloud security fabric, which suits hybrid enforcement scenarios, not remote-user identity brokering.

On-premises ISE cluster.

Why it fails: An on-premises ISE cluster authenticates devices and users on the local network, yet Cisco+ Secure Connect enforces unified identity-based access in its cloud-delivered policy engine, not behind a corporate perimeter. ISE suits campus network access control rather than cloud SASE remote-user policy.

Using static IP addresses for every IoT device to ensure consistency.

Why it fails: Static addressing provides no identity or posture signal and does not scale, so it contributes nothing to Zero Trust enforcement with ISE and TrustSec. It is tempting because fixed addresses simplify device tracking and ACL writing, and static assignment is the right choice for infrastructure such as printers or cameras needing predictable reachability.

Ensuring all IoT devices are placed in the same VLAN for easier management.

Why it fails: A single flat VLAN removes the segmentation boundary TrustSec security group tags enforce, so compromised IoT devices could reach every peer. It is tempting because one VLAN simplifies management and DHCP scoping, and it is the correct design for small, trusted, single-purpose networks without lateral-movement concerns.

Disabling 802.1X for all non-PC devices.

Why it fails: Disabling 802.1X removes the identity-based authentication that Zero Trust requires, leaving IoT devices unverified before network access. It is tempting because IoT endpoints often lack 802.1X supplicants, and MAB or profiling is the correct compensating control in that scenario, not wholesale disabling of the protocol.

Using static routing to bypass all security policies for trusted SaaS domains.

Why it fails: Static routes cannot identify SaaS application traffic or apply the application-aware policies and IPsec tunnels that SD-WAN uses, and bypassing security removes the required protection. Static routing suits small, stable topologies with fixed next hops, not dynamic SaaS optimisation with centralised policy enforcement.

Deploying a dedicated physical firewall at every branch office.

Why it fails: A dedicated physical firewall per branch inspects traffic locally but provides no application-aware path selection or tunnel optimisation across transports, so SaaS performance is not improved. Dedicated branch firewalls suit sites needing local perimeter enforcement independent of the SD-WAN fabric's routing decisions.

Hair-pinning all SaaS traffic back to the corporate headend for inspection.

Why it fails: Backhauling SaaS traffic to the headend adds latency and defeats the direct internet breakout that SD-WAN uses to optimise cloud-bound flows. Headend hair-pinning is the right design when all traffic must traverse a centralised security stack, such as strict compliance environments with no local internet egress.

Deploy separate FMC instances in each cloud provider for localized management.

Why it fails: Separate FMC instances create independent policy domains, so a rule change on the AWS manager never propagates to the Azure pair, breaking the consistency the scenario demands. It is tempting because per-cloud managers reduce cross-region latency and isolate administrative failure domains, which suits wholly independent estates.

Use individual Firewall Device Managers (FDM) for every instance.

Why it fails: Individual FDMs manage standalone appliances and cannot share policy objects, so per-instance managers give no consistent enforcement across AWS and Azure. FDM is correct for managing a single firewall via its local web interface, not for centralised multi-cloud policy.

Implement cloud-native security groups exclusively to bypass firewall bottlenecks.

Why it fails: Cloud-native security groups are enforced per VPC and per provider, so AWS rules cannot be expressed identically in Azure, and they lack the deep inspection the firewall provides. They suit stateless segmentation between tiers inside one provider, not cross-cloud policy parity.

IKEv2 protocol support.

Why it fails: IKEv2 is a VPN tunnel protocol negotiating encryption and mobility, not endpoint posture assessment; it cannot inspect antivirus, patch level or firewall state. It is tempting because IKEv2 genuinely suits always-on remote access, but posture checking requires Cisco Secure Client's Posture module with ISE or ASA hostscan.

Split-tunneling.

Why it fails: Split-tunneling is for traffic steering, not security posture.

Dynamic Access Policies (DAP).

Why it fails: Dynamic Access Policies evaluate posture results and assign authorisation after the endpoint has already connected, rather than performing the pre-connection posture check the stem demands. It is tempting because DAP is a genuine AnyConnect feature for granular, context-aware access control once posture data exists.

Deploy individual local managers for each cloud provider.

Why it fails: Separate local managers per cloud fragment policy administration, so no single consistent rule set spans AWS and Azure. It tempts because local managers reduce latency and survive WAN outages; that design fits isolated, independently administered clouds rather than one unified multi-cloud security policy.

Rely on native cloud-native security groups only.

Why it fails: Security groups are cloud-specific constructs with different semantics and no shared policy model, so AWS and Azure rules cannot be kept consistent. It tempts because they are agentless and free; they would suffice where each cloud's workloads need only basic instance-level filtering and no unified enforcement is required.

Implement separate FTD instances with unique local access control lists.

Why it fails: Separate FTD instances with unique local ACLs produce divergent rule sets per cloud, so policy drifts between AWS and Azure. It tempts because per-cloud appliances scale independently; it would suit environments where each cloud has genuinely distinct security requirements and no shared policy baseline is needed.