A NetOps team must automate consistent VLAN and interface changes on IOS XE with transactional rollback, clear separation of candidate and running state, and structured RPC operations over a secure channel. REST calls feel stateless and lack datastore concepts. Which NETCONF characteristic meets these controller requirements?

The correct characteristic is accurate because NETCONF over SSH combines encrypted transport with structured XML RPC messaging and formal datastores, allowing the controller to lock the candidate, stage VLAN and interface edits, run validate, then commit or discard with confirmed-commit rollback, which preserves consistency and separates intended from active state on IOS XE. The RESTCONF over HTTPS description fails by datastore concept because although it uses YANG and TLS for secure structured management, it maps operations to stateless HTTP verbs without native candidate staging, validate, and phased commit semantics, so it cannot meet the explicit transactional requirement. The direct running datastore edit description fails by transaction concept because immediate edits to running bypass candidate isolation and validation, meaning a partial VLAN change takes effect at once and recovery depends on manual reconfiguration rather than automatic rollback. The gNMI over TLS description fails by operation-model concept because while it is secure, YANG-based, and excellent for streaming telemetry and path-oriented Set updates, it relies on gRPC service calls rather than NETCONF lock, edit-config, validate, and commit workflows. As an exam caveat, treat any mention of candidate, validate, lock, and commit-confirmed as a strong discriminator for NETCONF even when other choices also mention YANG and encryption. As a practical check, inspect the server hello capabilities for candidate and validate, then test lock, edit-config to candidate, validate, commit, and confirmed-commit timeout on a lab IOS XE device to observe that running remains unchanged until commit succeeds.