Examworthy
Open the appSign inStart free

200-301 domain - 15% of the exam

Security Fundamentals

Security Fundamentals is 15% of the 200-301 exam. These are the objectives it covers, each with practice questions, with every answer explained.

The domain in numbers

50
Practice questions
4
Objectives
32
Medium
18
Hard

Where people go wrong

  • Choosing the wildcard for the wrong prefix length

    The wrong answers give the wildcard for a different prefix length. A wildcard is the inverse of the subnet mask, so a /20 gives 0.0.15.255, a /26 gives 0.0.0.63 and a /12 gives 0.15.255.255. Using 0.0.31.255 for a /20 matches a /19 and doubles the block, while 0.0.7.255 matches a /21 and misses the upper half. Writing the subnet mask itself in the wildcard position is also wrong.

    See it in a sample question

  • Assuming an unmatched packet passes an ACL

    The wrong answers treat a packet that matches no entry as permitted, redirected or sent through a second pass, or blame a visible entry for a drop that no entry caused. Every ACL ends with an implicit deny that is not shown in the configuration, so a packet matching no entry is dropped. A list that permits only TCP 443 to one host therefore also drops DNS, ping and HTTP, and a list with no permit for port 443 drops HTTPS. The log keyword does not change that default.

    See it in a sample question

  • Placing a standard ACL near the source

    The wrong answers put a standard ACL near the source, or credit it with port matching. A standard ACL matches the source address only, so applied near the source it blocks that host's traffic to every destination. The guidance is standard ACLs close to the destination and extended ACLs close to the source, where the destination and Layer 4 ports can be matched and unwanted traffic is dropped early. Naming a list or changing direction adds no port matching.

    See it in a sample question

  • Mixing up the port security violation modes

    The wrong answers misattribute the violation modes. The default is shutdown, which err-disables the port and stops all forwarding, including for the original host. Protect silently discards frames from the extra MAC address while the port stays up. Restrict also discards them but logs the violation and raises the counter. A port that stays up with its original host still working is therefore running protect or restrict, not shutdown.

    See it in a sample question

  • Misplacing what DHCP snooping filters and what DAI checks

    The wrong answers misplace what DHCP snooping filters and what DAI checks. Snooping makes ports untrusted by default and drops server messages such as DHCPOFFER arriving on them, while client messages such as DHCPDISCOVER and DHCPREQUEST pass. An uplink towards the server therefore needs ip dhcp snooping trust, and trusting the access ports defeats the protection. Snooping inspects DHCP only and builds a binding table. Dynamic ARP inspection checks ARP packets against that table, not against the CAM table, the routing table or STP state.

    See it in a sample question

Objectives in this domain

Sample questions from this domain

Free sampleSecurity Fundamentalsmedium

R1 connects the campus to the internet on g0/1 (outside) and to the LAN on g0/0 (inside). The security team wants an inbound ACL on g0/1 that drops any packet whose source claims to be from the RFC 1918 range 172.16.0.0/12, as a basic anti-spoofing mitigation. Which single ACL entry matches exactly that source range and nothing outside it?

R1(config)# ip access-list extended ANTISPOOF
R1(config-ext-nacl)# deny ip <source> <wildcard> any
R1(config-ext-nacl)# permit ip any any
R1(config)# interface g0/1
R1(config-if)# ip access-group ANTISPOOF in
  • Adeny ip 172.16.0.0 0.0.15.255 any
  • Bdeny ip 172.16.0.0 0.255.255.255 any
  • Cdeny ip 172.16.0.0 0.0.255.255 any
  • Ddeny ip 172.16.0.0 0.15.255.255 any Correct
Translate a /12 prefix into the correct ACL wildcard mask so an anti-spoofing entry matches exactly the intended source range. A wildcard mask is the bitwise inverse of the subnet mask. The 172.16.0.0/12 block uses mask 255.240.0.0; inverting each octet gives 0.15.255.255. That wildcard varies the lower 20 bits, so the entry matches 172.16.0.0 to 172.31.255.255 precisely, which is the full RFC 1918 12-bit private range.

Why A is wrong: This wildcard 0.0.15.255 only varies the lower 12 bits, matching 172.16.0.0/20 (172.16.0.0 to 172.16.15.255); it puts the variable bits in the wrong octets and covers far less than the /12 block.

Why B is wrong: 0.255.255.255 is the wildcard for a /8, so this matches 172.0.0.0 to 172.255.255.255 and wrongly catches addresses outside the 172.16.0.0/12 block, such as 172.32.5.1.

Why C is wrong: 0.0.255.255 is the wildcard for a /16, so this matches only 172.16.0.0 to 172.16.255.255 and misses the rest of the /12 range, such as 172.20.0.0.

Why D is correct: A /12 leaves 20 host bits, so the wildcard is the inverse of 255.240.0.0, which is 0.15.255.255; this matches exactly 172.16.0.0 through 172.31.255.255 and nothing else.

Free sampleSecurity Fundamentalshard

An extended ACL applied inbound on an interface contains three permit entries for specific TCP flows and no explicit deny statements. A packet arrives that does not match any of the three permit entries. What does the router do with that packet, and why?

  • AIt drops the packet, because every ACL ends with an implicit deny that matches anything not permitted earlier. Correct
  • BIt forwards the packet, because an ACL with only permit entries defaults to permitting unmatched traffic.
  • CIt forwards the packet, because the implicit deny applies only to ACLs that already contain at least one explicit deny entry.
  • DIt generates an ICMP redirect and continues to evaluate the remaining interface ACLs before deciding.
Every IPv4 ACL ends with an implicit deny, so traffic matching no explicit permit is dropped. An ACL is scanned top-down and the first matching entry decides the packet's fate. Because no explicit entry matches, the packet reaches the implicit deny ip any any that silently terminates every ACL, so it is discarded even though only permit statements were typed.

Why A is correct: An ACL is evaluated top-down and stops at the first match; a packet matching none of the explicit permits falls through to the invisible deny ip any any that terminates every ACL, so it is dropped.

Why B is wrong: This is tempting because the visible list contains only permits, but the unwritten implicit deny at the end overrides that intuition and drops anything not explicitly permitted.

Why C is wrong: The implicit deny is unconditional and present on every ACL regardless of whether an explicit deny was configured, so this reasoning is wrong and the packet is still dropped.

Why D is wrong: A first-match miss does not trigger a redirect or defer to other ACLs; evaluation ends at the implicit deny on this list and the packet is discarded immediately.

Free sampleSecurity Fundamentalshard

A junior administrator claims a single standard IPv4 ACL can permit web traffic from one subnet while denying it from another based on the requested TCP port. Why is that claim incorrect about the capability of a standard ACL?

  • AA standard ACL can match TCP ports but only when it is named rather than numbered, so the claim fails on the numbering choice alone.
  • BA standard ACL can match ports but is processed bottom-up, so the deny would always win and break the intended permit.
  • CA standard ACL can match ports only on outbound interfaces, and web filtering must be applied inbound, so direction defeats the claim.
  • DA standard ACL matches the source IP address only and cannot inspect Layer 4 ports, so it cannot distinguish web traffic by TCP port at all. Correct
A standard ACL filters on source address only and cannot match Layer 4 ports or destinations. Standard ACLs evaluate the source IPv4 address and nothing else, regardless of whether they are numbered or named or applied inbound or outbound. Matching a TCP port such as 80 requires the protocol and port fields that only an extended ACL can inspect.

Why A is wrong: Naming an ACL changes only its identifier, not its matching capability; a named standard ACL still matches source address only, so the port-based distinction in the claim remains impossible.

Why B is wrong: ACLs are processed top-down, not bottom-up, and a standard ACL cannot match ports at all, so both halves of this explanation are wrong.

Why C is wrong: Direction of application does not grant port-matching ability; a standard ACL evaluates the source address in either direction and never inspects Layer 4 ports.

Why D is correct: A standard ACL examines the source IPv4 address exclusively; matching a TCP port such as 80 requires an extended ACL, so the standard ACL cannot make the port-based decision the claim describes.

Free sampleSecurity Fundamentalsmedium

Access port g0/2 on SW2 connects an end-user PC and is configured with port security as a Layer 2 mitigation. A user quietly attaches a small unmanaged switch to the wall jack and plugs in three additional devices. The interface then stops forwarding and the following show output appears: SW2# show port-security interface g0/2 Port Security : Enabled Port Status : Secure-shutdown Violation Mode : Shutdown Maximum MAC Addresses : 1 Total MAC Addresses : 2 Security Violation Count : 1 Which configured behaviour explains this result?

SW2# show port-security interface g0/2
Port Security              : Enabled
Port Status               : Secure-shutdown
Violation Mode            : Shutdown
Maximum MAC Addresses     : 1
Total MAC Addresses       : 1
Last Source Address:Vlan  : 0011.2233.4455:10
  • ADHCP snooping on g0/2 saw rogue server replies from the added devices and shut the port to stop address hijacking
  • BThe maximum MAC limit is 1, so a second source MAC was permitted but only logged while the port kept forwarding normally
  • CBPDU guard detected spanning-tree BPDUs from the unmanaged switch and placed g0/2 into the secure-shutdown state shown
  • DThe maximum MAC limit is 1 and violation mode is shutdown, so the second learned MAC triggered a violation that err-disabled the port Correct
Diagnose a port-security violation by reading the maximum MAC limit and shutdown violation mode that err-disable an access port. Port security limits how many source MAC addresses an access port may learn. With a maximum of 1 and violation mode shutdown, a second source MAC, here introduced by the daisy-chained switch and its devices, is a violation that err-disables the interface. That is why the status reads Secure-shutdown rather than the port simply logging or continuing to forward.

Why A is wrong: The output is from port security and shows a MAC-count limit, not DHCP snooping; snooping reacts to untrusted DHCP server messages, which is a different feature and not what this counter reflects.

Why B is wrong: With violation mode shutdown the port does not keep forwarding; the status reads Secure-shutdown, so the claim that traffic continued and was merely logged contradicts the output.

Why C is wrong: BPDU guard does err-disable a port on receiving a BPDU, but it reports a spanning-tree guard event, not the port-security MAC counters and Secure-shutdown status displayed here, so it is not the cause shown.

Why D is correct: Port security allows one MAC; when the extra devices presented additional source MACs, the violation mode of shutdown err-disabled the interface, which is exactly the Secure-shutdown status shown.

Free sampleSecurity Fundamentalsmedium

DSW1 is the distribution switch for VLAN 20 (10.20.20.0/24). The DHCP server sits behind uplink Gi1/0/24; access ports Gi1/0/1 to Gi1/0/23 serve clients. After enabling DHCP snooping for VLAN 20, clients on the access ports stop receiving addresses. Which configuration change restores DHCP while keeping the protection intact?

DSW1(config)# ip dhcp snooping
DSW1(config)# ip dhcp snooping vlan 20
DSW1(config)# interface range Gi1/0/1 - 23
DSW1(config-if-range)# ! no trust configured anywhere
  • AMark the access ports Gi1/0/1 to Gi1/0/23 as trusted so client requests are no longer rate-limited and discarded.
  • BAdd ip dhcp snooping information option allow-untrusted so option 82 frames from the uplink are accepted.
  • CLower the snooping rate limit on Gi1/0/24 with ip dhcp snooping limit rate 15 to stop the server replies being throttled.
  • DMark uplink Gi1/0/24 as a trusted port with ip dhcp snooping trust so server-sourced replies are allowed through. Correct
Configure the server-facing uplink as a trusted DHCP snooping port so legitimate DHCP replies reach clients. When DHCP snooping is enabled, all ports start untrusted and the switch drops DHCP server messages (DHCPOFFER, DHCPACK) received on untrusted ports. The port toward the legitimate DHCP server must be set as trusted so those replies are forwarded while rogue servers on client ports remain blocked.

Why A is wrong: Trusting the client-facing ports would defeat the protection by allowing a rogue server on those ports, and it is the server replies on the untrusted uplink, not the client requests, that are being dropped.

Why B is wrong: That command only relaxes option 82 checking on untrusted ports for relayed frames, which does not address replies being blocked on the untrusted uplink toward the server.

Why C is wrong: No rate limit is configured here, and rate limiting governs how many DHCP packets per second a port accepts, not whether server replies are trusted on the uplink.

Why D is correct: DHCP snooping makes every port untrusted by default and drops server messages such as DHCPOFFER and DHCPACK on untrusted ports, so the server-facing uplink must be explicitly trusted.

Other domains in this exam

See also the 200-301 cert hub, the study guide, and the cheat sheet.

Examworthy is not affiliated with or endorsed by Cisco. Original, blueprint-aligned practice material only.