Jira ACP-620 Certification Practice Exams

The correct answer is Assign components to mark the development areas and create a single board with two quick filters that use those components.

This option works because components are a built in way to partition work in a company managed project and they do not require extra custom fields or enforcement of freeform data. A single board keeps one unified backlog and a single Burndown Chart for the product owner to see combined progress across both squads. The squads can still focus on only their work by using quick filters that target the components assigned to each squad.

Using components with quick filters also lets each squad view board level reports that reflect only their issues. That makes it possible for a squad to detect bottlenecks with a Cumulative Flow Diagram that shows only that squad’s issues while the product owner retains the combined Burndown Chart on the same board.

Label work areas with tags and use one board with two quick filters that target those labels is not ideal because labels are freeform and can become inconsistent across teams. That increases the administrative overhead and can make reporting and filtering unreliable.

Use versions to separate areas and create two distinct boards each filtered by a different version is wrong because versions are intended for releases and not for ongoing team segmentation. Creating distinct boards would also lose the single combined Burndown Chart that the product owner needs.

Add a custom field to identify squads and build one board with two quick filters based on that custom field is not the best choice because adding a custom field increases configuration and maintenance. The requirement asks to avoid complex configuration and a built in mechanism like components meets the needs with less overhead.

The correct answer is: Component labels are case-sensitive.

This statement is incorrect because project components do not have a separate concept called labels. Components are defined by a name and can include a lead, description, and default assignee, while labels are an issue level field used to tag issues and are handled separately.

Only project administrators can create or modify components is not the incorrect statement because managing components is controlled by project administration permissions and normally only users with those permissions can create or edit components.

Component fields can be used in JQL filters is not the incorrect statement because the component field can be referenced in JQL and you can filter issues by component.

A component’s default assignee can be Project Default, Component Lead, Project Lead or Unassigned is not the incorrect statement because those are the standard default assignee options for components in Jira.

The correct answer is Browse users and groups global permission.

When adding someone as a board administrator the user picker autocompletes from accounts that the acting user is allowed to see. If the acting user does not have the Browse users and groups global permission then the autocomplete will not present Liam in the suggested list and she will not be able to select him.

Browse projects project permission controls access to projects and their issues. It does not determine whether user accounts appear in the autocomplete user picker so it would not prevent suggestions when adding a board administrator.

Manage board administrators board permission relates to who can change the administrators on a specific board. It does not affect visibility of users in the global user picker so lacking it would not hide suggestions.

Jira administrators global permission grants elevated administrative rights across the site. That permission is not required to populate the user suggestions and it is not the reason the suggested user list would fail to appear.

Burndown chart is correct because it shows remaining sprint work and projects whether the team will meet the sprint goal.

A Burndown chart plots work remaining on the vertical axis and time on the horizontal axis. It compares the actual remaining work against an ideal trend so the team can see mid sprint whether they are on track to finish the planned work.

Velocity chart is incorrect because velocity summarizes how much work the team completed across past sprints to help forecast future capacity and it does not show remaining work within the current sprint over time.

Burnup chart is incorrect because burnup emphasizes total scope and work completed and it is useful for showing scope changes and cumulative progress rather than directly showing remaining sprint work against time to predict meeting the sprint goal.

The correct options are Tasks are visible in the Backlog while Subtasks are excluded from the backlog view and Tasks can be ranked in the backlog but Subtasks cannot be ordered there.

The reason Tasks are visible in the Backlog while Subtasks are excluded from the backlog view is that a Kanban backlog in Jira shows standard, parent issue types by default and does not include child subtask issue types in the backlog listing. Subtasks are managed as children of their parent issue and they do not appear in the backlog view unless the board filter is explicitly configured to include them.

The reason Tasks can be ranked in the backlog but Subtasks cannot be ordered there is that backlog ranking operates on the set of issues that appear in the backlog. Since subtasks are excluded from the backlog they are not part of backlog ordering. Subtask ordering is handled within their parent issue context and is not part of backlog rank operations.

Subtasks inherit their visibility and restrictions from the parent issue so Tasks and Subtasks cannot have separate access controls is incorrect because subtasks are independent issues for many behaviors and visibility can be controlled by project permissions and issue security schemes. Subtasks are not universally forced to share a distinct access control that prevents them from having separate settings.

Tasks appear on the Kanban board but Subtasks are not displayed there is incorrect because whether subtasks appear on the board depends on the board filter and configuration. Subtasks can appear on boards if the filter or workflow mapping includes them, so the statement is too absolute to be correct.

Both Tasks and Subtasks can be ranked together in the backlog is incorrect because subtasks do not appear in the backlog by default and backlog ranking applies to issues that are part of the backlog. Therefore subtasks cannot be ranked together with parent tasks in the backlog view.

The correct options are Manually rank Project A issues above Project B issues in the board and backlog and Drag and drop Project A issues onto Project B epics in the Epics panel.

Manually rank Project A issues above Project B issues in the board and backlog is correct because a board that pulls issues from multiple projects uses a single board backlog and swimlanes for ordering and ranking. You can change the relative order of issues from different source projects on the board and in the backlog when the board filter includes both projects.

Drag and drop Project A issues onto Project B epics in the Epics panel is correct because the Epics panel shows epics available to the board and you can assign issues from other included projects to those epics by dragging. That lets you link or move issues from one project into epics that belong to the attached project when the board is configured to surface them.

View all project versions on the attached project Releases page is wrong because the Releases or Versions page for a given project shows versions only for that project. It does not aggregate versions from other projects just because the board pulls issues from them.

Set Kanban board estimation to Story Points is wrong because estimation configuration is typically a Scrum board feature and Kanban boards do not expose the same sprint based estimation settings in the board configuration. Story Points may still be used on issues but the Kanban board does not provide the same estimation setup as a Scrum board for backlog planning.

She must be a Jira administrator to create the rule that spans both projects.

Project administrators can build rules that run only inside their own project, and creating a rule that triggers in one company managed project and creates issues in another requires a multi project or global rule. A Jira administrator is required to create or permit rules that span multiple projects so the rule can create the cloned issue in BUILD and link it back to the SHIP source.

The actions Maya wants to perform are supported by Automation. Automation can clone or create issues, it can add issue links back to the source issue, and it can set the assignee automatically by using the project lead or a smart value for the project lead.

She can create the automation and satisfy every requirement is incorrect because a project administrator cannot create rules that operate across multiple company managed projects. Such cross project scope requires higher level administration.

Cloning issues is not supported by Automation is incorrect because Automation includes actions to clone or create issues and to copy fields or links when creating the clone.

She can build the rule but automatically assigning the clone to the project lead is not possible is incorrect because Automation can set the assignee and can reference the project lead for the target project so the cloned issue can be assigned automatically.

The correct options are The duplicated planning board is owned by the user who copied it, The cloned board can be pointed to a different saved filter but cannot alter the original filter if the copier lacks filter permissions, and The copier becomes administrator of the new board but not owner of the saved filter.

When you copy a board the system creates a new board record and assigns the copier as the owner and manager of that new board. This is why The duplicated planning board is owned by the user who copied it and why the copier can configure the new board independently of the original.

Boards reference saved filters as separate entities and the copy process does not change who owns those filters. That is why The cloned board can be pointed to a different saved filter but cannot alter the original filter if the copier lacks filter permissions. Changing or editing a saved filter requires the appropriate filter permissions even if you own the board that uses it.

The board copy grants administration rights over the new board but it does not transfer ownership of external resources. For that reason The copier becomes administrator of the new board but not owner of the saved filter, and the saved filter remains owned by the original filter owner unless ownership is explicitly transferred outside of the board copy action.

Cloning transfers ownership of the original saved filter to the copier is incorrect because copying a board does not reassign ownership of the referenced saved filter. Saved filter ownership and edit rights remain governed by the filter permissions and sharing settings rather than by who copied a board.

Both you and Maya will serve as administrators of the duplicated board.

When you duplicate an organization managed Kanban board you become an administrator of the new board while the original board administrator remains assigned. That means Both you and Maya will serve as administrators of the duplicated board and you can manage the duplicate without removing Maya from the administrator role.

Only Maya will be the board administrator is incorrect because duplicating the board grants administrative rights to the person who creates the duplicate and does not transfer exclusive control to the original owner.

You will be the only administrator of the duplicated board is incorrect because the original administrator is retained when the board is duplicated, so you are not the sole administrator.

You will not be able to duplicate the board is incorrect because viewing a saved filter does not prevent you from duplicating the board and creating a new board that you administer alongside the original administrator.

The correct answer is Oscar.

When you explicitly set the assignee to Oscar the issue is assigned to that person regardless of selecting multiple components. Components are used for categorization or routing and they do not override the assignee field, so Oscar is the recipient of the issue.

Priya is incorrect because she was not chosen as the assignee and selecting components does not assign the issue to other users.

Marcus is incorrect for the same reason because the assignee field determines who receives the issue and Marcus was not set as the assignee.

Hana is incorrect because she was not assigned the issue and component selection alone does not send the issue to her.

The correct answer is 8 days.

The days in column indicator is cumulative for the specific column and therefore you add the time spent in each visit to that column. The ticket was in Doing for 6 days on the first visit and for 2 days on the second visit which totals 8 days. Time spent in the Review column is tracked separately and does not count toward the Doing total.

The option 11 days is incorrect because it would add the 3 days spent in Review to the Doing time and days in other columns are not included in the Doing total.

The option 3 days is incorrect because that is the time the ticket spent in Review and not the time spent in Doing.

The option 6 days is incorrect because it counts only the first stay in Doing and ignores the additional 2 days from the second stay which must be included in the Doing total.

Branch rule is the correct option because it is the automation construct that iterates over linked or related issues and applies the nested actions to each linked issue.

The branch is configured with a branch type such as for linked issues so the rule will loop through each linked issue and execute whatever actions you place inside the branch for every matched linked issue. This makes it the proper choice when you need to perform actions on each linked issue individually.

Lookup issues action is incorrect because that action runs a JQL search and returns a set of issues for use in the rule but it does not by itself act as the branching mechanism for iterating through linked issues in the way a branch does.

Link issues action is incorrect because that action creates a link between issues and it does not iterate over linked issues or perform per-linked-issue actions.

Re-fetch issue action is incorrect because that action refreshes the rule’s current issue data to the latest values and it does not loop through or act on linked issues.

The correct option is Scheduling work using team capacity and velocity.

Scheduling work using team capacity and velocity is the capability Advanced Roadmaps provides because it models team capacity and velocity to forecast when work will complete across multiple teams and projects. Scheduling work using team capacity and velocity lets you define team members, sprint length, and per sprint capacity so the plan can surface overcommitments and calculate realistic dates based on velocity.

Enterprise level portfolio planning and governance is not correct because Advanced Roadmaps focuses on cross team scheduling and forecasting rather than providing full enterprise governance features. Enterprise governance is normally handled by broader portfolio management systems and organizational processes.

Lean budgeting and adaptive investment tracking is not correct because Advanced Roadmaps does not provide dedicated budgeting or investment tracking workflows. Those concerns are usually addressed by separate financial or portfolio tools rather than the scheduling and capacity features in Advanced Roadmaps.

Dedicated lean methodology tooling is not correct because Advanced Roadmaps is a planning and scheduling tool that supports multiple ways of working and it is not a purpose built toolkit for a single lean methodology.

The correct options are They depend on the same reporting and metrics, They require identical workflow schemes, and They share a roadmap and release cadence.

They depend on the same reporting and metrics is correct because a single Jira project makes it straightforward to build shared filters, boards, and reports. When teams need identical metrics and cross team dashboards it is simpler to keep their work in the same project so that reporting is consistent and query scopes do not need complex cross project filters.

They require identical workflow schemes is correct because a project applies a single set of workflow conventions by default. If both teams follow the same lifecycle for issues then a single project ensures the workflow behavior is uniform and reduces scheme management overhead.

They share a roadmap and release cadence is correct because versions and release tracking are typically organized at the project level. When teams plan together and ship on the same cadence a shared project keeps the roadmap and release management in one place which reduces coordination friction.

They require distinct issue type schemes is incorrect because a single Jira project uses one issue type scheme and cannot simultaneously enforce different issue type sets for different teams. If teams truly need different issue types then separate projects or careful scheme configuration is the better approach.

The correct answer is All statuses from every project are assigned to three default columns To Do In Progress and Done.

This happens because when you create a company managed Kanban board that spans multiple projects Jira collects the statuses from each project’s workflows and assigns them to the board’s default columns. You can then customize the column to status mappings if you need different groupings or additional columns.

Only issues in an active sprint are shown on the board is wrong because sprints apply to Scrum boards and not to Kanban boards. A Kanban board displays issues based on the board filter and column mappings rather than the sprint state.

Only the statuses from the first selected project are applied to the board is wrong because the board aggregates statuses from all projects included by the board filter. The board does not limit mappings to a single project’s statuses.

Some issues may be omitted from the board because they do not map to any column is wrong in the creation scenario because Jira initially assigns all discovered statuses to the default columns so issues are not omitted. Issues can become omitted only if you later remove or change mappings.

It is not possible to create a single board that spans multiple company-managed projects is wrong because company managed boards can span multiple projects by using an appropriate board filter. Team managed projects are limited to a single project but that limitation does not apply to company managed boards.

The correct answer is Interim Product Owners role and Jira Software access.

This combination is correct because the Interim Product Owners project role can be granted the project permissions required to change the Reporter field and Jira Software access ensures the user appears in the Assignee picker and can receive assignments in Jira Software projects.

Interim Product Owners role alone is incorrect because the project role by itself does not guarantee product access or the ability to be assigned unless the permission scheme and product access are also configured.

Product Owners role is incorrect because the role name alone does not imply that it includes the Modify Reporter or Assign Issues permissions or that the user has Jira Software access which is required to be a selectable assignee.

Scrum Lead role and Administrators role is incorrect because this pairing is not the combination described in the question and administrator status does not automatically mean the Modify Reporter permission and product access are present in every project configuration.

The correct option is Control chart.

A Control chart displays cycle time and lead time for individual work items across a sprint or release and it visualizes variation and trends over time. A Control chart highlights outliers and shows whether the process is stable and predictable, which is why it helps indicate if current sprint measurements can be used to forecast future performance. A Control chart often includes percentile lines or limits that make it easy to see typical completion times and to detect shifts in the process.

Velocity chart is incorrect because it shows the amount of work completed per sprint and it helps with sprint planning but it does not plot per item cycle time or show process stability for predicting future performance.

Cumulative flow diagram is incorrect because it shows work in progress and the flow of issues through states and it helps identify bottlenecks but it does not directly plot individual item cycle time and stability in the way a control chart does.

Sprint report is incorrect because it summarizes completed and remaining work for a single sprint and it does not provide the item level cycle time analysis or the statistical view of predictability that a control chart provides.

Release burndown is incorrect because it tracks remaining work over a release timeline and it helps show overall progress but it does not show cycle time or lead time per work item or whether the process is stable enough to predict future performance.

The correct answer is Reopen resolved issues from an archived release.

This bulk operation specifically targets issues that were marked as resolved and that were included in a release that has been archived. Running this operation moves those issues out of the resolved state so they are reopened and can be reassigned or worked on again even though the release itself is archived.

Change the Summary for multiple issues is incorrect because changing a summary only updates the issue text and does not affect an issue’s workflow status or reopen resolved work.

Update the Original Estimate across issues is incorrect because that operation only adjusts time tracking fields and does not transition issues between workflow statuses or reopen them.

The correct option is Board sub filter.

A Board sub filter adds an extra JQL condition that is automatically applied on top of the board’s saved filter so the board shows only issues that match both queries without any user action. You can restrict the sub-filter to issues with a specific Components value so the duplicated board will display only compliance related issues across projects. Because the sub-filter is evaluated together with the board’s saved filter the duplicate can continue to reference the same saved filter so updates to the original board filter are reflected and the board reports remain consistent.

Swimlanes are a visual layout feature that groups issues into horizontal bands and they do not prevent issues from appearing on the board so they cannot enforce a view that only shows compliance issues.

Quick filters create buttons that users can click to temporarily narrow the visible issues and they require manual action so they do not meet the requirement for an always applied, automatic view.

Automation rule can change issue data or perform background tasks but it is not the board configuration element that creates a persistent, automatically applied view tied to the board filter or preserves the board reports in the same way.

The correct answer is Company managed Kanban project.

This setup provides a backlog together with a configurable board sub filter and it lets project administrators assign users to project roles and manage permissions. A company managed Kanban board can enable a backlog for continuous flow and the board settings include filter and sub filter options so you can fine tune which issues appear on the board. Project roles and permission schemes in company managed projects let administrators control assignments and administrative rights without changing global settings.

Team managed Kanban project is incorrect because team managed projects use simplified permissions and do not offer the same level of project roles or advanced board filter configuration. Team managed boards are intended for simpler, team level workflows and they lack the granular role and permission controls found in company managed projects.

Company managed Scrum project is incorrect for this question because Scrum projects are optimized for sprint based planning and iteration work even though they include a backlog. The question specifically targets the Kanban configuration that emphasizes continuous backlog handling and Kanban style board settings, so the Kanban option is the intended choice.