The public API Management gateway still serves only the default *.azure-api.net host and allows a weak TLS version. What should the security engineer configure?
Select an answer to reveal the explanation.
Short Explanation
APIM needs its own custom domain, cert, and min TLS—same idea as any public gateway. Policy XML and subscription-key catalogs don’t harden the listener.
Full Explanation
A public API Management gateway that still serves only the default *.azure-api.net host and allows a weak TLS version needs hostname and protocol hardening on APIM. Configure a custom domain, bind a TLS certificate, and set the minimum TLS protocol on the gateway so canal partners hit a trusted name with an acceptable TLS floor.
Exporting a full catalog of APIM backend auth, named values, and subscription-key recommendations fails by concept: those are broader security-configuration topics and do not replace custom-domain/TLS hardening. Authoring only inbound policy XML for rate limits while leaving the default hostname and TLS floor unchanged fails by concept: rate-limit policies do not raise TLS versions or bind custom domains. Disabling HTTPS so clients fall back to HTTP fails by concept: that weakens the public gateway instead of hardening it.
Exam caveat: for public APIM TLS items, prioritize custom domain, certificate, and min TLS—not policy XML dumps or exhaustive APIM catalogs. Operational check: bind the custom domain and certificate on APIM, set minimum TLS to the documented floor, confirm clients using the custom host succeed on strong TLS, and verify weak TLS handshakes fail.