intermediate
Secrets
Inject credentials through protected secret stores and scoped permissions rather than source code, logs, or build artifacts.
Delivery pipelines need credentials for registries, cloud APIs, signing, and deploy targets. Secrets should come from scoped stores with least privilege, masking, rotation, and environment protection—not from source code or logs.
| Pattern | Benefit | |---------|---------| | OIDC federation | Short-lived tokens without long-lived PATs | | Environment secrets | Scope by staging/production | | Protected branches | Limit who can read deploy credentials |
permissions:
id-token: write
contents: read
# Exchange OIDC for cloud role — no static key in repo
Forked pull requests and untrusted workflows must not receive production secrets. Mask values in logs and scan artifacts before upload.
On interviews: OIDC versus long-lived tokens, repository and environment scopes, protected branches, and secret exposure in forks or preview builds.
Common pitfalls: long-lived deploy tokens in CI are attractive incident targets; logs, artifacts, and preview builds leak secrets accidentally.
The trade-off is automation convenience versus blast radius when credentials are compromised.
Checklist:
- Prefer short-lived credentials.
- Scope secrets by environment.
- Prevent secret exposure in logs and artifacts.
- Block untrusted PR workflows from production secrets.