1Y0-241 · Question #120
Scenario: To receive data alerts for failures, a Citrix Administrator is configuring SNMP on the Citrix ADC. The administrator is confident that the manager, alarms and SNMP traps are configured…
The correct answer is B. The community name was NOT configured in the Citrix ADC SNMP trap destination settings. See the full explanation below for the reasoning.
Question
Scenario: To receive data alerts for failures, a Citrix Administrator is configuring SNMP on the Citrix ADC. The administrator is confident that the manager, alarms and SNMP traps are configured correctly. The following week, there is a Citrix ADC-related outage and the administrator does NOT receive any alerts. What could be the reason for this alert failure?
Options
- AThe Citrix Web App Firewall is blocking the alerts from going out.
- BThe community name was NOT configured in the Citrix ADC SNMP trap destination settings.
- CThe Citrix ADC only has standard licensing.
- DThe Citrix ADC is configured for SNMP version 1.
How the community answered
(53 responses)- A13% (7)
- B77% (41)
- C6% (3)
- D4% (2)
Community Discussion
6B is your answer. When you configure SNMP traps on the Citrix ADC, the community name in the trap destination settings is what ties the trap to the right manager, and if it is missing, the ADC has nowhere authenticated to send those alerts, so they silently drop even when everything else looks correct. Spin up a lab, intentionally leave the community name blank, trigger a trap condition, and watch your SNMP manager sit quiet while the ADC logs show the event happened.
The community name is the piece people most often skip because it feels redundant after you have already set up the manager and the alarms, but the trap destination config on the ADC treats it as a separate required field. If that field is blank or mismatched, the ADC will not authenticate the trap against the manager and the alert dies silently, which is exactly the kind of failure that looks like everything is configured correctly. The Web App Firewall does not inspect or block internal SNMP trap traffic on the ADC itself, so A is a distractor, and standard licensing supports SNMP just fine. SNMPv1 in option D would be a concern in some environments but the version alone does not cause this specific silent failure pattern the way a missing community name does.
Yeah B is definitely the one, the community string is what the SNMP manager uses to authenticate and match the trap source, so if that field is blank in the trap destination config the ADC will drop those alerts right on the floor even if everything else looks perfect.
Community name missing from trap destination is the classic gotcha, B is right.
Our group keeps landing on D, SNMPv1 just does not support trap authentication properly.
Anjali, you are right that SNMPv1 trap authentication is weak, but that actually points toward B, not D. SNMPv3 is the version that introduced message-level authentication for traps using HMAC, which is the feature the question is testing, and that lines up with option B.