Data Serialization practice questions

yaml.read_multi()

Why it fails: Incorrect. read_multi does not exist in PyYAML.

yaml.load_all()

Why it fails: Incorrect. yaml.load_all() without 'safe_' uses the full loader, which can be vulnerable to arbitrary code execution if parsing untrusted data.

yaml.parse_documents()

Why it fails: Incorrect. parse_documents is not a standard function in the PyYAML library.

pickle

Why it fails: Incorrect. Pickle serializes and deserializes Python object structures into binary bytes, not XML.

yaml

Why it fails: Incorrect. The yaml module (PyYAML) processes YAML formatted data.

json

Why it fails: Incorrect. The json module is used for encoding and decoding JSON objects, not XML.

corejson

Why it fails: Incorrect. corejson is not a standard Python JSON processing library.

xmljson

Why it fails: Incorrect. xmljson is designed for converting XML to JSON/Dict structures, not high-precision JSON parsing.

fastjson

Why it fails: Incorrect. fastjson does not natively offer decimal precision parsing for Python.

Forward slash (/)

Why it fails: Incorrect. Forward slashes are not used as separators.

Semicolon (;)

Why it fails: Incorrect. Semicolons are not used as standard separators in JSON.

Period (.)

Why it fails: Incorrect. Periods are used for floating-point numbers.

Three hashes (###)

Why it fails: Three hashes mark a comment, not a document boundary, so they cannot signal the start of a YAML stream. The temptation is understandable: hash-prefixed lines are visually prominent and often used as section headers in configuration files. The correct marker is three hyphens (---), which delimits document streams in multi-document YAML.

Three slashes (///)

Why it fails: Three slashes carry no meaning in YAML; a document stream begins with three hyphens (---). The slashes are tempting because comment markers and separators look similar, but only --- starts a document, while ... ends one.

Three dots (...)

Why it fails: Three dots (...) mark the end of a YAML document, not its beginning. It is tempting because it is a genuine YAML directive, but it terminates a document stream; the opening marker is three hyphens (---).

The parser throws a ScannerError due to invalid numeric formatting.

Why it fails: Incorrect. Octal representation with leading zero is valid in YAML 1.1.

As a string literal matching the exact characters.

Why it fails: Incorrect. Unquoted numbers are parsed as numeric types, not strings.

As a floating-point number with zero prefix.

Why it fails: Incorrect. Floats require a decimal point or exponential notation.

TypeError

Why it fails: Incorrect. TypeError is a Python runtime type error, not a YAML parsing scanner error.

YAMLSemanticError

Why it fails: Incorrect. YAMLSemanticError is not the standard PyYAML exception for syntax issues.

JSONDecodeError

Why it fails: Incorrect. JSONDecodeError is raised by the json module, not PyYAML.

Storing unencrypted credentials directly inside YAML global anchors.

Why it fails: Incorrect. Credentials should never be hardcoded insecurely.

Relying on yaml.load() to automatically execute embedded Python object constructors.

Why it fails: Incorrect. Executing arbitrary constructors is dangerous and discouraged.

AttributeError

Why it fails: Incorrect. AttributeError occurs when accessing non-existent attributes.

KeyError

Why it fails: Incorrect. KeyError is raised when looking up missing dictionary keys.

ScannerError

Why it fails: Incorrect. ScannerError is raised by PyYAML, not json.

Support for numeric floating-point values

Why it fails: Both formats natively represent integers and floating-point numbers.

Support for boolean data types

Why it fails: Both JSON and YAML support boolean data types natively.

Support for nested arrays

Why it fails: Both formats natively support nesting arrays and lists.

YAML anchors and aliases will be automatically preserved as native references in the resulting JSON output.

Why it fails: PyYAML resolves anchors and aliases during parsing, producing shared Python object references; json.dump then serialises each occurrence as a full duplicate, since JSON has no anchor or alias syntax. It is tempting because anchors do reduce YAML file size, and would be correct if the target format also supported reference syntax.

JSON supports multi-document streams natively in a single file just like YAML.

Why it fails: JSON has no multi-document stream syntax; json.load parses exactly one value, so a YAML file containing several documents separated by --- must be split and converted individually. It is tempting because YAML's --- separators look like ordinary delimiters, and multi-document YAML would be correct input for yaml.safe_load_all.

interface_name: ""

Why it fails: An empty string is not equivalent to null. In JSON, null and an empty string are distinct types. Using an empty string would misrepresent the original JSON null, causing the automation script to treat it as a present but empty string rather than an absent or null value. This could lead to incorrect configuration decisions.

interface_name: null

Why it fails: While 'null' is a valid YAML scalar that represents a null value, the scenario asks for the representation that preserves the distinction between a missing key and an explicit empty value. Using the string 'null' without quotes is parsed as a null value, but it is less idiomatic than the tilde. However, the question likely expects the canonical YAML null, which is ~. The other options are incorrect for different reasons.

interface_name:

Why it fails: A key with no value in YAML is parsed as having a null value, but it does not explicitly preserve the distinction between missing and null in a way that is as clear as the tilde. In YAML, a key followed by a colon and no value is typically interpreted as null, but it is ambiguous and may be treated as an empty value in some parsers. The tilde is the explicit null representation.

speed = int(data["interface-speed"])

Why it fails: Attempting to convert the string "10G" directly to an integer with int() will raise a ValueError because of the 'G' suffix. The string is not a valid integer literal. The engineer must first strip the non-numeric characters before conversion. This approach would fail at runtime.

speed = int(data["interface-speed"].strip("G"))

Why it fails: Using strip("G") removes all leading and trailing 'G' characters, but it does not multiply by 1000 to convert to megabits. It would return 10 for "10G", which is in gigabits, not megabits. The engineer needs megabits per second, so multiplication is necessary.

speed = int(data["interface-speed"][:-1]) * 1000

Why it fails: Slicing off the last character assumes the unit is always a single character. While "10G" has a one-character unit, this approach is brittle and would fail for values like "100M" or "2.5G". It also does not handle potential whitespace. The rstrip method is more robust for removing a specific suffix.

JSON

Why it fails: Standard JSON does not allow comments or trailing commas. It is a strict format defined by RFC 8259, and parsers reject any deviation. While some libraries offer relaxed modes, the format itself does not support these features. The scenario explicitly requires comments and trailing commas, so JSON alone does not satisfy the team's requirements.

YAML

Why it fails: YAML is not a subset of JavaScript object notation; in fact, YAML 1.2 is a superset of JSON. YAML supports comments and does not use commas at all, so trailing commas are not applicable. The requirement for a strict subset of JavaScript object notation is not met by YAML, making it an incorrect choice for this scenario.

XML

Why it fails: XML is a markup language, not a subset of JavaScript object notation. It supports comments, but its structure is element-based rather than object-based, and it does not use trailing commas. The scenario specifically asks for a format that is a strict subset of JavaScript object notation, which XML is not, so it does not fit.

Null

Why it fails: JSON null represents the absence of a value and is decoded to Python None. The token 100 clearly carries a value, so it cannot be null. If the script tested for None here it would skip the interface description update, leaving the SRX configuration unchanged even though the API returned usable data.

String

Why it fails: A JSON string must be enclosed in double quotation marks, as in "100". Because the REST API response contains the bare token 100, the decoder produces a numeric Python object, not a str. Treating it as a string would force unnecessary quoting in the Junos CLI command and could produce a configuration error.

Boolean

Why it fails: JSON booleans are limited to the literal tokens true and false, and Python represents them as bool. The token 100 is not one of those literals, so it cannot be decoded as a boolean. Believing otherwise would lead the script to make a wrong logical decision when handling the SRX interface description.

management_ip: [192.0.2.10, 192.0.2.11]

Why it fails: This flow-style sequence is valid YAML and also produces a two-element list, but the scenario specifies that the second address must be added to the existing block-style file while keeping the same representation. Mixing flow style into a block-style document is inconsistent and is not the representation the engineer wants for the Junos facts file.

management_ip: 192.0.2.10, 192.0.2.11

Why it fails: A plain scalar containing a comma is still a single string in YAML, not a list. The PyEZ script would treat the entire value as one management address, so the Junos device would receive an invalid address and the second address would never be configured. The dash indicator is required for a true sequence.

management_ip: 192.0.2.10 192.0.2.11

Why it fails: This is not a valid YAML sequence because the list items lack the dash indicator. A YAML parser will raise an error on the second scalar line, causing the PyEZ script to fail before it can read any Junos facts. The engineer must use the dash form to represent a list.

CSV

Why it fails: CSV is a flat, tabular format with no native support for nested hierarchy, so it cannot represent Junos interface configuration with multiple nested units and address families. Attempting to force the configuration into rows and columns loses the parent-child relationships that the script needs. CSV is suitable for simple tabular telemetry exports, not for parsing hierarchical Junos configuration.

JSON

Why it fails: JSON cannot represent Junos configuration hierarchy natively because it requires quoted keys and does not support comments, and a raw `backup.conf` is a curly-brace configuration file, not JSON. Loading it with `json.load()` raises a JSONDecodeError, so the script would fail before any interface data could be read. JSON is useful for API payloads but not for parsing native Junos configuration text.

YAML

Why it fails: Although YAML is human-readable and supports hierarchy, a native Junos configuration file uses curly braces and semicolons with Junos-specific syntax, which is not valid YAML. A YAML parser would raise a scanner or parser error on tokens such as `interfaces {`. YAML is appropriate for authoring automation inputs, but it does not directly deserialize a Junos `show configuration` file.

JSON natively supports binary data through a dedicated base64 scalar type.

Why it fails: JSON has no binary type; binary data must be encoded as a base64 string and decoded by the consumer, which loses the type distinction. YAML 1.1 defines a `!!binary` tag for base64-encoded binary scalars, but JSON does not. Claiming JSON has a native binary scalar type is incorrect and could lead to faulty assumptions when serializing certificates or keys.

JSON supports comments, which makes it easier to document inventory fields inline.

Why it fails: JSON does not support comments in its specification, and adding them causes parsers to raise errors. Some tools accept JSON5 or JSONC extensions, but those are non-standard and not universally supported. YAML, by contrast, allows comments with the `#` character. Claiming JSON supports comments misstates a fundamental limitation that affects how inventory files can be documented.

JSON is a superset of YAML, so any valid YAML document is also valid JSON.

Why it fails: The relationship is the opposite: YAML 1.2 is designed as a superset of JSON, meaning most valid JSON documents are also valid YAML. JSON is not a superset of YAML, and many YAML constructs such as anchors, comments, and unquoted strings are not valid JSON. This option reverses the compatibility direction and would mislead anyone choosing a format for interoperability.

ip_addresses = {192.168.1.1, 192.168.1.2}

Why it fails: This is Python set or dictionary notation, not YAML; braces with commas are invalid in a YAML block sequence. It would be the right structure when defining a flow-style mapping of key-value pairs, not an ordered list of IP addresses.

ip_addresses: [192.168.1.1: 192.168.1.2]

Why it fails: Colons inside flow brackets create a mapping, and the syntax is malformed for a sequence; YAML flow sequences use comma-separated values only. This form suits a flow mapping such as {key: value}, not an ordered list of addresses.

ip_addresses: * 192.168.1.1 * 192.168.1.2

Why it fails: YAML sequences require a hyphen followed by a space for each entry; asterisks denote aliases referencing anchors, so this parses as invalid syntax. Asterisks are correct when reusing a previously anchored node, not when declaring a fresh ordered list of addresses.

json.format(data, spacing=4)

Why it fails: No json.format function or spacing parameter exists in Python's json module; the call raises AttributeError. The module offers dumps with an indent argument, which is the correct choice when a formatted JSON string is required.

json.dump(data, indent=4)

Why it fails: json.dump writes serialised JSON to a file-like object, so it returns None rather than a string, failing the requirement to output a formatted JSON string. It is the right call when writing directly to an open file handle instead of capturing the result.

json.stringify(data, spaces=4)

Why it fails: Python's json module has no stringify function, and no spaces parameter exists; this is JavaScript's JSON.stringify, which takes a space argument. It would be correct only in a Node.js or browser script, not a Python script manipulating Junos JSON output.