Courseiva
hardMultiple Choice

350-401 Practice Question: Is deploying Cisco TrustSec (CTS) with Security…

A network engineer is deploying Cisco TrustSec (CTS) with Security Group Access Control Lists (SGACLs) on a campus network. The engineer configures the switch with 'cts role-based enforcement' and assigns SGTs to users via 802.1X. The engineer tests connectivity between a user in SGT 10 and a server in SGT 20. The SGACL permits traffic from SGT 10 to SGT 20, but the user cannot reach the server. The engineer checks 'show cts role-based sgt map' and sees that the user's SGT is 0. What is the most likely cause?

⚠ Common exam trap

Cisco often tests the misconception that SGT 0 is a special deny-all SGT, but in reality, SGT 0 is the default untagged SGT and simply means no SGT was assigned, causing traffic to be implicitly denied by SGACL default-deny logic.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The RADIUS server is not configured to send the SGT in the Access-Accept message.

The user's SGT is shown as 0 in the 'show cts role-based sgt map' output, which is the default SGT assigned when no SGT is received from the RADIUS server. Since the SGACL permits traffic from SGT 10 to SGT 20, but the user has SGT 0, the SGACL does not match, and traffic is implicitly denied. The most likely cause is that the RADIUS server is not configured to send the SGT in the Access-Accept message, so the switch cannot dynamically assign the correct SGT.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    The RADIUS server is not configured to send the SGT in the Access-Accept message.

    Why this is correct

    The SGT is not derived from the switch's local configuration or the interface; it is assigned dynamically by the RADIUS server during 802.1X authentication via a vendor-specific attribute (e.g., cisco-avpair with cts:security-tag). If the RADIUS server does not return this attribute in the Access-Accept message, the switch has no SGT to map to the user's role, leaving the user unclassified. Consequently, even though 'cts role-based enforcement' is enabled, the switch cannot apply any SGACL because it has no valid SGT for the session. The correct fix is to configure the RADIUS server to include the appropriate SGT for the authenticated user.

  • ✗

    The SGACL is applied to the wrong interface.

    Why it's wrong here

    SGACLs are not bound to interfaces in Cisco TrustSec; they are policy constructs evaluated on the basis of source and destination SGTs after the switch classifies traffic during authentication. The interface only carries the framed link and does not influence which SGACL is applied, because policy is role-based, not interface-based. Therefore, suggesting that the SGACL is on the wrong interface is conceptually incorrect, as there is no interface-level SGACL attachment. The actual enforcement point is the SGT-based lookup in the switch's policy database, not any specific Layer 2 or Layer 3 port.

  • ✗

    The switch is not configured with 'cts role-based enforcement'.

    Why it's wrong here

    The switch is indeed configured with 'cts role-based enforcement', as the engineer verified that the command is present in the running configuration. This global command is what enables the switch to enforce SGACLs on traffic based on SGTs, and without it, the switch would simply forward traffic without policy checks. Since the command is already active, the absence of enforcement is not due to a missing configuration of this feature. The problem lies in the fact that the SGT itself is never delivered to the switch, so even with enforcement enabled, there is no tag to evaluate.

  • ✗

    The user's SGT is 0, which is a valid SGT that denies all traffic.

    Why it's wrong here

    SGT 0 is not a valid or meaningful SGT that denies all traffic; it is a reserved value indicating that no SGT has been assigned to the session. In Cisco TrustSec, SGT 0 means 'unclassified' or 'unknown', and traffic with SGT 0 is typically forwarded without any SGACL enforcement unless a default policy explicitly drops it. The user's SGT showing as 0 is a symptom, not a root cause—it reflects the RADIUS server's failure to send an SGT in the Access-Accept message. Therefore, the issue is not that SGT 0 has deny semantics, but that the user was never allocated a proper tag.

Visual reference

Source Router + ACL permit 10.0.0.0/8 deny any Server 10.0.0.5 ✓ 192.168.1.1 ✗ dropped ACLs evaluate top-down; first match wins — implicit deny all at end

Quick reference

AAA Protocol Comparison

ProtocolPort(s)EncryptionTransportPrimary Use
RADIUS1812 / 1813Password onlyUDPNetwork access control
TACACS+49Full packetTCPDevice administration
Diameter3868Full sessionTCP / SCTPCarrier / mobile networks
802.1X—EAP-basedLayer 2Port-based access control

TACACS+ encrypts the entire packet; RADIUS only encrypts the password field — a key exam distinction.

Go deeper

Related to this question

About these practice questions

This 350-401 question is part of Courseiva's 1,923-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.