A blueprint asks how end-to-end encryption principles apply to APIs for a municipal microservice. Which focus stays in scope?
Select an answer to reveal the explanation.
Short Explanation
Stay on the API envelope—TLS for the request and response—not the Wi-Fi cipher or the branch VPN. Those are other exams’ playgrounds.
Full Explanation
For municipal microservices, end-to-end encryption principles applied to APIs focus on protecting request and response confidentiality (and integrity) with TLS on the API path. That keeps tokens, tenant identifiers, and civic payloads private between clients and the intended service identity. Switching and wireless controls may matter elsewhere in the campus design but are out of scope when the blueprint asks how encryption principles apply to APIs.
Selecting 802.11 encryption ciphers for the public Wi-Fi SSID near the data center fails scope—it does not secure the JSON API hop the microservice exposes. Tuning IPsec transform sets for a branch office VPN unrelated to the JSON clients likewise misses the API path under discussion. Enabling MACsec only on access ports that never carry the API traffic fails to protect the messages the blueprint actually asked about.
Exam caveat: defense in depth can still use MACsec or IPsec on other segments, but the DEVCOR API-encryption answer centers on HTTPS/TLS for the application protocol. Hostname verification and sound cipher suites remain part of “TLS done right” for civic services.
Operational check: verify service mesh or ingress policies enforce TLS for the microservice listeners that face integrations, independent of guest Wi-Fi cipher choices or branch VPN transform sets.