CCNA Configuration Questions

Passive authentication monitors directory server logs or agents to map user IP addresses to usernames without user intervention.

Dynamic PAT translates outbound traffic to the outside interface's current address, so the rule automatically tracks the DHCP-assigned IP without hard-coding it. Static NAT or manual address entries would break when the dynamic address changes, failing outbound connectivity.

Slow Path forwards matching traffic into the normal inspection pipeline, where access control, intrusion, and file policies evaluate it. This satisfies the requirement to explicitly designate traffic for full analysis rather than bypassing or dropping it at the prefilter stage.

Access control rules match traffic by application identity, so peer-to-peer file-sharing applications are blocked regardless of the port they use. Port-based rules would fail here, since these applications evade fixed-port blocking by dynamically shifting ports.

Log at End records the connection's termination, capturing bytes transferred, duration and close reason once the session finishes. Together with Log at Beginning, it forms the two logging options available on an Access Control Rule's Logging tab.

A Tunnel prefilter rule matches and handles GRE-encapsulated traffic, letting the firewall inspect or accelerate the inner flow rather than the outer tunnel. This satisfies the stem's requirement by specifically targeting tunneled packets, which standard access-control rules cannot evaluate.

The Devices > Device Management menu in FMC lists all managed FTD devices, showing their status, model and health. Navigating there satisfies the stem's requirement to view the inventory of FTD devices registered to the manager.

The Applications tab in the Access Control Policy references application detectors, letting administrators select a specific application such as Facebook for blocking. It satisfies the requirement to define a named application, unlike URL, category or user conditions, which filter by destination or identity instead.

Security Intelligence feeds and lists are configured on the Security Intelligence tab within an Access Control Policy in the FMC. This placement lets the policy evaluate source and destination IP reputation against the feed before allowing or blocking traffic.

The FTD re-signs intercepted traffic with its own CA, so clients must trust that CA or they reject the certificate. Importing the FTD's Re-signing CA certificate into each endpoint's trusted root store satisfies the stem's constraint that clients currently reject the re-signed certificate as untrusted.

The Network Discovery Policy defines which networks and ports the FMC's discovery function scans, plus which devices and applications are excluded. This scoping determines what managed and unmanaged hosts appear in the network map, directly satisfying the requirement to define discovery scope.

Do Not Decrypt bypasses inspection entirely, letting the TLS session pass through untouched. It is one of the three SSL Decryption Policy actions, used for traffic that must not be intercepted, such as financial or health sites, or where decryption would break certificate pinning.

URL Categories match traffic by the reputation or category assigned to the requested URL, satisfying the criterion of matching by web destination classification. This differs from matching by application detector, IP address, or security zone, and requires URL filtering licensing and a configured access control policy.

A dedicated failover link interface is required to exchange failover status and heartbeat messages between the active and standby FTD devices. This link ensures that both devices are aware of each other's state and can trigger a failover if needed. Without it, the devices cannot coordinate failover, leading to potential split-brain scenarios.

For the FTD to initiate communication with FMC, it needs a route to the FMC's IP address. If FMC is on a different subnet, a default gateway or specific static route must be configured on the management interface. Without a route, the FTD cannot send registration packets to FMC, and registration will fail even if all other settings are correct.

First match wins.

A Port Group Object aggregates multiple existing port objects, such as TCP 80, 443 and 8080, into one reusable container. Referencing it in Access Control Policy rules avoids creating separate rules for each port, simplifying administration.

Log at End records the connection once it terminates, capturing the final action and bytes transferred rather than generating an entry at session start. This matches the requirement to log only when traffic matches the rule, and it reduces log volume compared with logging at both points.

The connection event's 'Rule Name' field directly records which Access Control Rule matched the traffic, satisfying the need to attribute a specific connection to its triggering rule. Cisco Secure Firewall Management Center populates this field at evaluation time, so no correlation across separate rule or policy tables is required.

Prefilter policies operate before and separately from the Snort inspection engine, so matching traffic is allowed or blocked without deep packet inspection. This bypass explains why a Prefilter rule drops the connection regardless of Snort configuration.

Block with Reset drops the packet and returns a TCP RST to the sender, immediately terminating the connection rather than silently discarding it. This satisfies the requirement to both deny traffic and notify the client, unlike plain Block, which drops silently and forces the client to time out.

A Trust rule in an Access Control Policy permits matching traffic to pass without any further inspection by the access control policy, bypassing intrusion and file analysis. This satisfies scenarios needing uninspected throughput for trusted flows.

Application filters are reusable objects created under Objects > Object Management > Application Filters in the FMC. Building the filter there lets the administrator group cloud storage applications once, then reference that single object in Access Control rules instead of selecting each application individually.

Interactive Block drops the connection but returns a notification page to the user explaining the block, unlike plain Block which silently discards traffic. This satisfies the requirement to inform the user while still denying access.

QoS policies on FTD only affect traffic when bound to Security Zones within the Access Control Policy's QoS tab, since that association determines which zone-to-zone flows the rate limiting and prioritisation rules actually inspect and shape.

A decryption policy rule matching the Financial and Health URL categories with a 'Do Not Decrypt' action exempts that traffic from inspection while all other categories remain decryptable. This satisfies the privacy and regulatory compliance constraint without disabling decryption fleet-wide.

Identity NAT exempts matching traffic from translation by mapping addresses to themselves, so the specified internal subnets traverse the partner VPN tunnel with their original source addresses intact. This directly satisfies the requirement that those subnets never undergo NAT translation, unlike dynamic or static NAT, which rewrite addresses.

Application Category is one of the three Access Control rule components that classify traffic as Application, alongside Application and Application Tag. It satisfies the stem's requirement by letting the rule match on the category metadata Cisco assigns to the detected application, rather than on IP, port, or URL alone.

Custom URL categories are populated by adding URL objects, which live under Objects > Object Management > URL in FMC. Creating the URL objects there and grouping them into the category satisfies the requirement to add specific domains, since FMC has no separate domain-list editor for custom categories.

Security zones are reusable objects stored in the FMC object library, so they are created under Objects > Object Management > Security Zones before being referenced in access control policies. This grouping lets one zone object represent several FTD interfaces, satisfying the requirement to simplify rule creation.

Interface PAT overloads the interface IP, translating many internal addresses to that single address via port multiplexing. This satisfies the requirement to hide the internal network behind one interface IP, unlike static NAT, which maps one-to-one and would expose individual hosts.

A Security Zone in FMC is a logical container that groups interfaces sharing identical security policies, letting rules apply once rather than per interface. This satisfies the requirement to logically group interfaces, simplifying policy management across multiple physical or virtual interfaces.

The Identity Policy binds realm, realm-to-AD mapping and active authentication methods together, then is referenced by access control rules. Without it, FMC cannot resolve user or group identity for rule matching, so it satisfies the requirement for user identity mapping.