How to answer
How are credentials, API keys and other secrets managed?
The question is about the credentials your software runs on, not the password manager the team uses. Rotation is the part most likely to be aspirational, and the follow-up is always the date of the last one.
Application secrets are held in [a managed secret store] and injected at runtime; they are not present in source control, in container images, or in developer environments. Access is granted per service identity rather than per person, and read access is logged. Secrets are rotated [on personnel change and at least annually].
Square brackets are yours to fill in. FillTrust grades an answer like this confirmed in your documents when your documents support it.
- Answered from
- Your access control standard or engineering handbook, wherever it says where secrets live and who can read them.
- Evidence to attach
- Rarely anything. If asked, a screenshot of the secret store's access policy, never a list of what is in it.
- Where it is asked
- CAIQ v4.0SIG LiteISO 27001 Annex A
There are two answers hiding in this question and they belong to different systems. One is how humans store the passwords they use, which is a password manager and two-factor authentication and belongs to the access control questions. The other is how your running software gets its database password and its API keys, which is what this question is actually about. Answer the second, and say briefly that the first is covered elsewhere, so the reviewer does not have to ask twice.
The claim that matters is negative: secrets are not in the repository. Almost everything else in this answer is detail; that is the part a reviewer is checking. If it is true, say it plainly and say how it stays true, because "we do not commit secrets" is a policy and a pre-commit hook or a scanning job is a control. If it is not entirely true, say what is there and what is being done about it. A known credential in an old commit that you have identified and rotated is an incident you handled. One that a reviewer finds later is a different conversation.
Service identity beats shared credentials, and it is worth naming. "Each service reads its own secrets under its own identity" tells a reviewer that a compromised component does not hand over everything, and it is a much stronger sentence than any description of the storage technology. If you are not there yet, the honest version is that access is scoped per environment, which is weaker and still real.
Rotation is where this answer usually stops being true. Nearly every engineering handbook says secrets are rotated periodically, and rotation is disruptive enough that it often has not happened since the systems were built. Do not claim a cadence you do not keep. The answer that survives a follow-up names the events that definitely trigger rotation, and personnel departure is the one a reviewer cares about most, because the risk they are imagining is the engineer who left with a copy of the production database password in their terminal history.
Finally, do the sweep for the secrets that live outside the secret store, because they are the ones that get forgotten and they are exactly what a reviewer means to catch: tokens in the CI provider, signing keys for third-party webhooks, credentials pasted into a scheduled job, and the long-lived personal access token somebody created once to unblock a deploy and never removed.
How this one goes wrong
Specific to this question, not general advice.
- Answering about the password manager the team uses for SaaS logins. The question is about the credentials your software runs on, and the two are different systems with different risks.
- "Secrets are stored in environment variables" as a complete answer. That is where they are read from, not where they are kept, and it invites the follow-up about who can see the deployment configuration.
- Claiming rotation that has never happened. Rotation is the part of this answer most likely to be aspirational, and the follow-up is always the date of the last one.
- Forgetting the ones that are not in the secret store: the CI provider's tokens, the third-party webhook signing keys, the personal access token somebody created to unblock a deploy in March.