The correct option is Encrypt the secret with GPG, commit the encrypted file to the repository, and keep the decryption passphrase as a GitHub secret.

This method avoids the repository secret size limit because the large value is stored as ciphertext in the repository while only a small passphrase is kept in GitHub Secrets. During the workflow run you decrypt the file using the passphrase, so the plaintext exists only at runtime and is never stored as a large secret. This keeps the sensitive material encrypted at rest, allows you to review changes to the encrypted blob without exposing its contents, and lets you rotate the passphrase by updating the secret and re-encrypting as needed.

Store the credential in Google Secret Manager and retrieve it during the workflow run is not the most appropriate choice for this scenario because it adds an external dependency and still requires provisioning secure access from GitHub to the cloud. You would need additional setup such as credentials or federation, which does not directly solve the problem of handling a single oversized value within the workflow repository context.

Place the entire 60 KB value directly into a repository secret to bypass the limit will not work because it exceeds the documented size limit for a single secret and GitHub will reject it.

Split the large value across several repository secrets and concatenate the parts in the workflow is brittle and hard to manage. It increases the risk of exposure, complicates rotation, and goes against recommended practices for handling large sensitive files.

Full AWS Practitioner Certification Question