Why Does a Deployed Access Control Rule Show Zero Hit Counters?
An engineer defines a new rule while configuring an Access Control Policy. After deploying the policy, the rule is not working as expected and the hit counters associated with the rule are showing zero. What is causing this error?
Community Insight
It tests whether you know that FMC access control rules are enabled by default and that a zero hit counter means the rule's match conditions, such as the application signature, were never satisfied — not that the rule was left disabled.
In Cisco Secure Firewall Management Center, a newly created access control rule is enabled by default, so an all-zero hit counter after deployment points to a rule condition that no traffic can match — here, the wrong application signature selected in the rule. This page explains why A is correct and why the popular 'rule was not enabled' answer fails against documented FMC behavior.
Most candidates choose C ('the rule was not enabled'), assuming new access control rules start in a disabled state, but FMC creates new rules enabled, and logging (D) never affects hit counters either.
Community Discussion (15 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
An access control rule in FMC increments its hit counter only when a connection matches every condition in that rule, and only after the policy is deployed. If the engineer picked the wrong application signature — for example Facebook Games instead of Facebook — the rule is syntactically valid and deploys cleanly, but no real traffic ever satisfies its application condition, so the action never fires and the counter stays at zero. That fits the reported symptom chain precisely: a rule that is 'not working as expected' after deployment with no hits at all. Nothing else in the scenario is broken; the match criteria the engineer typed in are the problem.
Why the Other Options Are Wrong
Option C contradicts documented FMC behavior: new access control rules are created in an enabled state, so the engineer would have had to deliberately disable the rule for it not to be evaluated, and the question says the rule was simply defined and deployed. Option B describes a setting that does not exist — access control rules are scoped by source/destination security zones, networks, ports, applications and URLs, not by a 'source interface for Snort'; Snort interface selection belongs to intrusion/interface configuration. Option D confuses logging with matching: logging settings only control whether connection events are generated for traffic the rule already matched, so they cannot explain a zero hit counter.
Community Comment Notes
The better-reasoned comments favor the application condition: Initial14 argued that "Rules are enabled by default, only SNORT rules need to be enabled", and z6st2a1jv cited Cisco's configuration guide to state "When you create an access control rule, it is enabled by default." Silexis made the same point from cross-vendor experience, noting that for a rule added to an ACP "the default state is Enabled", while bassfunk openly admitted that "the answer could be A or C" before settling on C. Learners such as Joe_Blue and donciga picked C purely on the assumption that new rules start disabled, which the vendor documentation contradicts. Weighing the documented default state of new FMC rules is what breaks the tie in favor of A.
Official Reference
Exam Strategy
Read the symptom chain literally: a deployed rule with a zero hit counter means nothing matched, so look for a match condition (application, URL, user, zone) that no traffic satisfies. Also memorize FMC defaults — new access control rules are enabled — because 'the rule was disabled' is a favorite planted distractor.
Frequently Asked Questions
Why is option C (the rule was not enabled) wrong in Cisco FMC?
FMC creates new access control rules in an enabled state, so a freshly defined rule is already active; you would have to disable it manually for it to stop being evaluated.
Does logging have any effect on an access control rule's hit counter?
No. Hit counters increment whenever a connection matches the rule, while logging settings only control whether connection events are recorded for that already-matching traffic.