300-420 Question #38: Real Exam Question with Answer & Explanation

Question

Drag and Drop Question Drag and drop the properties from the left onto the protocols they describe on the right. Answer:

Explanation

The question tests knowledge of NETCONF and RESTCONF protocols, specifically their underlying transport mechanisms and key features like candidate configuration and transaction support.

Approach. The correct interaction involves dragging the properties from the left pane to the appropriate protocol targets on the right pane. The correct mappings are: - Drag 'SSH-based' to NETCONF. NETCONF (Network Configuration Protocol) is designed to run over a secure transport layer, most commonly SSH (Secure Shell), for authentication and encryption. - Drag 'built to support candidate configuration' to NETCONF. A key feature of NETCONF is its robust transaction model, which includes explicit support for a 'candidate configuration' datastore. This allows network device configurations to be modified, validated, and staged before being atomically committed to the running configuration. - Drag 'HTTPS-based' to RESTCONF. RESTCONF (RESTful Network Configuration Protocol) leverages HTTP/HTTPS as its underlying transport protocol, aligning with its RESTful architectural style. - Drag 'lacks support for two-phase commit transactions' to RESTCONF. While complex orchestration systems might implement transaction-like behavior using RESTCONF, the protocol itself, being REST-based and typically stateless, does not natively support explicit two-phase commit transactions or a distinct candidate configuration datastore in the same manner as NETCONF. Changes are often applied directly or require external orchestration for transactional integrity.

Common mistakes.

• common_mistake. A common mistake would be to associate 'HTTPS-based' with NETCONF or 'SSH-based' with RESTCONF. NETCONF primarily uses SSH for secure transport, while RESTCONF uses HTTPS. Another error would be to assign 'built to support candidate configuration' to RESTCONF, as this is a defining feature of NETCONF's transaction model. Conversely, attributing built-in two-phase commit transaction support to RESTCONF is incorrect, as it typically relies on simpler request-response semantics and external orchestration for such capabilities, unlike NETCONF's inherent support for candidate configurations and atomic commits.

Concept tested. This question tests the understanding of the fundamental characteristics and differences between NETCONF and RESTCONF protocols, including their underlying transport mechanisms, configuration management models (e.g., candidate configuration), and transaction capabilities.

Reference. null

No community discussion yet for this question.