Challenge 1: Authentication Works by Machine Name but Not by New
Hostname -- Solution Walkthrough

The most likely cause: Kerberos authentication requires a Service
Principal Name (SPN) registered in Active Directory for the exact
hostname being used to reach the site, bound to the account the
Application Pool runs under. The server's raw machine name very
often already has a default SPN registered automatically, which is
why authentication behaves normally through it. The new public
hostname added last week is a different name entirely from the
server's machine name, and unless someone explicitly registered an
SPN for it, Kerberos has no matching SPN to authenticate against
under that hostname. Because the site's authentication provider list
uses Negotiate, which silently falls back to NTLM when Kerberos
fails, the site doesn't outright break -- it just quietly downgrades
to the weaker NTLM protocol for that hostname, which is exactly the
kind of "behaves oddly" symptom (rather than a clean failure) this
scenario describes.

The command that would confirm/fix it:

setspn -A HTTP/newhostname.example.com DOMAIN\svc-webapp

(replacing newhostname.example.com with the actual new public
hostname, and svc-webapp with the actual account the Application
Pool's identity uses). Running setspn -L against the service account
first would also confirm whether the SPN for the new hostname is
actually missing, before adding it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can apply the SPN gotcha to a
realistic scenario -- recognizing "works by machine name, odd by a
newer custom hostname" as the signature symptom of a missing SPN
registration for that specific hostname, masked by Negotiate's
silent NTLM fallback, and knowing the actual setspn command that
fixes it.