A developer is tasked with configuring an application-specific SSL certificate for a civic REST API. Which action stays in scope for that application HTTPS requirement?
Select an answer to reveal the explanation.
Short Explanation
This ticket is about the shop’s own front-door lock—HTTPS for the API—not the campus turnstile or the WAN tunnel. Put the right certificate on the application listener.
Full Explanation
Configuring an application-specific SSL certificate for a civic REST API stays in the HTTPS listener/ingress scope: present a hostname-matched certificate on the API’s HTTPS listener or ingress. That is the DEVCOR application-security concern for API TLS identity—not campus access-control or link encryption features that never terminate the client’s HTTPS session to the app.
Tuning 802.1X EAP methods on the access switch facing the API servers fails scope: useful for port access, irrelevant to the API’s server certificate. Enabling MACsec on a data-center uplink that carries unrelated VLAN traffic fails the same way—link encryption is not application certificate configuration. Building an IPsec site-to-site tunnel solely so browsers can open JSON endpoints misplaces the control; browsers expect TLS to the API hostname.
Exam caveat: ingress or service-mesh TLS with the correct secret is still “on the API’s HTTPS path.” Do not answer with switching features when the stem asks for application SSL.
Operational check: from a citizen client network path, confirm TLS terminates with the app hostname’s cert at the documented listener/ingress and that MACsec/802.1X toggles do not change that certificate presentation.