Detent PointTurning on backup encryption is one clause on the BACKUP statement, and it works immediately — the file is encrypted, the job succeeds, the monitoring stays green. What that green does not tell you is whether the certificate that encrypted it has itself been backed up and can be put on the server where you will one day need to restore.
An encrypted backup you cannot decrypt is worse than no backup, because it looks like protection right up until the restore. The certificate, not the .bak, is the part that has to survive.
The first is about the instance taking the backups: does it hold a backup-encryption certificate, and has that certificate’s private key been backed up somewhere separate? test_sql_backup_encryption_readiness answers that, read-only and free — a present-but-never-exported certificate is the common gap.
The second is about a specific file: is this backup restorable here? Pointed at a .bak with -BackupPath, the same command reads the backup header, finds the thumbprint the file was encrypted under, and reports whether that certificate is present on this machine — before you commit to a restore that would otherwise fail partway.
Both checks read and report; neither changes a binding, a certificate, or a database. That is deliberate — the point is to find the gap on an ordinary Tuesday, on any instance you manage, rather than during an incident. In live testing the -BackupPath check correctly called a backup not-restorable on a server missing the certificate, then restorable on the same server once the certificate was present.