A CI job pushes results into a TestRail-class case repository using an engineer's own account. What goes wrong inside the repository, and what should it use instead?
answer
- whose name ends up on the outcome
- the job inherits all their reach
- offboarding breaks the build
- record-only, project-scoped, team-owned
basics
~20 sEvery automated outcome is attributed to that engineer, the pipeline inherits their full human reach across projects, and the job breaks when they change team or leave. Use a dedicated machine account holding only the capability to record results.
solid answer
~40 sA personal credential brings three problems, all of them inside the repository. **Attribution**: the trail and every recorded outcome now name a human who never ran the test, so nobody can tell automated output from that person's real manual work. **Reach**: the account carries whatever they can do by hand — authoring, closing cycles, several projects, sometimes administration — and the pipeline inherits all of it while exercising one capability. **Lifecycle**: when they move team or leave, routine offboarding disables the account and silently breaks a pipeline nobody remembers is coupled to a person. The fix is a dedicated machine account that exists for the job, holds record-result and nothing else, is scoped to the project it reports into, and is owned by the team rather than an individual.
go deeper
Say plainly that a pipeline should authenticate as an account created for the job, and name the immediate consequences of using your own: your name on machine output, and a broken build the day you leave.
Explain that the credential inherits the account's whole capability set and project reach, so the pipeline silently holds authoring and closing it never uses, and describe what a machine account narrows.
Demonstrate how you would detect personal credentials already in use across an inherited estate from the repository's own trail, and how you would cut pipelines over without a reporting blackout.
Argue where account ownership sits organisationally — which team owns the register, who revokes at short notice — and what standard makes a machine account the default rather than the exception.
## The account is what gets spent, not the credential A credential is only interesting for what the account behind it is allowed to do. A person's account in a case repository is shaped by that person's job: they read several projects, author cases in one or two, record results by hand during a manual pass, close cycles if they run a release, and in small installations they are quietly a project administrator because somebody had to be. **Every one of those capabilities is inherited by any job that authenticates as them**, and a reporting pipeline exercises exactly one. Where the credential is kept and how it is injected into the job is a pipeline concern with its own answers. This question is about the other end of the wire: what the account may do to the repository the moment the credential arrives. ## Three costs, all of them repository-side 1. **Attribution collapses.** Recorded outcomes and the change trail carry the account that wrote them. With a personal credential in the pipeline, a human name sits on machine output. Ask the repository who reported this failure and it answers with a person who was asleep. Worse, that person's genuine manual work becomes indistinguishable from the pipeline's, so the trail can no longer separate a considered human judgement from an automated push. 2. **Reach is the person's, not the job's.** The pipeline can now author definitions, close cycles, and read every project that engineer belongs to. None of that is exercised in normal operation, which is precisely why nobody notices it is there until something goes wrong with the job. 3. **The account has a human lifecycle.** People change team, take leave, and eventually go. Disabling a leaver's account is routine hygiene that no one connects to a build; the reporting step then starts failing, or worse, fails quietly, and the record silently stops being updated. | | A person's account in a pipeline | A dedicated machine account | |---|---|---| | Who the trail names | A human who did not run it | The pipeline that did | | Capabilities carried | Everything that person can do by hand | Record a result | | Project reach | Every project they belong to | The one project it reports into | | Survives a leaver | No | Yes | | Rotation | Entangled with a person's own credential | Scheduled, owned by the team | ## What a machine account is, concretely It is not a mysterious kind of login. It is an ordinary account that exists for a job rather than a person, and it has four properties worth insisting on: - **Named for its purpose**, so a reader months later can tell from the trail alone which pipeline in which project produced a given outcome. - **Holding one capability**: record a result. Not authoring, not closing, not administration. - **Scoped to the project it reports into**, so a leak from one team's pipeline does not reach another team's inventory. - **Owned by a team, not an individual**, with a written note of which pipeline spends it, so rotation and revocation have somewhere to start. ## The half-measures that do not count - **A shared team login.** It has all the attribution problems of a personal credential and adds one of its own: nobody owns it, so nobody rotates it and nobody can say who is still using it. - **An account an engineer created specially, under their own name.** It is still a personal account with a new purpose, and it still dies with their offboarding. - **A machine account granted administrator for now.** The word *now* does not survive contact with a backlog. If the narrowest available preset is wider than record-only, say so explicitly and monitor the surplus rather than quietly accepting it. ## Finding the ones you have already got In an estate you inherited, do not start by auditing pipelines — you will not find the ones nobody remembers. Read the repository instead: 1. List the accounts that have recorded outcomes recently and look at the shape of their activity. Machine traffic is unmistakable: bursts aligned to build times, activity at night and at weekends, volumes no person types. 2. For each human account showing that pattern, find the team and the pipeline behind it. 3. Issue a machine account per pipeline, cut them over one at a time, and watch for traffic still arriving on the old credential before you touch it. 4. **Disable rather than delete** the personal account's automation role, so the historical outcomes it wrote stay attributable to something a reader can look up. The end state is boring and that is the point: the trail says which pipeline reported what, the pipeline survives the people who built it, and the worst a leaked reporting credential can do is record a result somebody can correct.
- The team also wants the pipeline to create the cycle it reports into. Does that change your answer?Only a little. Creating a cycle is a separate capability from recording into one and from closing one, so grant creation if the pipeline genuinely opens its own cycle, and still withhold authoring and closing. Prefer reporting into a cycle a human or a scheduled job already opened, because a pipeline that opens a new one whenever it runs makes the project's cycle list unreadable within weeks.
- How would you find out today whether any pipeline is still pushing with a person's credential?Look from the repository side rather than auditing pipelines, because you will miss the ones nobody remembers. Recorded outcomes carry the account that wrote them, so search for human accounts with machine-shaped activity: bursts at build times, weekend traffic, volumes no person types. Trace each back to its team, issue a machine account for that pipeline, and only then disable the personal route.
saying these in an interview costs you the question
- Uses a personal token because it was the quickest thing to get
- Thinks a shared team login is the same as a machine account
- Assumes automated pushes are exempt from the audit trail
- Believes a reporting account needs administrator rights to work