1Y0-230 · Question #118
Scenario: A Junior Citrix Administrator needs to create a Content Switching virtual server on a NetScaler high availability (HA) pair. The NSIP addresses are 192.168.20.10 and 192168.20.11. The…
The correct answer is B. The junior administrator connected to the NSIP of the secondary NetScaler in the HA pair. See the full explanation below for the reasoning.
Question
Scenario: A Junior Citrix Administrator needs to create a Content Switching virtual server on a NetScaler high availability (HA) pair. The NSIP addresses are 192.168.20.10 and 192168.20.11. The junior administrator connects to NSIP address 192.168.20.10 and saves the changes. The following day, a Senior Citrix Administrator tries to test the new Content Switching virtual server, but it is NOT working. The senior administrator connects to the HA pair and everything the junior administrator configured is gone. Why did the NetScalers lose the newly added configurations?
Options
- AThe NetScaler appliances are NOT at the same firmware version
- BThe junior administrator connected to the NSIP of the secondary NetScaler in the HA pair
- CBoth NetScalers in the HA pair restarted overnight, losing the configuration
- DThe junior administrator made the changes and did NOT force a failover to save the configuration
How the community answered
(28 responses)- A7% (2)
- B79% (22)
- C4% (1)
- D11% (3)
Community Discussion
5
Orla P.May 3, 2026The answer is B. In a NetScaler HA pair, configuration changes must always be made on the primary node, because the primary is the one that pushes its running config down to the secondary during synchronization, not the other way around. When the junior admin connected to 192.168.20.10 and made those changes, that IP happened to belong to the secondary NetScaler, so the config never got pushed to the primary. Once a sync event occurred, the secondary had its config overwritten by the primary's unchanged state, and everything the junior admin built was gone. The lesson here for the exam and for real life is the same: always confirm which node is primary before you touch anything, either through the dashboard status banner or by running "show ha node" from the CLI, because the NSIP addresses alone tell you nothing about which appliance is currently holding the primary role.
Luis F.May 5, 2026Solid breakdown, just worth adding that if the admin had checked the HA sync status after making changes and seen a successful sync listed in the logs, that would have been the first clue that something was off, because a secondary does not push outbound syncs, only the primary does.
Lena V.May 16, 2026I initially leaned toward D because forgetting to force a failover seems like a classic junior mistake, but then I remembered that the whole point of HA is that the primary handles all writes and syncs to the secondary automatically, so the real issue is that the junior connected to the secondary NSIP (192.168.20.10 was the secondary that day), and any config changes made directly on the secondary node are not saved or synced since only the primary propagates config to its peer.
Luis F.May 23, 2026Yeah B is right, you can't config the secondary node directly.
Orla P.May 25, 2026That tracks, the secondary node pulls its config from the primary, so any direct edit you make there just gets overwritten on the next sync.