A municipal security script must create a host network object on FDM for a new kiosk subnet gateway. Which request matches the official create construction?
Select an answer to reveal the explanation.
Short Explanation
Creating a host or subnet object is a POST with the typed body—type, subType, name, and value. GET only lists what already exists; PUT rewrites an id you already have.
Full Explanation
Creating a host network object on FDM for a municipal kiosk subnet gateway follows the Networks object resource contract. The official create construction is POST /object/networks with a body that includes type networkobject, a subType such as HOST or NETWORK, plus name and value for the address or prefix. That typed payload tells FDM what kind of object to materialize in the pending configuration model so later access rules can reference it by identity.
GET /object/networks alone fails because listing enumerates existing objects; it does not invent a missing host. PUT /object/networks/{objId} with only a new access-rule name and no network fields fails create semantics: PUT targets an existing object id for update, and access-rule naming is not a substitute for networkobject fields. POST /operational/nat-rules with the host address buried in a NAT exemption comment fails because NAT operational resources are not the network-object create path, and comments do not register reusable host objects.
Exam caveat: after a successful POST, the object still sits in the staged model until an operational deploy; create success is not the same as data-plane enforcement.
Operational check: POST the networkobject, capture the returned id/UUID and name, GET /object/networks (or GET by id) to confirm the object appears with the expected value, then proceed to rule binding and deploy.