In Apstra 5.1, property sets are structured data objects (YAML/JSON) used to hold values that templates can consume at render time. Their most common use is with configlets, where property set key/value pairs are referenced as variables inside the template so Apstra can perform variable substitution during configuration generation. This directly supports statement B.

Property sets are also designed to be reusable. A single configlet can reference more than one property set (for example, one set for NTP servers and another for syslog collectors), allowing clean separation of data domains and easier lifecycle updates. This supports statement E.

Operationally, when you bring design content into a blueprint, the blueprint must have the required supporting objects available. In Apstra workflows, configlets that use property sets require those property sets to be present in the blueprint context (commonly accomplished by importing the relevant property set(s) from the catalog into the blueprint as part of bringing in the configlet and its dependencies). This aligns with statement A as the blueprint-level outcome: the property sets used by an imported configlet are imported/available in the blueprint for rendering.

Statements C and D are incorrect because property sets are not limited only to configlets (they are also used with Analytics probes), and the syntax is not vendor-specific—Apstra uses standard YAML/JSON structures independent of NOS.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/apstra5.1/apstra-user-guide/topics/concept/property-set-datacenter-design.html

https://www.juniper.net/documentation/us/en/software/apstra4.2/apstra-user-guide/topics/concept/property-set-datacenter-design.html

https://www.juniper.net/documentation/us/en/software/apstra5.1/apstra-user-guide/topics/ref/configlet-examples.html