TLS Certificate Transparency is a system where browser vendors require TLS Certificate Authorities to publish information about all of their TLS certificates in cryptographically validated logs, which are generally run by third parties (see also Wikipedia). This raises the question of how clients (generally browsers) interact with Certificate Transparency. As far as I can tell, it depends on how thorough a client wants to be about verifying that a TLS certificate really is in a given CT log.
The current version of Certificate Transparency is described in RFC 9162. Following RFC 9162, when a client gets a TLS certificate issued by a participating CA (which is all of them that want to work with Chrome and Safari), it will also receive (in one way or another) some number of Signed Certificate Timestamps (SCTs). Each SCT is a promise by some CT log to include the certificate (broadly speaking) in the log within a time interval specified by the log, and is signed by the CT's private key. A garden variety client can verify the SCT signatures (for CT logs that it knows of and accepts) and stop there. Generating a valid SCT requires (some) control of that log's private key and its activities, and if the key or the log is compromised, there's potentially not lots of point in going further.
(A client may also receive additional CT related information from the TLS server, up to all of the information it needs to validate things more thoroughly, See TLS Client in the RFC.)