A hotel group is adding member Wi-Fi at a new site through the Meraki Dashboard API in Python. The build must place the SSID's clients on VLAN 20, block them from the card-payment subnet, and preserve the existing allow rule that opens everything else. Which sequence of Meraki API operations satisfies all three requirements?
Select an answer to reveal the explanation.
Short Explanation
Two details decide the outcome here: the SSID must actually carry VLAN 20, and Meraki's firewall endpoint takes the whole rule list every time you save it. The rules then run from the top down, so a deny saved under a broad allow never fires. Get either wrong and the card subnet stays open.
Full Explanation
Meraki keeps three separate objects that your script has to touch in the right order. VLAN definitions live on the appliance, so VLAN 20 must exist before an SSID can carry it, and the SSID object holds the VLAN field that tags client traffic. Firewall rules are stored as one ordered array on the network, and the update endpoint replaces that array with whatever you send, which is why you send the complete list back with your deny entry positioned above the existing allow. Evaluation runs top down and stops at the first match, so appending the deny at the end fails because a broad allow above it matches the traffic first. Leaving the SSID untagged fails because untagged frames ride the native VLAN instead of VLAN 20. Sending only the new rule fails because a partial array silently drops the entries you left out, including the allow that keeps everything else flowing. One caveat: the saved list may contain system rules you did not author, so read them back instead of assuming. A practical check: issue a GET after the update and confirm the rule count, their order and where your deny landed.