Jira ACP-620 Certification Practice Exams

Maya administers the company managed project “RAPID” and she oversees several other internal applications. She notices that whenever a RAPID issue is reopened one of her applications receives an HTTP request containing the issue data in JSON format. Which two settings could be causing this behavior? (Choose 2)

• ❏ A. Application links

• ❏ B. Workflow post functions

• ❏ C. Issue collectors

• ❏ D. Automation rule

• ❏ E. Workflow triggers

Laura is the project administrator for project “ORION”. That project currently has two versions labeled “1.1” and “2.2”. Both versions are referenced by issues. The “1.1” version had the status RELEASED and the “2.2” version had the status UNRELEASED. Laura accidentally archived both versions and she asks whether she should unarchive them to correct the error. Which statement is correct?

• ❏ A. Unarchiving version “1.1” will change its status to UNRELEASED

• ❏ B. You will only be able to unarchive version “1.1” and not version “2.2”

• ❏ C. Laura can and should unarchive both versions “1.1” and “2.2” to fix her mistake

• ❏ D. Restore versions from a project backup

Which statement about estimation and time tracking on a company managed Scrum board at Nimbus Solutions is incorrect?

• ❏ A. A burndown chart can plot remaining work using an estimation metric other than story points

• ❏ B. You can use a single choice custom field as the basis for the board estimations

• ❏ C. A team may estimate using story points while logging time on sub tasks in hours

• ❏ D. Only the board administrator and the project administrator for the board location can alter the Estimation Statistic setting

Rosa from Meridian Tech needs a combined chart and table to confirm whether her backlog is current and healthy. The output must include the total number of unresolved tickets and the average age of those unresolved tickets. Which report should she use?

• ❏ A. Time Tracking Report

• ❏ B. Pie Chart Report

• ❏ C. Resolution Time Report

• ❏ D. Single Level Group By Report

• ❏ E. Time Since Issues Report

• ❏ F. Average Age Report

Liam is on the company managed project PORTAL2 at Keystone Retail and the project board uses a basic workflow that Jira generated and that has never been altered. Liam is unable to move cards into the Done column on the board. Which permission does Liam need?

• ❏ A. Move Issues permission

• ❏ B. Resolve Issues permission

• ❏ C. Transition Issues permission

• ❏ D. Edit Issues permission

At a startup named Skylark Systems the product teams use Jira boards and they maintain both team managed and company managed projects. Which statements about board ownership and the ability to include issues from different project types are correct? (Choose 3)

• ❏ A. A team managed board can display issues from both team managed and company managed projects

• ❏ B. It is impossible to add several team managed projects into one company managed board

• ❏ C. A company managed board may aggregate issues from several company managed projects

• ❏ D. A team managed project has only one board that belongs solely to that project

• ❏ E. A company managed board can include both team managed and company managed projects

• ❏ F. A company managed project is limited to a single board

A product team at Arcadia Digital maintains a mix of enterprise-managed projects and team-managed projects and they want to confirm whether subtasks can hold story point estimates and whether subtasks are visible on the active sprint board in enterprise-managed projects? (Choose 3)

• ❏ A. Subtasks cannot have story point estimates in team-managed projects

• ❏ B. Subtasks can have story point estimates in enterprise-managed projects

• ❏ C. Subtasks are never visible on the active sprint board of enterprise-managed projects

• ❏ D. Subtasks can have story point estimates in team-managed projects

• ❏ E. Subtasks cannot have story point estimates in enterprise-managed projects

• ❏ F. Subtasks are displayed on the active sprint board of enterprise-managed projects

At Meridian Software a delivery team wants to convert a project from team managed to company managed and they are unsure what is possible within the project settings, which statement about how project types work in Jira is accurate?

• ❏ A. Project administrators can update the project type from the project settings

• ❏ B. Changing a project type requires creating a new project and migrating the issues into it

• ❏ C. Team managed projects also use the same project type setting as company managed projects

• ❏ D. A single project may be assigned to multiple project types at the same time

Priya is setting up a new Scrum board that draws issues from several company-managed projects and each project has its own workflow with distinct statuses. Which statements are accurate? (Choose 2)

• ❏ A. No issues will be displayed on the board

• ❏ B. All workflows will have their statuses consolidated into three default columns To Do In Progress and Done

• ❏ C. Statuses are taken only from the first project chosen during board creation

• ❏ D. Some issues will not be visible on the Scrum board

• ❏ E. You are prevented from creating a board that includes more than one project

Harper started a two week sprint with five tasks and placed all tasks in the To Do column. On the first day Harper moved two tasks into the In Progress column. On the second day Harper moved one of those In Progress tasks into the Done column. On the third day Harper removed that task from Done and put it back into To Do. If each board column maps to a status with the same name and the leftmost column is To Do while the rightmost column is Done what will the Cumulative Flow Diagram display?

• ❏ A. To Do = 4 tasks In Progress = 1 task Done = 1 task

• ❏ B. To Do = 5 tasks In Progress = 2 tasks Done = 1 task

• ❏ C. To Do = 5 tasks In Progress = 1 task Done = 0 tasks

• ❏ D. To Do = 4 tasks In Progress = 2 tasks Done = 0 tasks

All exam questions come from my Jira ACP-620 Udemy course and certificationexam.pro

Marco recently joined an issue tracking team at scrumtuous.com and his lead gave him three responsibilities. He must assign tickets to other teammates, he must not be the assignee on any tickets, and he must change ticket statuses through the workflow. What minimum project permissions does Marco require to carry out these tasks? (Choose 2)

• ❏ A. Move Issues

• ❏ B. Edit Issues

• ❏ C. Assignable User

• ❏ D. Create Issues

• ❏ E. Assign Issues

• ❏ F. Transition Issues

Which elements are not included among the components used in Jira Cloud automation rules? (Choose 2)

• ❏ A. Trigger

• ❏ B. Branching

• ❏ C. Iteration

• ❏ D. Action

• ❏ E. Condition

• ❏ F. Workflow transition

Lina is using a company-managed Kanban board for her product team at Nimbus Apps and she can run the board saved filter in the “Advanced issue search” to display all matching issues yet several cards do not show on the board. What might cause some issues to be missing from the board? (Choose 3)

• ❏ A. Board swimlanes

• ❏ B. A board sub filter

• ❏ C. Quick filters configured on the board

• ❏ D. The board saved filter

• ❏ E. The “Hide completed issues older than” board setting

• ❏ F. Issue security levels

• ❏ G. The board card layout

Priya needs to share several security guides that are hosted on an external website with her project team inside a project that is managed by a team. What is the best way to share that website link with her teammates? (Choose 3)

• ❏ A. Use the project overview to store the website link

• ❏ B. Add a comment on an issue with the link

• ❏ C. Create a linked issue pointing to the website

• ❏ D. Add a shortcut on the project sidebar that points to the website

• ❏ E. Use the issue view to add a web link to the issue details

A Platform Squad added a new component called ‘Platform’ to every issue they own. Maria is not on that squad and she wants to prevent that component from showing on her board and in reports. What feature should she use to accomplish this?

• ❏ A. Swimlanes

• ❏ B. Board sub-filter

• ❏ C. Board filter

• ❏ D. Quick filters

• ❏ E. Saved filter

Lina added a custom field named Training Environment to her issue tracker and she needs a dashboard gadget that will list issues showing Issue Type Key Summary Priority and Training Environment. Which gadget types will allow her to include the Training Environment custom field as a column? (Choose 2)

• ❏ A. Issue Statistics

• ❏ B. Watched Issues

• ❏ C. Activity Streams

• ❏ D. Filter Results

• ❏ E. Two Dimensional Filter Statistics

A product team uses Jira with three statuses Backlog Active and Completed. Which JQL query will list issues that have never been in the Completed status?

• ❏ A. status != Completed

• ❏ B. resolution is EMPTY

• ❏ C. status was not Completed

• ❏ D. status was in (“Backlog”,”Active”)

• ❏ E. status changed TO Completed

Which capability is not available in both enterprise managed projects and team managed projects in Jira?

• ❏ A. Working on issues in weeklong iterations

• ❏ B. Creating multiple issues in a single operation

• ❏ C. Defining who may view specific issues

• ❏ D. Prioritizing work continuously using a backlog and an Agile board

Maya manages several company-controlled projects and she verifies that the issue statuses are mapped to the correct sprint board columns, yet she reports that some issues are not appearing on the Scrum board. What might be the underlying causes? (Choose 3)

• ❏ A. A quick filter is currently applied

• ❏ B. The board saved filter was modified

• ❏ C. A board sub-filter is excluding issues

• ❏ D. The user does not have Browse Projects permission on some projects on the board

• ❏ E. The user is missing View Development Tools permission

Which piece of information is not shown in the Development panel when viewing an issue in a Jira project?

• ❏ A. Total commits and the date of the most recent commit

• ❏ B. Number of builds and their current statuses

• ❏ C. Number of pull requests and their statuses

• ❏ D. Number of pipelines

• ❏ E. Number of branches linked to the issue

Marcus needs Jira to automatically duplicate a ticket and transfer its file attachments when the issue moves into the “DEV REVIEW” status. How would you achieve this?

• ❏ A. ScriptRunner

• ❏ B. Bulk Change

• ❏ C. Automation rule

• ❏ D. Workflow post-function

Two teams inside the same division have been running separate Jira projects until now. The division lead asked you to build a combined board that spans both projects so that issues can be linked to epics in either project. After you created the combined board some team members report that they cannot drag issues from one project into epics that belong to the other project. What is the most likely cause?

• ❏ A. The board filter limits issues to a single project

• ❏ B. Users are missing global site level permissions

• ❏ C. Team members do not have edit rights in the other project

• ❏ D. Epics cannot include issues from projects outside their own project

A support team at NovaWorks needs to find every issue that contains any of the words “Compliance” “AML” or “SEC” in their searchable text. Which JQL query will return those issues?

• ❏ A. text in (“Compliance”, “AML”, “SEC”)

• ❏ B. description ~ “Compliance” OR description ~ “AML” OR description ~ “SEC”

• ❏ C. text ~ “Compliance” OR text ~ “AML” OR text ~ “SEC”

• ❏ D. summary ~ “Compliance” OR summary ~ “AML” OR summary ~ “SEC”

Which of the following statements about Labels in TrackerPro is incorrect?

• ❏ A. Label values are case sensitive

• ❏ B. Labels are displayed as clickable links to related issues

• ❏ C. Labels cannot be removed after they have been created

• ❏ D. The Labels field can be used in the Issue Metrics gadget

How are parent tasks and their child subtasks ordered on the backlog and board in this project? (Choose 2)

• ❏ A. Subtasks keep fully independent order from their parent

• ❏ B. Moving a parent moves all of its subtasks together

• ❏ C. You must rank every subtask before you can rank its parent

• ❏ D. Subtasks can be rearranged relative to their sibling subtasks

Maya is forming a new quality assurance squad and she needs a project type that meets the following needs. The team requires a dedicated column to hold an extensive backlog. They need to quickly locate high priority issues on the board. They also want to produce a visual report that groups issues. Which project type should Maya choose?

• ❏ A. Scrum team managed project

• ❏ B. Company managed Kanban project

• ❏ C. Kanban team managed project

• ❏ D. Company managed Scrum project

The company managed project “NOVA” has the following configuration. The project lead is Nora and the project default assignee is set to Project Lead. The components are configured as follows. The “UI” component has Alex listed as the component lead and its default assignee is Project Lead. The “Auth” component has Ben listed as the component lead and its default assignee is Component Lead. The “Service-ALP” component has Cara listed as the component lead and its default assignee is Project Default. The “Service-BTA” component has Diego listed as its component lead but its default assignee is Unassigned. If you create a new issue and select the components “UI” “Auth” and “Service-ALP” while leaving the assignee set to Automatic who will the issue be assigned to?

• ❏ A. Cara

• ❏ B. Alex

• ❏ C. Ben

• ❏ D. Nora

All exam questions come from my Jira ACP-620 Udemy course and certificationexam.pro

Lina at NovaWorks is using the Jira timeline to track progress on a new project and she finds the timeline view is not available for that project. What is a likely cause of the missing timeline?

• ❏ A. The project is team managed

• ❏ B. There are no Epics in the project

• ❏ C. The board filter includes issues from multiple projects

• ❏ D. Lina lacks the View Read Only Workflow permission

• ❏ E. The timeline feature has been disabled by the board administrator

In a project configuration for a software team at NimbusSoft which configuration items can be assigned to project roles? (Choose 3)

• ❏ A. Application access

• ❏ B. Project dashboard

• ❏ C. Group membership

• ❏ D. Issue security level

• ❏ E. Global permission

• ❏ F. Saved filter subscription

Priya must build a dashboard to help onboard new Jira users. The dashboard should provide helpful links and a summary of activity across the Jira instance. Which gadgets should Priya add to the onboarding dashboard? (Choose 4)

• ❏ A. Watched Issues

• ❏ B. Activity Stream

• ❏ C. Favorite Filters

• ❏ D. Voted Issues

• ❏ E. Introduction

• ❏ F. Issue in progress

• ❏ G. Projects

• ❏ H. Labels Gadget

At Meridian Projects the team builds automation rules to handle issue workflows. Which automation component monitors the events that users choose and starts the rule execution?

• ❏ A. Conditions

• ❏ B. Webhooks

• ❏ C. Actions

• ❏ D. Requirements

• ❏ E. Triggers

• ❏ F. Steps

Which statements accurately describe how Quick Filters operate on a Kanban or Scrum board?

• ❏ A. Quick Filters are available only on Scrum boards and do not appear on Kanban boards

• ❏ B. Quick Filters append an extra JQL clause to the board’s primary filter so the board filter remains in effect

• ❏ C. The built-in Quick Filters named “Only My Issues” and “Recently Updated” cannot be changed

• ❏ D. Only board administrators and project administrators are allowed to create Quick Filters

Which statements accurately describe who can create company-managed projects and who can create team-managed projects in TaskFlow? (Choose 2)

• ❏ A. “Create Projects” global permission is required to create a company-managed project

• ❏ B. Only project administrators can create team-managed projects in TaskFlow

• ❏ C. Members of the “site-owners” group can create company-managed projects by default

• ❏ D. You need the “View Projects” permission to create a company-managed project

• ❏ E. Users with the “Administer TaskFlow” global permission can create company-managed projects

• ❏ F. Any licensed user can create both company-managed and team-managed projects

Lucas is setting up a team managed board for his engineering group and he needs to pick a project access level that satisfies two requirements. Team members who already work on other Jira Kanban boards must be able to reorder items in the new project’s backlog and Lucas does not want to assign any project roles to those team members after creating the project. Which project access level should Lucas choose?

• ❏ A. Limited

• ❏ B. Public

• ❏ C. Open

• ❏ D. Unlimited

• ❏ E. Private

Nimbus Mobile is building a mobile application and the team uses a company managed scrum board to track work. In the project developers move issues from the status “Ready” to “QA” and testers then move issues from “QA” to “Completed” where the Resolution field is set to “Completed”. The scrum board originally had three columns with the same names as the statuses and each status was mapped to the matching column. The team scheduled 60 issues for the sprint and because the scope is large the developers do not want more than 12 items in the right most column so they removed the “Completed” column and the right most column is now “QA”. What will happen when the sprint is closed?

• ❏ A. Items in the QA column will be recorded as completed for the sprint and will be removed from the backlog

• ❏ B. You will be prompted to either move the issues in the QA column to the next sprint or return them to the backlog

• ❏ C. Issues that are in the Completed status but not mapped to a column will not be marked as completed for the sprint and will be returned to the backlog

• ❏ D. Issues in the QA column will be marked as uncompleted for the sprint but they will be removed from the backlog

Which statement about administering project roles in the issue tracker AtlasWorks is incorrect? (Choose 3)

• ❏ A. Groups and individual user accounts can be assigned to project roles

• ❏ B. Project roles are referenced by permission schemes to govern project access

• ❏ C. Project administrators can change a role’s membership inside a specific project

• ❏ D. Project administrators can alter the default members that are applied to every newly created project role

Summit Tech recently moved its Jira Cloud subscription from Standard to Premium so multiple teams can scale Agile practices. Which Advanced Roadmaps features help plan work across many teams and evaluate alternative timelines? (Choose 2)

• ❏ A. Create multiple plan scenarios and switch among them to compare timeline outcomes

• ❏ B. Export plans in Microsoft Project format

• ❏ C. Assemble cross project plans and align cross project releases

• ❏ D. Native support for the SAFe framework

• ❏ E. Team capacity planning and utilization views

What should Maya do if her Kanban board shows a very long list of tickets in the first column that she uses for planning?

• ❏ A. Create a new workflow status and add a column then leave that status unmapped

• ❏ B. Turn on the Kanban backlog feature for the board

• ❏ C. Modify the board filter to hide issues in the planning status

• ❏ D. Add a distinct backlog column to the board

You recently hired Maya as the new Scrum Master at Riverton Tech and she must be able to create and reorder sprints on the company managed Scrum board. Which change will allow her to perform those sprint management actions?

• ❏ A. Add Maya to a project role that has the Administer projects permission

• ❏ B. Make Maya a board administrator of the Scrum board

• ❏ C. Add Maya to a project role that has the Schedule issues permission

• ❏ D. Assign Maya to a project role that is listed under the “Manage sprints” permission

Lina set up an automation that should create several sub tasks whenever a new issue is reported and its description contains the “CourseHub” keyword. The rule only generates a single sub task instead of multiple ones. What could be causing this issue?

• ❏ A. The automation actor does not have the Create Issues permission

• ❏ B. The rule is configured to run only once per issue so it only executes its post actions a single time

• ❏ C. The action was changed from Create sub tasks to Create issues using the sub task issue type

• ❏ D. The branch that iterates to create multiple sub tasks is missing from the rule

Lena created a Kanban board that includes issues from the following projects “NOVA” which is a company-managed project “PULSE” which is a team-managed project and “ROUTE” which is a company-managed project. She then enabled the backlog view and could see the “RELEASES” panel but the “EPICS” panel did not appear. Why is the “EPICS” panel missing?

• ❏ A. The “Epics” panel cannot be displayed on a Kanban backlog

• ❏ B. Issues from the team-managed project must be removed from the board filter

• ❏ C. Activate the backlog setting that displays the “Epics” panel

• ❏ D. Lena lacks the required permissions to enable the Epics panel

You work for Aurora Space Research tracking planetary information in Jira and their catalog contains 10 planets. When a user files an issue they must pick a single planet to associate with the issue. The chosen planet must be usable for producing accurate counts in an Issue Statistics gadget. Which field type satisfies these requirements?

• ❏ A. Labels

• ❏ B. Custom field Checkboxes

• ❏ C. Custom field Select List single choice

• ❏ D. Custom field Text Field single line

• ❏ E. Component/s

Which elements can a project administrator add directly from the project navigation sidebar in a Jira Cloud project? (Choose 2)

• ❏ A. Project avatar

• ❏ B. Linked code repositories

• ❏ C. Issue templates

• ❏ D. Project shortcuts

• ❏ E. Project short description

Maya is the project lead at Nebula Solutions and she manages the company controlled project “VENUS” which uses a single workflow for every issue type, and that workflow defines two resolution values “Abandoned” and “Completed”. Maya accidentally changed the resolution on several hundred issues from “Abandoned” to “Completed” and she needs to find all impacted issues knowing that the resolution field is set by the workflow and that its history can be queried. How can she locate those issues?

• ❏ A. Contact Atlassian support for assistance locating the affected issues

• ❏ B. project = VENUS and resolution changed from “Abandoned” to “Completed”

• ❏ C. project = VENUS and resolution = “Completed” and status changed from “Abandoned” to “Completed”

• ❏ D. Export issue change history or review the issue changelogs to search for resolution updates

All exam questions come from my Jira ACP-620 Udemy course and certificationexam.pro

Priya needs to create a new board for her team that displays issues from three separate projects and automatically hides any issue that is moved to the Done column and set to the resolution “Won’t Fix” after 48 hours. Which board configuration will meet both requirements?

• ❏ A. Company-managed Scrum board using quick filters

• ❏ B. Team-managed Kanban board with a board sub-filter

• ❏ C. Company-managed Kanban board using a board sub-filter

• ❏ D. Company-managed Scrum board with a board sub-filter

Priya has just created her first team-managed project in Jira from a Scrum template and she wants to estimate work in “Time” instead of “Story points”. Which area of the project settings will allow her to change the estimation method?

• ❏ A. Issue types

• ❏ B. Board

• ❏ C. Features

• ❏ D. Details

• ❏ E. Access

• ❏ F. It is not possible to change the estimation setting for a Scrum team-managed project

The correct options are Workflow post functions and Automation rule.

Workflow post functions run as part of a workflow transition and they can be configured to perform extra processing when an issue moves state. When an issue is reopened a post function can invoke an external service or a webhook provided by an app so the application receives the issue data in JSON format.

Automation rule can trigger on events such as an issue being reopened and it includes actions like Send web request. That action posts JSON payloads to external endpoints so an application would receive the issue data whenever the automation rule fires.

Application links are only used to connect Jira to other Atlassian products and to enable SSO and API integrations between them. They do not by themselves send outgoing HTTP requests on an issue reopen.

Issue collectors are widgets you embed on web pages to let users create issues from a form and they are not triggered by issue state changes within Jira.

Workflow triggers are inbound mechanisms that allow external systems to trigger workflow transitions. They do not send outbound HTTP requests when an issue is reopened.

When a question describes an outgoing HTTP request on a transition think about post functions or an automation rule with a send web request action.

The correct answer is Laura can and should unarchive both versions “1.1” and “2.2” to fix her mistake.

As the project administrator Laura can unarchive versions from the project settings and this will restore each version to its prior state. Unarchiving makes the versions visible again in release lists and preserves their associations with issues so it repairs the accidental archive without data loss.

Because version “1.1” was previously released and version “2.2” was previously unreleased unarchiving will return each to its former release status rather than forcing them both to become unreleased. Unarchiving is therefore the appropriate and simple corrective action.

Unarchiving version “1.1” will change its status to UNRELEASED is incorrect because unarchiving does not automatically flip the release flag and the version will generally retain its released or unreleased status when restored.

You will only be able to unarchive version “1.1” and not version “2.2” is incorrect because there is no such limitation and a project administrator can unarchive any archived version in the project.

Restore versions from a project backup is incorrect because a full backup restore is unnecessary for this situation and unarchiving is the supported and simpler way to recover archived versions.

When answering questions about archival look for the word reversible and remember that archived versions in issue trackers are often unarchived and restored to their previous state rather than requiring backups.

The correct answer is: You can use a single choice custom field as the basis for the board estimations.

This statement is incorrect because company managed Scrum boards do not let you pick an arbitrary single choice custom field as the board estimation statistic. The board estimation setting accepts specific statistics such as Story points, Original estimate (time), or Issue count and it maps to the field Jira expects for that statistic. You cannot point the board at a generic single choice custom field and have Jira treat those values as the board estimation metric.

A burndown chart can plot remaining work using an estimation metric other than story points is not the right answer because it is a true statement. The burndown chart uses whatever estimation statistic the board is configured to use so it can show remaining work in story points or in time or in issue count depending on the board setting.

A team may estimate using story points while logging time on sub tasks in hours is not the right answer because it is also true. Estimation and time tracking are separate features so a team can estimate at the issue level with story points while tracking work logged on subtasks in hours or minutes without changing the story point estimates.

Only the board administrator and the project administrator for the board location can alter the Estimation Statistic setting is not the right answer because this describes who normally makes the change through board settings. Changing the estimation statistic is performed via the board configuration and requires board administrator permissions or project administration rights for the project where the board is located. Administrators with broader system privileges can also perform administrative actions, but the operational change is done from the board settings by those roles.

When you see questions about board estimations check which fields Jira accepts as estimation statistics and remember that estimation configuration is changed in the board settings by a board admin or the project admin for the board location.

The correct answer is Average Age Report.

The Average Age Report directly provides the average age of unresolved issues and it can show counts of unresolved tickets along with charts so it meets the requirement to deliver both the total number of unresolved tickets and the average age of those unresolved tickets.

Time Tracking Report is focused on logged work and estimation data and it does not calculate the average age of unresolved issues so it does not meet the needs in this scenario.

Pie Chart Report only visualizes proportions by a chosen field and it will not compute an overall average age metric or present the combined numeric average required here.

Resolution Time Report analyzes time to resolution for issues that have been resolved and it does not provide the average age of currently unresolved tickets so it is not appropriate for this requirement.

Single Level Group By Report groups issues and returns counts per group and it does not calculate the average age metric needed to assess backlog health.

Time Since Issues Report highlights how long issues have been in a state or status but it does not combine a count of unresolved tickets with a computed average age in the way the Average Age Report does.

When a question asks for both a count and an age metric look for reports that explicitly calculate an average age or similar time based statistic and mention unresolved issues in their description.

Transition Issues permission is the correct option.

Transition Issues permission controls whether a user can perform workflow transitions that change an issue status and therefore move a card between board columns such as into Done. Boards map columns to workflow statuses in the basic workflow and moving a card into Done executes the transition that leads to that status so the transition permission is required.

Move Issues permission is incorrect because that permission is about moving an issue between projects or changing its issue type and not about executing workflow transitions to change status on the same board.

Resolve Issues permission is incorrect in this context because resolving or setting the resolution value is not what blocks the board transition. The ability to perform the transition is governed by the transition permission and not solely by resolution controls.

Edit Issues permission is incorrect because editing issue fields does not grant the right to perform workflow transitions. A user can edit fields if they have edit rights but they still need the transition permission to move issues through the workflow.

When a question describes moving cards between board columns think about workflow actions. If it is a transition then check for the Transition Issues permission in the project permission scheme.

The correct statements are A company managed board may aggregate issues from several company managed projects, A team managed project has only one board that belongs solely to that project, and A company managed board can include both team managed and company managed projects.

A company managed board may aggregate issues from several company managed projects is correct because company managed boards support cross project filters and board configurations that let you surface issues from multiple company managed projects in a single view. This flexibility is one of the main reasons teams use company managed projects when they need shared boards.

A team managed project has only one board that belongs solely to that project is correct because team managed projects are self contained and the board lives inside that project. That board cannot be owned by or shared with other projects in the same way as company managed boards.

A company managed board can include both team managed and company managed projects is correct because company managed boards can be configured with filters that reference issues across different project types when permissions allow. This makes a company managed board the more flexible option for aggregating work across an organization.

A team managed board can display issues from both team managed and company managed projects is incorrect because team managed boards are scoped to their own team managed project and are not designed to aggregate issues from other projects in the way company managed boards do.

It is impossible to add several team managed projects into one company managed board is incorrect because company managed boards can be configured to include issues from multiple projects, including multiple team managed projects when the filter and permissions permit it.

A company managed project is limited to a single board is incorrect because company managed projects can be associated with multiple boards and those boards can be configured independently to show different subsets of issues.

When answering these questions focus on whether a project type is self contained or shareable. Team managed projects are self contained with a single project board and company managed projects and boards are designed to be shareable across multiple projects.

The correct answers are Subtasks can have story point estimates in enterprise-managed projects, Subtasks can have story point estimates in team-managed projects, and Subtasks are displayed on the active sprint board of enterprise-managed projects.

Both Subtasks can have story point estimates in enterprise-managed projects and Subtasks can have story point estimates in team-managed projects are correct because Jira allows the story points field to be applied to subtask issue types when the project estimation settings and field configurations include that field. Teams can therefore record estimates at the subtask level in either project type when the estimation method and issue type fields are enabled.

Subtasks are displayed on the active sprint board of enterprise-managed projects is correct because enterprise managed boards can be configured to show subtask cards and the active sprint view will include those cards when the board filters and card settings permit it. Visibility is driven by board configuration and filters rather than by an absolute limitation that prevents subtasks from appearing.

Subtasks cannot have story point estimates in team-managed projects is wrong because team managed projects do support story point estimates on subtask issue types when the project’s estimation configuration is set to use story points.

Subtasks are never visible on the active sprint board of enterprise-managed projects is wrong because subtasks can be shown on the active sprint board if the board’s filter and card settings include them, so they are not categorically excluded.

Subtasks cannot have story point estimates in enterprise-managed projects is wrong because enterprise managed projects can include the story points field for subtask issue types and therefore allow estimating at the subtask level.

When the question asks about board behavior check whether visibility depends on configuration and filters rather than assuming an absolute restriction.

The correct answer is Changing a project type requires creating a new project and migrating the issues into it.

This is true because team managed and company managed projects use different configuration models and there is no single project setting that converts one type to the other. To change a project from team managed to company managed you must create a new company managed project and move the issues into it, and you should plan to map fields, recreate workflows, and reapply permissions because many settings do not transfer automatically.

Project administrators can update the project type from the project settings is incorrect because there is no in place toggle for project type in project settings and project administrators cannot convert the project type themselves.

Team managed projects also use the same project type setting as company managed projects is incorrect because team managed projects use a different, simplified configuration model that is not the same as the company managed scheme and they are treated as distinct project types.

A single project may be assigned to multiple project types at the same time is incorrect because a project has a single project type and it cannot be simultaneously classified as more than one type.

When a question mentions converting between team managed and company managed remember that there is no in place conversion. Look for answers that involve creating a new project and migrating issues.

The correct answers are All workflows will have their statuses consolidated into three default columns To Do In Progress and Done and Some issues will not be visible on the Scrum board.

The reason All workflows will have their statuses consolidated into three default columns To Do In Progress and Done is correct is that a Scrum board maps workflow statuses into board columns. When you create a new board it starts with the default columns To Do In Progress and Done and the various statuses from each project workflow are placed into those columns by the board configuration. You can later edit the columns and explicitly map or move statuses to match how your teams work.

The reason Some issues will not be visible on the Scrum board is correct is that the board only shows issues that match its filter and that are mapped to a column. Any issues in statuses that are not mapped to a column will not appear on the board and the board filter or project permissions can also exclude certain issues from view.

No issues will be displayed on the board is incorrect because a board will display issues that match its filter and that are mapped to one of the board columns. Boards do not default to showing no issues at all.

Statuses are taken only from the first project chosen during board creation is incorrect because the board aggregates statuses from all projects included by the board filter or selection. Statuses are not limited to the first project you pick.

You are prevented from creating a board that includes more than one project is incorrect because Jira lets you create boards that draw from multiple projects by using a filter or by selecting multiple projects when creating the board.

When answering questions about boards focus on two concepts. Check the board’s filter to see which issues are included and check the column to status mapping to see which issues will actually appear on the board.

All exam questions come from my Jira ACP-620 Udemy course and certificationexam.pro

The correct option is To Do = 5 tasks In Progress = 1 task Done = 0 tasks.

Begin with five tasks in the To Do column. On day one two tasks moved into In Progress which left the remainder in To Do. On day two one of those In Progress tasks moved into Done. On day three that Done task was removed and placed back into To Do which results in the final board snapshot showing the returned task in To Do, one task still in In Progress and no tasks in Done. The Cumulative Flow Diagram will reflect those column counts at that snapshot.

To Do = 4 tasks In Progress = 1 task Done = 1 task is incorrect because the task that was in Done was removed and returned to To Do so Done ends at zero rather than one and the returned task increases the To Do count above four.

To Do = 5 tasks In Progress = 2 tasks Done = 1 task is incorrect because only one task remains in In Progress at the final snapshot and the Done column is empty after the removal.

To Do = 4 tasks In Progress = 2 tasks Done = 0 tasks is incorrect because In Progress has only one task at the end and the moved back task results in five tasks in To Do rather than four.

Recreate the board state step by step and focus on the current snapshot counts when interpreting a cumulative flow diagram.

The correct options are Assign Issues and Transition Issues.

Marco needs the Assign Issues permission because that permission lets a user change the assignee field and assign tickets to other teammates. He also needs the Transition Issues permission because that permission allows a user to move an issue through workflow statuses and change its status as it progresses.

Not being the assignee is a constraint on how Marco should use the project rather than a permission he must hold. That rule can be enforced by a workflow condition or by team process and does not require a separate project permission beyond Assign Issues to put someone else in the assignee field.

Move Issues is not required here because that permission lets a user move issues between projects or change issue types. It is not needed simply to assign issues or to change workflow status.

Edit Issues is not correct because editing general issue fields is different from assigning issues or performing workflow transitions. You do not need Edit Issues to perform those two specific actions if the proper assign and transition permissions are granted.

Assignable User is incorrect because that control determines whether a user can be selected as an assignee. It does not grant the ability to assign issues to others. The ability to assign is granted by Assign Issues.

Create Issues is not required because creating new tickets is a separate action from assigning existing tickets or moving them through workflow. Marco does not need create rights to perform the responsibilities described.

When answering permission questions map each responsibility to the specific action it controls. For example remember that Assign Issues controls the assignee field and Transition Issues controls moving an issue through the workflow.

The correct options are Iteration and Workflow transition.

Iteration is not a named component of Jira Cloud automation rules. Jira automation is built around starting events, checks, and actions, and it does not provide a separate component called Iteration as part of the rule building blocks.

Workflow transition is not listed as a distinct automation rule component either. Automation can perform a transition by using an action such as Transition issue, but the phrase Workflow transition refers to workflow concepts rather than to one of the core rule components.

Trigger is incorrect because triggers are the component that start an automation rule when a specified event or schedule occurs.

Branching is incorrect because branching or branch rules let an automation rule run actions for related issues or for each matched item and they are considered part of the rule structure.

Action is incorrect because actions are the components that make changes or cause effects when conditions are met.

Condition is incorrect because conditions are the components that filter or gate execution so that actions only run when specific criteria are satisfied.

When answering questions about automation components remember to look for the standard building blocks such as trigger, condition, action and branching rules rather than names that describe workflow concepts or programming constructs.

The correct answers are A board sub filter, Quick filters configured on the board, and The “Hide completed issues older than” board setting.

A board sub filter is an additional filter that the board applies on top of the board’s saved filter. It restricts which issues are displayed on the board itself, so issues can appear in Advanced Issue Search but be removed by the sub filter and not show as cards on the board.

Quick filters configured on the board are user toggles that limit the visible cards when they are active. If one or more quick filters are turned on the board view will hide issues that do not match those quick filters even though the saved filter would include them.

The “Hide completed issues older than” board setting removes resolved or completed issues older than the configured threshold from the board view. Those older completed issues can still appear in Advanced Issue Search but will not be shown on the board if this setting is excluding them.

Board swimlanes are a layout feature that groups issues visually and do not remove issues from the board. Swimlanes change placement only and will not cause cards to be missing.

The board saved filter is the base JQL that defines the board’s issue set. If running that saved filter in Advanced Issue Search returns the issues then the saved filter is not the reason some cards are missing on the board.

Issue security levels restrict who can see an issue across Jira. If issue security were preventing visibility the issues would not appear in Advanced Issue Search for that user either, so it does not explain seeing them in search but not on the board.

The board card layout only controls which fields appear on each card and how they look. It does not filter out or hide specific issues from the board.

When a board shows fewer cards than a saved filter run, first check the board sub filter, any active quick filters, and the board setting that hides completed issues older than the configured threshold.

The correct answer is: Add a comment on an issue with the link, Add a shortcut on the project sidebar that points to the website, and Use the issue view to add a web link to the issue details.

Add a comment on an issue with the link works well because comments are visible to everyone who follows the issue and they do not require changing project configuration. A comment is quick to add and it keeps the link in the conversation thread where the team is likely to see it.

Add a shortcut on the project sidebar that points to the website is appropriate when you want the link to be highly visible and persist across the project for all members. A sidebar shortcut gives project level discoverability so team members can find the security guides without opening an issue.

Use the issue view to add a web link to the issue details is correct because the issue details are intended to store reference information and metadata for the work. Placing a web link in the issue details attaches the resource to the work item and makes it easy to find when someone reviews the issue.

Use the project overview to store the website link is incorrect because the overview is not designed for storing and surfacing persistent links for team workflows. The overview area can be less prominent and it is not the standard place the team will check for reference materials.

Create a linked issue pointing to the website is incorrect because creating a linked issue is meant to relate work items to each other and not to serve as a clean way to publish external reference links. That approach adds noise and extra issues instead of putting the link where the team will naturally look.

When you choose how to share a link think about visibility and persistence. Use comments or issue details for conversational context and use a project sidebar shortcut when you want a link to be prominent for the whole team.

The correct option is Board filter.

Board filter is the board setting that defines which issues are included on a board by using a JQL query. Maria can update or replace the board filter to exclude issues with the Platform component so those issues no longer appear on her board and are not included in the board reports.

Swimlanes only change how issues are grouped and displayed on the board and they do not remove or exclude issues from the board or its reports.

Board sub-filter is a secondary filter used for limited cases such as hiding certain completed items or specific sub-task behavior and it is not the primary mechanism to exclude a component from board results and reports.

Quick filters provide temporary, user-toggled views on a board and do not change what is returned in reports or what other users see unless the underlying board filter is changed.

Saved filter is a reusable JQL search that can be applied in many places but by itself it does not change a board. A saved filter only affects a board if it is explicitly used as the board filter.

When you need a change to affect both the board and its reports look for the setting that uses JQL to define board membership and focus on the board filter.

The correct answer is: Watched Issues and Filter Results.

The Filter Results gadget displays issue rows from a saved filter and allows you to choose which columns to show. You can include the Training Environment custom field as one of the selected columns so it appears alongside Issue Type, Key, Summary and Priority.

The Watched Issues gadget lists issues you are watching and also lets you configure which fields display as columns. That configuration supports custom fields so Training Environment can be shown in the gadget.

The Issue Statistics gadget is not correct because it only shows counts grouped by a chosen field and it does not present issue rows with configurable columns.

The Activity Streams gadget is not correct because it shows a feed of recent activity rather than a table of issues, and it does not provide column configuration for custom fields.

The Two Dimensional Filter Statistics gadget is not correct because it produces a matrix of counts across two fields and it is not a row based list that can display custom field columns.

When you need specific fields on a dashboard choose gadgets that let you pick columns and then test the gadget with a saved filter to confirm your custom fields appear.

The correct answer is status was not Completed.

status was not Completed uses JQL historical searching to return issues that have never been in the Completed status. The operator “was not” looks at the change history of the status field and excludes any issue that at any point had the Completed status, so only issues that have never been completed are returned.

status != Completed is incorrect because it only checks the current status of issues. That query will list issues that are not currently Completed but it will include issues that were Completed in the past and then moved out of that status.

resolution is EMPTY is incorrect because resolution is a different field than status. An empty resolution finds unresolved issues but it does not guarantee the issue was never in the Completed status since resolution can be changed independently of status.

status was in (“Backlog”,”Active”) is incorrect because it finds issues that were ever in Backlog or Active. That query does not exclude issues that were also in Completed at some point, so it does not satisfy the requirement.

status changed TO Completed is incorrect because it finds issues that have been moved into Completed at least once. That is the opposite of what the question asks for, since those issues have been in Completed.

Remember that queries using history operators like was or was not examine change history. If the question asks about whether an issue has ever been in a status use the history operators rather than current field checks.

The correct answer is Creating multiple issues in a single operation. This choice names a bulk create capability that is not offered as a native, single step feature across both enterprise managed and team managed projects.

Team managed projects do not include the same built in bulk create and bulk change features that are available in enterprise or company managed projects. Administrators can use site level CSV import or automation rules to generate many issues at once but those are different workflows and they require broader permissions or separate tools rather than a simple in project multi create operation.

Working on issues in weeklong iterations is available in both project types because both support boards and sprints or iterations so teams can plan and work in short cadence cycles.

Defining who may view specific issues is available in both types through project permissions and visibility controls so teams can manage who sees issues either by project level settings or through permission schemes and sharing options.

Prioritizing work continuously using a backlog and an Agile board is available in both project types because both provide backlogs and agile boards that let teams order and continuously prioritize work.

When a question contrasts team managed and enterprise managed features focus on whether the feature is a simple project level control or a broader scheme or administrative function. Look for mentions of bulk operations as a clue that the feature may not be available in team managed projects.

The correct options are A quick filter is currently applied, The board saved filter was modified, and The user does not have Browse Projects permission on some projects on the board.

A quick filter is currently applied is correct because quick filters temporarily narrow the issues shown on a board and they can hide issues that otherwise match the board columns and status mappings. Check the board header for any active quick filter and clear it to restore the full issue set.

The board saved filter was modified is correct because a board uses a saved filter or JQL to determine which issues belong to it and any change to that filter will change which issues appear. Review the board configuration and the filter query to ensure the filter still includes the projects and issue types you expect.

The user does not have Browse Projects permission on some projects on the board is correct because project permissions control issue visibility and a user without the Browse Projects permission will not see issues from those projects even if the board filter and column mappings would include them. Verify the permission scheme for each project to ensure the user can view issues.

A board sub-filter is excluding issues is incorrect in this scenario because a board sub-filter is an advanced setting that is not commonly used and the more likely causes are active quick filters, a changed board filter, or missing project permissions. You should still check sub-filters if the other checks do not resolve the problem.

The user is missing View Development Tools permission is incorrect because the View Development Tools permission only controls access to development information panels and integrations and it does not prevent issues from appearing on the board.

When a Scrum board is missing issues check quick filters first then verify the board filter JQL and finally confirm the user has Browse Projects permission in each relevant project.

All exam questions come from my Jira ACP-620 Udemy course and certificationexam.pro

The correct option is Number of pipelines.

Jira’s Development panel surfaces linked development activity such as commits, builds, pull requests, and branches for an issue. It does not present a separate metric called Number of pipelines even though pipeline runs may appear as build activity in some integrations.

Total commits and the date of the most recent commit is shown in the Development panel because Jira aggregates commit information from connected repositories and displays counts and recent commit details.

Number of builds and their current statuses is shown because the panel reports build results and statuses that come from integrated CI systems and repository services.

Number of pull requests and their statuses is shown since pull request data from linked repositories is listed and its state is visible in the Development panel.

Number of branches linked to the issue is shown because branches that reference the issue key are detected and counted in the Development information.

When the question asks what the Development panel shows focus on development artifacts such as commits, builds, pull requests, and branches and remember that specific CI product terminology like pipelines may not be reported as a distinct count.

The correct option is Automation rule.

An Automation rule can be triggered when an issue transitions into the “DEV REVIEW” status and it can create or clone an issue while copying file attachments. The built in actions let you create a new issue, clone an existing one, copy attachments and set fields so the entire process can run automatically without custom scripting.

ScriptRunner is a powerful add on that can perform this with custom scripts but it requires scripting knowledge and an additional app so it is not the simplest native solution.

Bulk Change is intended for manual batch operations across many issues and it does not run automatically on a single issue transition so it cannot meet the requirement.

Workflow post-function executes during a transition and can perform actions but the built in post functions do not provide an easy way to duplicate an issue and transfer attachments without custom code or third party apps so it is not the best choice.

When you are asked to automate actions on a transition think of Automation rule first because it provides triggers, actions and attachment handling without having to write code.

The correct answer is Team members do not have edit rights in the other project.

This situation happens because dragging an issue into an epic modifies the issue and possibly the epic link field in the target project. If users do not have the project level Edit Issues permission in that other project then Jira will block the change even though the board shows issues from both projects. Granting the appropriate edit or role based permission in the target project lets team members link or move issues into epics across projects.

The board filter limits issues to a single project is unlikely in this scenario because a combined board was created to span both projects. A filter that only included one project would prevent issues from the other project from appearing on the board rather than selectively blocking drag actions due to permissions.

Users are missing global site level permissions is not the best answer because editing and linking issues are controlled by project level permissions in Jira. Global permissions cover administration and site wide actions and they do not normally prevent a user from editing an issue in a specific project.

Epics cannot include issues from projects outside their own project is incorrect because Jira Software supports epics that span projects when the epic link is available and users have the necessary project permissions. Cross project epic association is allowed when permissions and field configuration permit it.

When you see a drag or link failure check the target project level permissions first and confirm the board filter includes all relevant projects. Also verify the Edit Issues and Link Issues permissions for the users involved.

The correct answer is text: text ~ “Compliance” OR text ~ “AML” OR text ~ “SEC”.

text: text ~ “Compliance” OR text ~ “AML” OR text ~ “SEC” is correct because the text ~ operator performs a full text search across an issue’s searchable text fields including summary description comments and work logs and the OR operators will return issues that contain any one of the specified terms.

text: text in (“Compliance”, “AML”, “SEC”) is incorrect because JQL does not support using in with the free text text field in this way and that syntax is not valid for full text searches.

text: description ~ “Compliance” OR description ~ “AML” OR description ~ “SEC” is incorrect because it only searches the description field and it will miss matches that appear in summary comments or other searchable text fields.

text: summary ~ “Compliance” OR summary ~ “AML” OR summary ~ “SEC” is incorrect because it restricts the search to the summary field and it will not find issues where the terms appear outside the summary.

When you need to search across all searchable text fields use text ~ and combine multiple terms with OR to match any of them.

Labels cannot be removed after they have been created is the correct choice because that statement is the one that is false about Labels in TrackerPro.

The statement is incorrect because labels are not permanent and they can be removed when they are no longer needed. Users can edit an issue to remove labels and administrators or users with the right permissions can clean up or delete labels from the system so labels do not have to remain once created.

Label values are case sensitive is not the incorrect statement. Label value case sensitivity is a real property of many issue trackers and therefore that claim does not make it the wrong option in this question.

Labels are displayed as clickable links to related issues is not the incorrect statement. Labels are commonly shown as links or filters that let users view related issues, so this behavior supports the statement rather than contradicting it.

The Labels field can be used in the Issue Metrics gadget is not the incorrect statement. The Labels field is often available for filtering and grouping in reporting and gadget views, so this option does not represent a false claim about label capabilities.

When a question asks which statement is incorrect read each option as a factual claim and eliminate the ones that match known product behavior. Pay attention to absolute words like cannot which often point to the false statement.

Moving a parent moves all of its subtasks together and Subtasks can be rearranged relative to their sibling subtasks are correct.

When you move or rank a parent issue on the backlog or board the parent and its nested subtasks remain grouped so the whole group moves together and the parent retains its relationship to those subtasks.

You can also reorder subtasks within the same parent so that sibling subtasks appear in a different sequence without having to move the parent itself. This lets you adjust the internal order of work items while keeping them under the same parent.

Subtasks keep fully independent order from their parent is incorrect because subtasks are shown as children of their parent and the parent and its subtasks are treated as a grouped unit when the parent is moved.

You must rank every subtask before you can rank its parent is incorrect because you can rank the parent issue directly and move the entire group without first ranking each individual subtask.

When answering ordering questions remember to think about grouping and ranking. Moving the parent usually moves its nested items, while you can still reorder sibling subtasks independently.

The correct option is Company managed Kanban project.

A Company managed Kanban project provides a dedicated backlog column and flexible board columns so the team can keep an extensive backlog in its own column while work flows through the board. It also supports robust board configuration and advanced reports such as the cumulative flow diagram and control chart so the team can produce visual reports that group and surface issues. Company managed projects offer configurable quick filters and card highlighting so high priority issues can be located quickly on the board.

Scrum team managed project is not ideal because Scrum focuses on timeboxed sprints and sprint planning rather than a continuous backlog column on the board, and team managed projects have fewer built in reporting and configuration options.

Kanban team managed project provides a simple Kanban board but it has more limited customization and fewer advanced reports than a company managed project, so it may not meet the requirement for visual reports that group issues at scale.

Company managed Scrum project is not the best fit because Scrum projects organize work into sprints and are not focused on a single continuous backlog column and flow, so locating and visualizing a large, continuously managed backlog is harder than with a Kanban setup.

When a question asks for a continuous backlog plus strong reporting think Kanban for flow and company managed for the most configurable boards and reports.

Ben is correct.

When the assignee is set to Automatic the system evaluates the default assignee settings of the selected components. The selected components were UI, Auth, and Service-ALP. UI’s default assignee is Project Lead so it resolves to the project lead Nora. Service-ALP’s default assignee is Project Default so it also resolves to the project default which is the project lead Nora. Auth’s default assignee is Component Lead and the Auth component lead is Ben. Because one selected component explicitly uses the Component Lead setting that component lead takes precedence and the issue is assigned to Ben.

Cara is incorrect because although Cara is the component lead for Service-ALP that component’s default assignee is set to Project Default rather than Component Lead so the assignment does not go to Cara.

Alex is incorrect because Alex is the UI component lead but the UI component’s default assignee is Project Lead so the UI selection resolves to the project lead rather than to Alex.

Nora is incorrect because while Nora is the project lead and the project default assignee she is overridden in this case by the Auth component which is configured to assign to its Component Lead and that lead is Ben.

When multiple components are selected check each component’s default assignee and watch for any set to Component Lead because that will usually determine the assignee.

The board filter includes issues from multiple projects is the correct answer.

The timeline view is scoped to the board and it uses the board filter to determine which issues to display. If the board filter pulls issues from more than one project then the timeline cannot present a unified project timeline and the timeline view will not be available. Check the board filter JQL and narrow it to a single project or create a project-specific board to restore the timeline.

The project is team managed is not likely the cause because team managed projects have their own roadmap features and board type alone does not prevent the timeline from appearing. The visibility issue is more often related to the board filter than the project template.

There are no Epics in the project would not remove the timeline control itself. You might see an empty timeline with no epic bars, but the timeline view would still be present rather than completely missing.

Lina lacks the View Read Only Workflow permission is unrelated to timeline visibility because that permission controls access to workflow details and not whether the board can show the timeline view.

The timeline feature has been disabled by the board administrator is unlikely because there is no single per-board feature switch that simply disables the timeline. Administrators can change filters and board settings which affect visibility but there is not a one click toggle to hide the timeline.

When a timeline or roadmap is missing first check the board filter and confirm whether it returns issues from only one project. Narrow the filter to a single project or create a dedicated board to quickly troubleshoot visibility.

The correct options are Project dashboard, Issue security level, and Saved filter subscription.

Project dashboard can be controlled at the project level by assigning project roles so that specific roles can have view or edit access to a dashboard that pertains to that project.

Issue security level uses project roles to determine who can see particular issues because security levels reference roles or users to limit visibility within the project.

Saved filter subscription can target project roles so that members of a role receive scheduled filter results for the project and stay informed without individual configuration.

Application access is not correct because application access is a global user entitlement and it is managed at the site level rather than being assigned per project role.

Group membership is not correct because groups are a separate identity construct and you assign users to groups rather than assigning groups as a configuration item to a project role.

Global permission is not correct because global permissions apply across the whole instance and are granted at the global level rather than being bound to project roles.

Look for the scope of the item to decide if it belongs to a project role. Project-level scope usually means it can be assigned to a project role while global scope usually means it cannot.

All exam questions come from my Jira ACP-620 Udemy course and certificationexam.pro

The correct options are Activity Stream, Introduction, Projects and Labels Gadget.

The Activity Stream gadget surfaces recent changes and commentary across the Jira instance so new users can quickly see who is doing what and which issues are active. This makes it useful for onboarding because it provides a running summary of instance activity and helps new users orient themselves.

The Introduction gadget is designed to present helpful links and onboarding text so administrators can place guides, links to documentation, or pointers to key workflows directly on the dashboard. That makes it a natural choice for an onboarding screen.

The Projects gadget lists projects and gives newcomers an entry point into the different teams and contexts they will work in. Project-level discovery helps users find relevant boards and backlogs without hunting through menus.

The Labels Gadget highlights common labels and lets users explore issues by tag. This helps new users identify recurring topics and areas of interest across the instance and makes discovering related work easier.

Watched Issues is focused on an individual user’s watched list and does not provide an instance wide summary, so it is not ideal for a general onboarding dashboard.

Favorite Filters shows saved filters that are useful to power users but it depends on specific filters being created and shared, so it is not as universally helpful for initial onboarding.

Voted Issues reflects a user specific voting activity and popularity signals rather than providing broad context, so it does not meet the requirement for summarizing overall instance activity for new users.

Issue in progress is not a gadget that provides a wide overview and typically focuses on single issue state, so it does not offer the collection of helpful links and instance level summaries needed for onboarding.

When building onboarding dashboards pick gadgets that give instance wide context and place clear navigation links or instructions up front so new users can find resources and relevant projects quickly.

Triggers is the correct option.

Triggers are the automation component that monitor the events users choose and start rule execution. They listen for events such as issue created, issue updated, comment added, or scheduled times and when a configured event occurs they kick off the rule so the system can evaluate Conditions and then run Actions.

Conditions are evaluated after a Triggers event fires to decide whether the rule continues. They do not observe events or begin rule execution.

Webhooks are an external mechanism that can send events into the system but they are not the automation component that monitors chosen events and starts a rule. Webhook calls can feed a Triggers type but Webhooks themselves are not the rule starter.

Actions perform the work that changes issues sends notifications or updates fields after a rule has started. They do not monitor for events and they do not start rule execution.

Requirements is not a standard automation component that watches for events. The term might refer to preconditions for a rule but it does not act as the event listener that starts the rule.

Steps is a generic term for parts of a rule and it does not specifically refer to the event listener. Rules are built from a trigger plus conditions and actions which together form the steps but the listener role belongs to Triggers.

When you must identify the component that starts an automation rule think about which element listens for events. Triggers start the flow while conditions and actions operate after the trigger has fired.

The correct option is Quick Filters append an extra JQL clause to the board’s primary filter so the board filter remains in effect.

Quick Filters operate by adding an additional JQL clause to the board’s base filter at query time so the board filter still defines the full set of issues and the quick filter simply narrows that set further. Quick Filters are defined per board and work the same way on both Kanban and Scrum boards.

Quick Filters are available only on Scrum boards and do not appear on Kanban boards is incorrect because quick filters are a standard board feature and are available on both Scrum and Kanban boards.

The built-in Quick Filters named “Only My Issues” and “Recently Updated” cannot be changed is incorrect because the default quick filters can be edited or removed by users with the appropriate board administration permissions and you can also add custom quick filters.

Only board administrators and project administrators are allowed to create Quick Filters is incorrect because creating and editing quick filters requires board administration rights and project administrators do not automatically have those rights unless they are also board admins. Jira administrators may also change boards depending on instance permissions.

When a question uses absolute words like only or cannot double check whether the product documentation actually enforces that limitation before choosing the option.

The correct options are Members of the “site-owners” group can create company-managed projects by default and Users with the “Administer TaskFlow” global permission can create company-managed projects.

Members of the “site-owners” group can create company-managed projects by default is correct because site owners are granted elevated, site level control that includes creating and managing projects that are governed at the company level. Company-managed projects rely on global or site level controls and those controls are typically assigned to site owner groups.

Users with the “Administer TaskFlow” global permission can create company-managed projects is correct because a global administration permission grants the ability to manage TaskFlow settings and to create projects that are managed across the company. Global permission holders have broader capabilities than ordinary licensed users and can perform project creation at the company scope.

“Create Projects” global permission is required to create a company-managed project is incorrect because the ability to create company-managed projects is tied to site ownership or specific global administrative permissions rather than a single generic flag in all TaskFlow setups. The named permission may not be the exclusive requirement for company-managed project creation.

Only project administrators can create team-managed projects in TaskFlow is incorrect because team-managed projects are generally created by users with the right to create team projects and they do not require existing project administrator status. Team-managed projects tend to have less restrictive creation rules than company-managed projects.

You need the “View Projects” permission to create a company-managed project is incorrect because view permissions only allow reading project details and they do not grant the ability to create new projects. Creating projects requires higher level permissions such as global administration or site ownership.

Any licensed user can create both company-managed and team-managed projects is incorrect because licensed users may be allowed to create team-managed projects only when instance settings permit it and they generally cannot create company-managed projects without elevated global or site permissions.

When the question is about who can create projects focus on whether the permission is a global or site level right or a project role. Keep in mind that site owners and global admins usually control company-managed project creation while team-managed creation is often more permissive.

The correct option is Open.

Open gives site users access to a team managed project without requiring the project creator to assign project roles. That means team members who already work on other Jira Kanban boards can access and interact with the new board and reorder backlog items without Lucas having to add them to project roles.

Limited is incorrect because limited access requires explicitly granting access to specific users or groups and so would force Lucas to assign permissions rather than leave access implicit.

Public is incorrect because it does not match the team managed project access model needed here and it would not provide the intended controlled site user access without role assignments.

Unlimited is incorrect because it is not a valid Jira project access level for team managed projects and so it cannot satisfy the stated requirements.

Private is incorrect because a private project requires explicitly adding members or roles to grant access and that would require Lucas to assign project roles after creating the project.

When a question asks that users should be able to access a project without assigning roles look for the Open access option for team managed projects because it grants site user access by default.

Issues that are in the Completed status but not mapped to a column will not be marked as completed for the sprint and will be returned to the backlog is the correct option.

When a board has no column mapped to the Completed status the board does not treat that status as done. Jira determines completed work by which statuses are mapped to the board’s rightmost column. Because the Completed status lost its column mapping those issues are not counted as completed when the sprint is closed and they are returned to the backlog. This is why Issues that are in the Completed status but not mapped to a column will not be marked as completed for the sprint and will be returned to the backlog.

Items in the QA column will be recorded as completed for the sprint and will be removed from the backlog is incorrect because completion is determined by the status to column mapping and not simply by the column name. If the Completed status is unmapped then issues that were in Completed will not be recorded as completed even if another column is now the rightmost column.

You will be prompted to either move the issues in the QA column to the next sprint or return them to the backlog is incorrect because Jira only prompts for unresolved issues when closing a sprint. Issues that are mapped to the board’s rightmost column are treated as done and do not generate that unresolved prompt. The prompt behavior affects unresolved work not statuses that were removed from column mappings.

Issues in the QA column will be marked as uncompleted for the sprint but they will be removed from the backlog is incorrect because unresolved issues are returned to the backlog rather than being removed from it. Removing items from the backlog is not part of the standard sprint close behavior for unresolved work.

Remember that the board’s rightmost column defines what is considered done. Check the status to column mappings when a question asks about sprint completion.

The correct options are Groups and individual user accounts can be assigned to project roles, Project roles are referenced by permission schemes to govern project access, and Project administrators can change a role’s membership inside a specific project.

The statement Groups and individual user accounts can be assigned to project roles is correct because project roles are intended to contain both user accounts and groups so that permissions can be granted at the role level rather than to each user individually. This lets administrators manage access more efficiently by assigning roles rather than repeating assignments for each person.

The statement Project roles are referenced by permission schemes to govern project access is correct because permission schemes assign permissions to roles and not to projects directly. Permission schemes map actions to roles so that changing a role membership changes who has the associated permissions without altering the scheme itself.

The statement Project administrators can change a role’s membership inside a specific project is correct because project administrators typically have the ability to add or remove users and groups from roles only within the scope of that project. This allows per project adjustments without affecting other projects that use the same role name.

The statement Project administrators can alter the default members that are applied to every newly created project role is incorrect. Default members for project roles are part of the global configuration and are managed at the system or site administration level rather than by individual project administrators. Allowing project admins to change global defaults would affect every new project and so that capability is reserved for higher level administrators.

When deciding between answers think about scope. If a change affects every project then it is likely a global or system administration task and not something a project administrator can do.

The correct options are Create multiple plan scenarios and switch among them to compare timeline outcomes and Assemble cross project plans and align cross project releases.

Create multiple plan scenarios and switch among them to compare timeline outcomes is correct because Advanced Roadmaps lets planners build alternative versions of a plan to test different assumptions. You can change scope dates or team assignments in a scenario and then switch between scenarios to see how timelines and delivery dates shift.

Assemble cross project plans and align cross project releases is correct because one of the core capabilities of Advanced Roadmaps is to bring issues from many projects into a single plan and to align releases and dependencies across teams. That unified view is what enables realistic end to end timelines across multiple Agile teams.

Export plans in Microsoft Project format is incorrect because exporting to Microsoft Project is not the feature that Advanced Roadmaps is known for and it does not address creating alternative timeline scenarios across many teams.

Native support for the SAFe framework is incorrect because Advanced Roadmaps does not provide a single built in SAFe template or certification. You can model hierarchies to match scaled frameworks but there is no turnkey native SAFe implementation.

Team capacity planning and utilization views is incorrect in this question because although Advanced Roadmaps provides some capacity and allocation information, the feature set called out for planning and comparing alternate timelines across many teams is focused on scenarios and cross project alignment rather than on detailed per team utilization reporting.

When a question asks about evaluating alternative timelines look for options that explicitly mention scenarios or cross project plans. Treat export functions and framework templates as distractors unless the question specifically asks about those items.

Turn on the Kanban backlog feature for the board is correct.

Enabling the Kanban backlog gives you a separate backlog area that stays out of the main board columns and that prevents the planning column from becoming overloaded. The backlog area is designed to hold items you are not actively working on so you can keep the planning column focused on items you intend to refine or start soon.

Create a new workflow status and add a column then leave that status unmapped is wrong because adding an unmapped status and column changes your workflow and can hide or misplace issues. It also complicates workflow management and is not the intended way to separate backlog work from active board columns.

Modify the board filter to hide issues in the planning status is wrong because filtering will remove issues from the board entirely for all users and can break visibility and reporting. Hiding items is not the same as separating a backlog area and it is a blunt instrument compared with the backlog feature.

Add a distinct backlog column to the board is wrong because putting backlog items into a regular column makes them part of the board flow and can distort work in progress and metrics. The Kanban backlog feature is the correct mechanism to keep backlog items out of the board columns without altering workflow semantics.

When a planning column is crowded try the Kanban backlog first instead of changing workflows or board filters so you preserve visibility and metrics.

Assign Maya to a project role that is listed under the “Manage sprints” permission is correct.

The Assign Maya to a project role that is listed under the “Manage sprints” permission option grants the specific project permission that controls sprint creation and ordering on company managed Scrum boards. Project roles that are added to the “Manage sprints” permission allow members to create, start, complete and reorder sprints, so assigning Maya to such a role gives her the needed sprint management capabilities.

Add Maya to a project role that has the Administer projects permission is incorrect because the Administer projects permission gives project configuration and administration rights but it does not grant the sprint management actions on company managed boards unless the Manage sprints permission is also granted.

Make Maya a board administrator of the Scrum board is incorrect because board administrators can change board settings and filters but they do not automatically gain the project level Manage sprints permission that controls creating and reordering sprints on company managed boards.

Add Maya to a project role that has the Schedule issues permission is incorrect because Schedule issues only controls editing issue dates and scheduling fields and it does not allow creating or reordering sprints.

When a question asks about sprint creation or ordering look for the specific project permission named Manage sprints because roles or board admin status do not automatically grant that capability.

All exam questions come from my Jira ACP-620 Udemy course and certificationexam.pro

The correct answer is The action was changed from Create sub tasks to Create issues using the sub task issue type.

When the action was swapped in this way the rule may still create an issue with the sub-task issue type but it does not behave the same as the dedicated sub-task action. The dedicated sub-task action attaches each created item to the trigger issue as a child by default. If you use a generic create issues action you must explicitly set the parent or use a branch to associate the new issues with the original issue. This mismatch commonly results in only one properly parented sub-task or unexpected single creations when the original rule expected multiple sub-tasks.

The automation actor does not have the Create Issues permission is incorrect because lack of create permission causes the rule to fail or log permission errors and it would not silently create a single sub-task. Permission problems are visible in the audit log and do not explain why one item is created.

The rule is configured to run only once per issue so it only executes its post actions a single time is incorrect because the symptom describes a single execution that creates one sub-task instead of multiple creations within that execution. A rule limited to run once per issue would prevent repeated triggers but would not change how many child items a single execution creates.

The branch that iterates to create multiple sub tasks is missing from the rule is incorrect in this specific case because the rule did execute and produced a sub-task. If an iteration branch were missing you would expect the design to have no iteration at all and the rule would not attempt multiple creations. The observed behavior fits a changed action type more closely than a missing branch.

When troubleshooting automation check the exact action used and whether the rule sets the parent field or uses a branch to iterate. The Create sub tasks action automatically parents issues while the generic Create issues action does not, so verify you are using the correct action.

The correct answer is Activate the backlog setting that displays the “Epics” panel.

The Epics panel is an optional backlog view element that can be turned on or off in the board backlog settings. Enabling that backlog setting will make the Epics panel appear alongside the Releases panel for the Kanban backlog.

The “Epics” panel cannot be displayed on a Kanban backlog is incorrect because Kanban backlogs can show an Epics panel when the backlog option is enabled.

Issues from the team-managed project must be removed from the board filter is incorrect because including a team-managed project in the board does not force the Epics panel to be hidden. The missing panel is caused by the backlog setting rather than the presence of a team-managed project.

Lena lacks the required permissions to enable the Epics panel is incorrect because the visibility of the Epics panel is controlled by the board backlog settings. If the panel is missing the setting is the usual cause rather than a permissions issue.

Open the board settings and check the backlog options when a panel is missing and enable the Epics panel if it is turned off.

Custom field Select List single choice is correct because it forces users to choose exactly one planet and it stores a single, indexed value per issue that the Issue Statistics gadget can aggregate for accurate counts.

A Select List single choice is ideal for a fixed catalog of ten planets because the options are predefined and standardized. This prevents freeform entries and ensures each issue contributes one unambiguous value to gadget reports.

Labels is wrong because labels are freeform and multi valued so users can add inconsistent or misspelled planet names and the counts will be unreliable.

Custom field Checkboxes is wrong because checkboxes allow multiple selections and the gadget would not reflect a single associated planet per issue when aggregating counts.

Custom field Text Field single line is wrong because a text field accepts freeform input and values will not be standardized so the Issue Statistics gadget cannot reliably aggregate them.

Component/s is wrong because components are project scoped and they can be applied in multiple values which makes them unsuitable for enforcing a single, global planet choice for accurate issue counts.

When a question requires a single, countable value choose a field type that enforces one selection and produces standardized, indexed values such as a Select List single choice.

Linked code repositories and Project shortcuts are the elements a project administrator can add directly from the project navigation sidebar in a Jira Cloud project.

Linked code repositories can be added from the project navigation because Jira exposes development and repository linking features in the project view so that you can connect the project to external code hosting or integrated development tools without needing global admin rights.

Project shortcuts are configurable directly in the sidebar so a project administrator can add links that help the team access external pages or important internal resources from within the project navigation.

Project avatar is incorrect because the project image is managed in the project settings or by changing the avatar in the project administration screen rather than by adding it from the navigation sidebar.

Issue templates is incorrect because creating or managing reusable issue templates is done through template management features or global configuration and not by adding templates directly from the project sidebar in most Jira Cloud setups.

Project short description is incorrect because the project description or summary is edited in the project details or settings area and not added as an item directly from the navigation sidebar.

Read each option carefully and think about whether it is a sidebar item or a setting elsewhere. Sidebar items like shortcuts and repository links are added from the project view while avatars and descriptions are edited in project settings.

The correct option is project = VENUS and resolution changed from “Abandoned” to “Completed”.

This query works because the resolution field is recorded in the issue change history and JQL supports the changed operator to search for field transitions. Running the query returns all issues in the VENUS project where the resolution moved from Abandoned to Completed so you will locate the mistakenly updated issues.

Contact Atlassian support for assistance locating the affected issues is incorrect because you do not need support for this type of search. The issue change history can be queried with JQL so you can find the affected issues yourself.

project = VENUS and resolution = “Completed” and status changed from “Abandoned” to “Completed” is incorrect because it mixes resolution values with a status change. Abandoned and Completed are resolution values in this workflow and the status change clause will not reliably match those transitions. You need to search the resolution change rather than the status change.

Export issue change history or review the issue changelogs to search for resolution updates is not the best answer because it is manual and slower. Exporting or reviewing changelogs can work but the JQL project = VENUS and resolution changed from “Abandoned” to “Completed” query directly returns the impacted issues.

When a question mentions that a field is set by the workflow and that history is available look for JQL using the changed or was operators to find previous values.

The correct answer is Company-managed Kanban board using a board sub-filter.

A Company-managed Kanban board using a board sub-filter can be based on a filter that pulls issues from multiple projects and can also apply a board sub-filter using JQL to automatically exclude issues. You can write a JQL sub-filter that omits issues with the resolution “Won’t Fix” once their resolved date is older than 48 hours so the board hides them automatically. Kanban boards are appropriate here because they do not rely on sprint boundaries and they keep Done issues visible only when the filter allows them.

Company-managed Scrum board using quick filters is incorrect because quick filters are manual toggles that team members must enable or disable and they do not provide automatic hiding after a time period. Scrum boards are also sprint focused which makes automated removal of Done items by time less suitable.

Team-managed Kanban board with a board sub-filter is incorrect because team-managed boards have more limited filtering capabilities and they do not support the same cross-project board and sub-filter configuration that company-managed boards provide. That limitation prevents reliably combining three separate projects and applying an automated sub-filter across them.

Company-managed Scrum board with a board sub-filter is incorrect because Scrum boards are centered on sprints and the workflow for clearing Done issues is tied to sprint completion rather than continuous board filtering. While a company-managed Scrum board can use filters, the Kanban approach better supports continuously hiding Done items after a fixed time window.

When a question mixes multiple projects and automated exclusion by time think about using a company managed board and a JQL sub-filter. Test the sub-filter in Issue Navigator before finalizing the board to confirm it excludes the expected items.

The correct option is Features.

In a team-managed project created from the Scrum template you change whether the team estimates in time or story points in the Project settings under Features. Inside Features there is an Estimation setting in the backlog or board configuration that lets you choose between estimating by time or by story points and it updates the issue fields and backlog display accordingly.

Issue types is incorrect because issue types determine the kinds of issues such as task bug or story and they do not control the project estimation method.

Board is incorrect because board settings control board display and columns but the estimation unit is configured at the project features level for team-managed projects rather than in the board menu.

Details is incorrect because Details typically refers to project or issue metadata and not to the estimation configuration for a team-managed Scrum project.

Access is incorrect because access controls manage user permissions and project visibility and they do not provide options for switching estimation units.

It is not possible to change the estimation setting for a Scrum team-managed project is incorrect because Jira allows switching the estimation type for team-managed projects through Project settings and the Features section.

When you need to find where to change estimation think Project settings and then look under Features for the Estimation or backlog option so you can switch between time and story points.