Exam 300-710 All Questions

View all questions & answers for the 300-710 exam

Exam 300-710 topic 1 question 181 discussion

Actual exam question from Cisco's 300-710

Question #: 181
Topic #: 1

An engineer is troubleshooting connectivity to the DNS servers from hosts behind a new Cisco FTD device. The hosts cannot send DNS queries to servers in the DMZ. Which action should the engineer take to troubleshoot this issue using the real DNS packets?

A. Use the packet capture tool to check where the traffic is being blocked and adjust the access control or intrusion policy as needed
B. Use the Connection Events dashboard to check the block reason and adjust the inspection policy as needed
C. Use the packet tracer tool to determine at which hop the packet is being dropped
D. Use the show blocks command in the Threat Defense CLI tool and create a policy to allow the blocked traffic

Show Suggested Answer

Suggested Answer: A 🗳️

by Baumb at Feb. 12, 2023, 1:03 p.m.

Comments

Submit Cancel

TECH3K3

3 weeks, 2 days ago

Selected Answer: B

Anyone who selected "A" doesn't use the FMC. How can you use packet tracer to let you know where the traffic is being blocked? You can't. It can tell you if the packet is allowed or dropped, but not where it's been blocked. Connection Events can let you know what rule is blocking access.

upvoted 1 times

...

tinyJoe

5 months, 3 weeks ago

Selected Answer: A

i have no idea about "inspection policy". in this situation, the reason that blocks dns query is definitely ACP or intrusion policy. I choose A.

upvoted 2 times

...

Doris8000

10 months, 1 week ago

Same question question as 301 where the packet-capture is not an option so the correct answer is B.

upvoted 1 times

...

MB2222

1 year, 1 month ago

This question is a crazy since the wording sucks. The question will try to trick you to pick the capture tool using for troubleshooting based on the so called key word "real packets". Well, the connection event viewer uses real packets as well but with a delay of 5 min I guess (default settings). To answer the question in real live scenarios, most of us will go first on the connection event viewer to see what is dropping in particular and from there adjust the ACP. So, as a result I will go for answer (B) as well, since this might be a regular way to troubleshoot, first. As an addition to that you still might want to use the packet capture to analyze "real TIME* traffic.

upvoted 1 times

...

pr0fectus

1 year, 8 months ago

Selected Answer: B

Troubleshooting Steps: 1-Event Logging 2-Check Traffic Flow 3-Debugging 4-Buffer Logging So this should be starting at the connection events first. So I'd go with - B.

upvoted 3 times

...

bassfunk

1 year, 10 months ago

Selected Answer: A

The key words "Real Packets" makes me think packet capture. I'd go with A.

upvoted 2 times

gwb

1 year, 3 months ago

real packets - yeah packet capture sounds like it. I would go with B because connection event is REAL traffic as well to unblock/block the traffics

upvoted 1 times

...

aaInman

1 year, 10 months ago

Selected Answer: A

Artificial Intelligence says "A" gathered from 40 sources: "The engineer should use the packet capture tool to check where the traffic is being blocked and adjust the access control or intrusion policy as needed. This is option A. The packet capture tool can be used to capture and analyze real DNS packets to determine where the traffic is being blocked. Once the source of the blockage is identified, the engineer can adjust the access control or intrusion policy as needed to allow DNS traffic to pass through to the servers in the DMZ."

upvoted 3 times

d0980cc

2 months, 2 weeks ago

I asked Grok if B could be an option. Using Connection Events is a solid initial troubleshooting step, especially if the engineer suspects a policy misconfiguration (e.g., an ACP rule blocking DNS traffic). It’s less invasive and quicker than a packet capture, making it viable for a first pass. However, if the Connection Events don’t provide enough detail—such as when traffic isn’t logged, or the issue lies outside policy enforcement (e.g., packet drops due to interface errors)—then a packet capture would be the next step to analyze the real DNS packets directly. So, yes, Connection Events in the dashboard can be a viable answer, particularly as a starting point, but they might need to be supplemented with packet captures for deeper troubleshooting.

upvoted 1 times

...

bassfunk

1 year, 10 months ago

Selected Answer: B

B sounds like the very first step you would take and will tell you why the packet was dropped and the rule that dropped it. Its the one that makes the most sense.

upvoted 1 times

...

bobie

2 years ago

Selected Answer: B

Of course, B, do you want to make your life easier when it comes to troubleshooting? You only need to look at the event logs to discover what happened to the session.

upvoted 1 times

...

Gabranch

2 years, 1 month ago

Selected Answer: C

A - A Pcap doesn't tell me which rule is dropping the packet B - Connection events helps to diagnose, but it is likely an ACP (not Inspection) that needs adjusting if ALL DNS requests are hampered. D - lol C - Packet tracer will show whether it's a NAT issue or ACP block issue or route issue.

upvoted 1 times

Gabranch

2 years, 1 month ago

Changed to A - Packet Capture with trace will diagnose.

upvoted 2 times

...

Cokamaniako

2 years, 1 month ago

You can use packet capture tool due "The hosts cannot send DNS queries to servers in the DMZ" The answer is B

upvoted 1 times

...

THEODORABLE

2 years, 1 month ago

Hmmm, I though B at first but now I lean towards A-- as I would check the connection event log first to see what was going on.....but then I re-read the question. It states adjusting the inspection policy in result of the observation. Do they mean the Intrusion inspection or the Access control list? so much ambiguity- I never want to work with these people, ambiguity is one of my pet peeves!

upvoted 2 times

...

Initial14

2 years, 2 months ago

Selected Answer: B

You can see block action in connection events. Example: Reason: URL Block Sec. Inteligence category: URL Malicious . So connections events

upvoted 1 times

...

Joe_Blue

2 years, 3 months ago

Selected Answer: A

A. Use the packet capture tool to check where the traffic is being blocked and adjust the access control or intrusion policy as needed. Using the packet capture tool on the Cisco FTD device is an effective method for troubleshooting connectivity issues. By capturing packets and analyzing them, the engineer can identify where the traffic is being blocked and adjust the access control or intrusion policy as needed. In this case, capturing the real DNS packets can help determine if the packets are being blocked by the FTD device or if there is an issue with the DNS server itself. Once the issue is identified, the engineer can make necessary adjustments to the device policies to allow the traffic to flow properly.

upvoted 1 times

...

freho

2 years, 4 months ago

Selected Answer: B

B is correct. You cannot see in a packet-capture why the packet has been dropped. Packet-Tracer sends a real packet, but its not the real DNS-Packet and also doesnt show the reason for beeing blocked if it is a security-intelligence or reputation/category deciscion

upvoted 2 times

freho

2 years, 4 months ago

Have to correct my post. B is NOT correct. The connection Events will not show the Intrusion-Events. Checking Connection Events, and then edit Intrusion Policy makes no sence. Going with A too.

upvoted 1 times

THEODORABLE

2 years, 1 month ago

YES BUT, if there is an IPS policy triggered, the connection log will get a connection event automatically whether logging the ACL policy or not. also true with file & malware policy triggers & Security Intelligence events.

upvoted 1 times

...

Baumb

2 years, 4 months ago

Selected Answer: A

I would go for A, since there is a trace option you can choose and you would use the real packet. https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html#anc34

upvoted 2 times

...