Courts IT is cutting the e-filing hostname to a new frontend pair. Which virtual-network change must be included so citizens reach the new endpoints?
Select an answer to reveal the explanation.
Short Explanation
DNS is the courthouse directory—if the address card still lists the old wing, citizens walk into an empty hallway. Cutting over e-filing means updating that hostname's DNS to the new frontends. Leaving DNS alone while you rearrange servers is how you get confused phone calls on Monday.
Full Explanation
Cutting a courts e-filing hostname to a new frontend pair requires updating the DNS record so the existing citizen-facing name resolves to the new frontend addresses (or to the load balancer that fronts them). Clients discover services by name; without a DNS change, browsers and integrations continue to reach the old endpoints even if new capacity is ready. Municipal cutovers usually also plan TTL reduction beforehand, validate certificates for the same hostname, and coordinate the change window—but the indispensable virtual-network naming change called out here is the DNS update.
Deleting the municipal certificate authority before the cutover window fails because destroying PKI trust does not retarget traffic and actively breaks TLS validation for many services, not only e-filing. Disabling load-balancer health checks so stale nodes stay in the pool forever fails the cutover goal and availability hygiene: unhealthy or decommissioned nodes would continue receiving citizens. Flushing only database transaction logs while leaving DNS unchanged fails conceptually—database maintenance does not change where the hostname points, so citizens never reach the new frontends.
Exam caveat: DNS propagation and resolver caching mean a record update is necessary but may not be instantaneous unless TTLs were lowered in advance. Still, among the options, only updating DNS actually directs the e-filing hostname to the new endpoints.
Operational check: before cutover lower TTL if policy allows; during cutover update the A/AAAA or alias record; verify public and internal resolvers return the new addresses; confirm HTTPS to the hostname lands on the new pair; and only then drain or decommission old frontends after health and traffic metrics look correct.