September 8, 2026 · 7 min read
TL;DR: Automating something appears in fourteen options in this bank and is keyed twice. Both keyed cases automate a chore rather than a judgement: manual work categorisation, which the explanation calls non-value-added outright, and the generation of a status report a stakeholder asked for. The other twelve offer automated testing, automated tooling or advanced technology against stems describing a requirements drift, a user-perceived quality problem, a skill gap, or a schedule that can be compressed for free, and in each of those the tool never reaches the cause.
Tooling answers are seductive on this exam because they are the ones a competent engineer would actually propose in the meeting. They are concrete, they scale, and they sound like the modern answer. That is exactly the shape of a good distractor, and this bank uses it twelve times.
The two where the work itself is a chore rather than a judgement.
A project management office is optimising its portfolio and asks for advice on tracking what type of work each member does and how long it takes, proposing that people categorise and log their work in addition to actually doing it. Keyed is recommend an automated reporting tool where possible, since categorising the work by hand is non-value-added.
Read the distractor sitting directly next to it: recommend an automated reporting tool because recording the work is value-added. Same recommendation, opposite justification, and only one of them is keyed. The explanation says why: time spent tracking or recording work can be seen as non-value-added effort that does not directly benefit the customer's output.
That pair is the whole rule in miniature. Automation is keyed when it removes effort that was never producing value, and it is not keyed for being efficient in general.
The second keyed case is the same principle on a smaller scale. A stakeholder on an adaptive project would rather have a weekly status email than use the live dashboard, and one of two keyed answers is to check whether the report can be generated and sent automatically by the system. Generating a report nobody needs a human to assemble is a chore; deciding what the report should say is not.
Because it answers a question about correctness of build, and the stems ask about correctness of intent.
The CRM record makes the distinction unusually visible. Midway through a development project the software features are drifting from the client's requirements, and the schedule performance index has fallen from 1.05 to 0.85 while the cost performance index has fallen from 1.2 to 0.95. Four options: add a code review process to catch defects before testing; improve communication with stakeholders to refine requirements and expectations; introduce an automated testing tool to raise efficiency; revisit and adjust the schedule.
Keyed is the communication one, and the explanation names why the tooling options are there. Code review and automated testing are the instructive wrong answers because both are genuinely valuable and neither touches this cause: they raise confidence that the software works as built, which does nothing about the fact that what is being built is not what was asked for.
Both indices fell together, and the stem states the reason. A team building the wrong features faster, with higher confidence, is further from the goal, not closer.
| Stem's actual problem | Tooling option offered | Why it misses |
|---|---|---|
| Features drifting from requirements | Automated testing tool for efficiency | Verifies the build, not the requirement |
| Users complaining that quality slipped | Eliminate human error by automating testing | Finds only defects a machine was told to look for |
| Team lacks machine-learning expertise | Deploy automated tools to help with ML tasks | Leaves the capability outside the team |
| Schedule can be compressed by overlapping | Bring in advanced technology to automate parts | Spends money where a free option exists |
| Manual work categorisation demanded by the PMO | Automated reporting tool, work is non-value-added | Keyed: removes effort that produced no value |
It shows the limit of machine judgement stated in one clause.
An apparel brand owner faces rising social-media complaints that quality has slipped, and sets up an agile team told to put product quality ahead of everything. Eliminate human error by automating the testing is offered. Keyed is feed user focus group input into the product's development life cycle.
The explanation's reasoning is worth carrying into the exam room: the complaints come from users, so bringing user judgement into development throughout the life cycle catches quality problems before customers meet them, while automated testing only finds the defects a machine has been told to look for.
That last phrase generalises. Automation is excellent at the failure modes somebody already anticipated and encoded. The quality complaints in that stem are, by definition, about failure modes nobody anticipated, because if they had been anticipated they would already be in the tests.
Common trap: reading eliminate human error as an unambiguous good. It is written to be the most confident-sounding phrase in the option set, and it is wrong twice over in that record. It overstates what automated testing does, since a test suite relocates human judgement into the test design rather than removing it, and it targets a source of error the stem never blamed. The bank builds several distractors around absolute language of this kind, and its explanations consistently answer them by asking what the mechanism actually catches rather than what the phrasing promises.
When the capability has to remain after the project closes.
A team must integrate machine-learning features into an existing product but lacks the expertise. Deploy automated tools to help the team with ML-related tasks is offered, alongside partnering with a machine-learning firm and running a workshop. Keyed is launching targeted machine-learning training for the team.
The explanation turns on ownership: the features are being integrated into an existing product this team will go on maintaining, extending and debugging long after the project closes, so the capability has to end up inside the team rather than beside it.
There is a related record where the constraint does the elimination instead. A team's unfamiliarity with a new API is slowing integration, and the project manager must close the gap without raising the budget. Buying fast-track training and hiring an external consultant are both reasonable and both cost money the stem has ruled out, which leaves a collaborative problem-solving session that mobilises what different team members have each learned about different parts of the API. Same family of question, different eliminating clause, and neither one keys the tool.
When is automating something the keyed answer on the PMP exam? When the work being automated is non-value-added in itself. The bank keys recommending an automated reporting tool where possible, since categorising work by hand is non-value-added, and its explanation is explicit that time spent recording work does not directly benefit the customer's output. The bank also keys checking whether a status report can be generated and sent automatically, which is the same principle applied to a reporting chore.
Why is automated testing so often a distractor? Because it verifies that software works as built, and the stems that offer it describe projects building the wrong thing. In one record the features are drifting from the client's requirements and both performance indices have fallen; the explanation says code review and automated testing are genuinely valuable and neither touches the cause.
Does the exam treat tooling as a way to close a skill gap? No. When a team lacks machine-learning expertise on a product it will maintain long after the project closes, deploying automated tools to help with the tasks is offered and rejected. Keyed is targeted training, because the explanation reasons that the capability has to end up inside the team rather than beside it.
How do I tell a legitimate tooling answer from a distractor? Ask what the tool measures and what the stem says is broken. If the stem describes a requirements, communication or capability problem, a tool that inspects output more efficiently will produce the same defect faster. The bank's single keyed case is the one where the activity itself, not the outcome, was the waste.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 Exam Content Outline, with every wrong answer explained, not just marked wrong. Start the free 20-question sample and see how often the technically impressive option never reaches the stated cause. No card, no signup required to try it.
When is automating something the keyed answer on the PMP exam?
When the work being automated is non-value-added in itself. The bank keys recommending an automated reporting tool where possible, since categorising work by hand is non-value-added, and its explanation is explicit that time spent recording work does not directly benefit the customer's output. The bank also keys checking whether a status report can be generated and sent automatically, which is the same principle applied to a reporting chore.
Why is automated testing so often a distractor?
Because it verifies that software works as built, and the stems that offer it describe projects building the wrong thing. In one record the features are drifting from the client's requirements and both performance indices have fallen; the explanation says code review and automated testing are genuinely valuable and neither touches the cause.
Does the exam treat tooling as a way to close a skill gap?
No. When a team lacks machine-learning expertise on a product it will maintain long after the project closes, deploying automated tools to help with the tasks is offered and rejected. Keyed is targeted training, because the explanation reasons that the capability has to end up inside the team rather than beside it.
How do I tell a legitimate tooling answer from a distractor?
Ask what the tool measures and what the stem says is broken. If the stem describes a requirements, communication or capability problem, a tool that inspects output more efficiently will produce the same defect faster. The bank's single keyed case is the one where the activity itself, not the outcome, was the waste.