ACP-620 Managing Jira Projects for Cloud Certification Exam Topics and Objectives

Maya must prepare a vertical bar chart for her team that shows how long tickets stay open before they are closed. Which report should she produce?

• ❏ A. Average Open Age Report

• ❏ B. Pie Chart Report

• ❏ C. Issue Resolution Time Report

• ❏ D. Single Field Grouping Report

• ❏ E. Time Tracking Report

• ❏ F. Issue Date Timeline Report

A release lead at StellarTech created a shared filter using the JQL project = “ORION” and shared it with everyone in her company. She later notices that different team members see different totals of issues when they view the filter results. What could explain the discrepancy? (Choose 4)

• ❏ A. Global permissions

• ❏ B. Project permissions

• ❏ C. Application access

• ❏ D. Filter subscriptions

• ❏ E. Group membership

• ❏ F. Issue type scheme configuration

• ❏ G. Project role membership

Which statements about the Epic issue type in Jira are accurate? (Choose 3)

• ❏ A. An epic cannot be converted into a subtask

• ❏ B. An epic can span issues across several Jira projects

• ❏ C. Users can change an epic’s colour in both Kanban and Scrum projects

• ❏ D. An epic may contain another epic through an epic link

• ❏ E. An epic is unable to have its own issue screen

• ❏ F. Users must turn on the Kanban backlog to manage epics on a Kanban board

Aisha needs to set up a new Jira project for her engineering team at Maple Labs. She needs the team to be able to reorder and prioritize tasks every day using an Agile board. She needs to run work in iterations that can vary in duration from one cycle to the next. She also needs project administrators to be able to manually clear the board rightmost column whenever required. The project must satisfy these capabilities immediately after creation without enabling extra features. Which project type and template should she choose?

• ❏ A. Company-managed project with shared Kanban configuration

• ❏ B. Team-managed project with Bug tracking template

• ❏ C. Team-managed project using the Kanban template

• ❏ D. Company-managed project with Kanban template

• ❏ E. Company-managed project with Scrum template

Assuming Maya has the Edit Issues permission which statements about creating a new project version are accurate? (Choose 4)

• ❏ A. Release Selector custom field

• ❏ B. Impacted versions field

• ❏ C. Resolved versions field

• ❏ D. Versions sidebar

• ❏ E. Releases section

Nina is a scrum master and the board administrator for a company managed Kanban board at SigmaTech for the project ‘ORBIT’. She sees many issues accumulating in the far right column and wants to publish a new release. Which permission must she have to create a new version for the project?

• ❏ A. Close issues project permission

• ❏ B. “Administer projects” project permission

• ❏ C. “Administer Jira” global permission

• ❏ D. Board administrator permission

Which set of workflow components must a project administrator configure to meet these needs? Send an email after a transition completes. Populate the resolution field when the transition runs. Limit who can add attachments to an issue. Only members of the group ‘infosec’ can see the ‘Under Review’ transition button. Ensure that all required fields are not empty during the transition?

• ❏ A. One condition two validators one post function and one status property

• ❏ B. One condition one validator two post functions and two status properties

• ❏ C. One condition one validator two post functions and one status property

• ❏ D. Two conditions one validator one post function and one status property

A development team at Aurora Apps uses a board to manage tasks and needs a report that displays how much work sits in each workflow state, enables the calculation of average throughput and cycle time, and provides both numeric and qualitative insight into historical and current bottlenecks?

• ❏ A. Velocity chart

• ❏ B. Version burndown

• ❏ C. Cumulative flow diagram

• ❏ D. Control chart

• ❏ E. Sprint health report

You provisioned a new Scrum board and made Liam the board administrator. Liam modified the board filter, created several issues, uploaded attachments, set due dates, and edited and assigned items to his team. When he tried to reorder backlog stories by dragging them during sprint planning he was unable to move the issues. What are two possible causes for this behavior? (Choose 2)

• ❏ A. Liam lacks Jira Software product access

• ❏ B. Ranking is disabled in the board saved filter

• ❏ C. Liam is missing the Schedule Issues project permission

• ❏ D. Liam needs Jira Administrators product access

• ❏ E. Liam does not have Manage Sprints project permission

A lead at Meridian Software holds the Administer Project permission for a single project but lacks system administrator rights. Which statement about what they can do is accurate?

• ❏ A. Project administrators can create new system permissions and assign them to project roles

• ❏ B. Project administrators can add users to roles that are specific to their project

• ❏ C. Project administrators can map project roles to system permissions

• ❏ D. Project administrators can define new project roles and grant them project permissions

• ❏ E. Project administrators can add users directly to system permission groups

Hannah is the scrum master at SprintWorks and she has full permissions to view create delete and edit issues in the company managed project “DATAFLOW”. She can set due dates add comments log work and manage sprints and she is the Scrum board administrator. However she cannot reorder subtasks in the backlog. Why is this happening?

• ❏ A. Hannah is missing a project permission

• ❏ B. Hannah is missing a global permission

• ❏ C. It is not currently supported to rank subtask issue types in the backlog

• ❏ D. Hannah requires site administrator privileges

Marco does not have the Schedule Issue permission on his project. If he attempts to move items from the backlog into the current sprint what will occur?

• ❏ A. Jira reorders the issue using the board ranking configuration

• ❏ B. Jira places the issue by its summary in alphabetical order

• ❏ C. The system stops the move because the user lacks the Schedule Issue permission

• ❏ D. The issue is positioned based on the order it was inserted into the sprint

The engineering group at Solstice Labs uses an organization-managed project to track releases and they currently have version “3.4” with status UNRELEASED. They want to move every unresolved issue from version “3.4” into a newly created version “4.0” and still have version “3.4” remain selectable in the Affects Versions field. What single action achieves both objectives?

• ❏ A. Delete version 3.4

• ❏ B. Mark version 3.4 as released

• ❏ C. Archive version 3.4

• ❏ D. Merge version 3.4 into another version

Maya needs a dashboard gadget for her team at CodeFlux to present three sprint metrics on the current iteration. She needs the count of days remaining until the sprint closes the percentage of scope change and the number of flagged issues. Which Jira gadget supplies all of these metrics?

• ❏ A. Sprint Burndown Gadget

• ❏ B. Sprint Health Gadget

• ❏ C. Two Dimensional Filter Statistics

• ❏ D. Velocity Chart Gadget

Priya creates a new Kanban board that spans several company-managed projects for HarborTech and notices that some expected issues are not visible on the board. What could explain the missing issues? (Choose 2)

• ❏ A. A Quick Filter is active and is hiding a subset of the issues

• ❏ B. Some issues have ‘Issue Level Security’ enabled

• ❏ C. The board’s saved filter uses JQL that excludes the missing issues

• ❏ D. The user lacks the Browse Projects permission for some projects

A product team at Meridian Works opens a subtask beneath an existing parent issue in their sprint board. Which field will not be copied from the parent issue to the subtask?

• ❏ A. Sprint assignment

• ❏ B. Issue security level

• ❏ C. Fix versions

• ❏ D. Project

Maya needs to move a collection of automation rules from her Jira staging site into the live Jira environment and she wants the fastest reliable method to do this, what is the best approach?

• ❏ A. Recreate all automation rules manually in the live instance

• ❏ B. Attempt to export and import rules at the project level from staging to production

• ❏ C. Ask the Jira administrator to export the automation rules as a JSON file from the staging site and import that JSON into the live site

• ❏ D. Open a support ticket with Atlassian and request that they migrate the automation rules between sites

Priya manages development work on Kanban boards for a small startup named Marigold Systems and one board has an overflowing Done column that hides recent closures. She only wants to see issues that were completed during the current week. What is the best way to limit the board to this week’s completed issues?

• ❏ A. Quick filters

• ❏ B. Board filter

• ❏ C. Hide completed issues

• ❏ D. Swimlanes

• ❏ E. Board sub-filter

• ❏ F. Automation rule

After a recent configuration change several members of the Skyward team report they can no longer create team-managed projects while they can still view and modify issues on Agile boards. What is the most likely cause?

• ❏ A. Application access setting

• ❏ B. Project level permission

• ❏ C. Board administrator role

• ❏ D. Global Create team-managed projects permission

The hardware team at NovaSensors shipped their initial beacon release last Friday and the next release is planned in three weeks. Which JQL query run today will list all stories that were delivered in version 2.0?

• ❏ A. project = BEACON AND issuetype = Story AND fixVersion in 2.0

• ❏ B. project = BEACON AND issuetype = Story AND fixVersion IS NOT EMPTY

• ❏ C. project = BEACON AND issuetype = Story AND fixVersion in releasedVersions()

• ❏ D. project = BEACON AND issuetype = Story AND fixVersion = latestReleased()

Lina is assembling a new engineering squad at Solace Labs to build a payments service. The client expects features to be delivered on regular sprint cycles and she must produce an Epic report for stakeholders. Which project type should Lina select?

• ❏ A. Team-managed Scrum project

• ❏ B. Company-managed Kanban project

• ❏ C. Company-managed Scrum project

• ❏ D. Team-managed Kanban project

Marcus and Priya work together on the same company controlled Scrum board at Meridian Labs and they can both create comment edit and transition issues without difficulty. Marcus can assign issues to Priya but Priya is unable to assign issues to Marcus. What is the most likely cause? (Choose 2)

• ❏ A. Priya is missing the “Assignable user” project permission

• ❏ B. Marcus is missing the “Assign issues” project permission

• ❏ C. Priya is missing the “Work on issues” project permission

• ❏ D. Priya is missing the “Assign issues” project permission

• ❏ E. Marcus is missing the “Assignable user” project permission

• ❏ F. Priya is missing the “Edit issues” project permission

All exam questions come from my ACP-620 Udemy Course and the certificationexams.pro website.

Maya oversees a project at OrionSoft that uses Epic, Story, Task, Bug and Sub-task issue types and she needs every sub-task to show up as an individual card on the Kanban board underneath its parent whether the parent is a Story, a Task or a Bug. Which board configuration will allow Maya to achieve this?

• ❏ A. Show sub-tasks only in the issue detail view

• ❏ B. Add sub-tasks to the card layout

• ❏ C. Base swimlanes on Queries

• ❏ D. Base swimlanes on Epics

• ❏ E. Base swimlanes on Stories

Dom is the project lead for a Jira project named LEARNIFY that has been shipped to production and handed off to an external vendor for upkeep. Which action lets Dom keep LEARNIFY issues out of advanced search results while still allowing access by direct links?

• ❏ A. Move the LEARNIFY project to Trash

• ❏ B. Archive the LEARNIFY project

• ❏ C. Hide the LEARNIFY project from users

• ❏ D. Permanently delete the LEARNIFY project

Priya accidentally removed a column from the project board in her team space and she has full board administration rights. What happens to the issues and the statuses that were mapped to the removed column?

• ❏ A. The number of issues in reports changes because deleting the column alters the counts

• ❏ B. You cannot remove a column while it still has at least one status mapped to it

• ❏ C. Issues move to the Unmapped statuses column and the column status becomes hidden from the board

• ❏ D. Statuses associated with that column are deleted from the workflow

• ❏ E. Some issues are permanently deleted from the project

At Meridian DevOps you have full permissions to perform a single bulk change across multiple issues. What can you do with one bulk change operation?

• ❏ A. Add my supervisor Alicia as a watcher on all my assigned open issues

• ❏ B. Stop watching the selected resolved issues

• ❏ C. Bulk edit the Description field of urgent issues

• ❏ D. Change the Resolution field on all withdrawn tickets

Leah is the release lead and project administrator for the project “MOBILE_APP”. After the sprint retrospective the team concluded that the imminent release will not meet its date because of substantial rework. Leah needs to locate every issue that is associated with that upcoming version. What JQL query will return those issues?

• ❏ A. project = “MOBILE_APP” and fixVersion = releasedVersions(“MOBILE_APP”)

• ❏ B. affectedVersion = latestReleasedVersion(“MOBILE_APP”) AND fixVersion = latestReleasedVersion(“MOBILE_APP”)

• ❏ C. affectedVersion = earliestUnreleasedVersion(“MOBILE_APP”) OR fixVersion = earliestUnreleasedVersion(“MOBILE_APP”)

• ❏ D. project = “MOBILE_APP” and fixVersion = nextUnreleasedVersion()

Aurora Systems uses a company managed Kanban board and the team agreed that every newly created ticket must include a due date. What permissions must a person have to add or change the Due date field on issues in that project? (Choose 2)

• ❏ A. Make bulk changes global permission

• ❏ B. Resolve issues project permission

• ❏ C. Set due dates global permission

• ❏ D. Edit issues project permission

• ❏ E. Schedule issues project permission

Marco is coordinating application development for three squads and each squad runs its own sprint. Which Jira project type lets Marco run sprints concurrently across those squads?

• ❏ A. Team-managed project

• ❏ B. Both team-managed and company-managed project types

• ❏ C. Company-managed project

In a team-managed project which of the following role titles are not provided as built-in roles by default? (Choose 4)

• ❏ A. Team member

• ❏ B. Viewer

• ❏ C. Administrators

• ❏ D. Administrator

• ❏ E. Developer

• ❏ F. Member

• ❏ G. Project Lead

Olivia is trying to log hours for ticket NOVA-142 in the NOVA company managed project but she cannot add a work log despite having the “Work on issues” project permission. What could prevent her from recording time on NOVA-142?

• ❏ A. The user lacks the “Edit own Worklogs” project permission

• ❏ B. Time tracking has been turned off at the workflow status level

• ❏ C. The user lacks the “Edit all Worklogs” project permission

• ❏ D. The user lacks the “Edit issues” project permission

Last week Maya updated the issue layout for every issue type in the “NOVA” company managed project. After a recent configuration update she can no longer modify the issue layouts in the “NOVA” project. What is the most likely cause?

• ❏ A. Board administrator permission

• ❏ B. Issue layout admin permission

• ❏ C. Project administrator permission

• ❏ D. Global permission

A release manager at Nebula Labs needs a JQL expression to return every issue in the team managed project “ORBIT” that has its affected version set to the most recently released version for that project and that is not in the “Done” status. What JQL will return those issues?

• ❏ A. status is not “Done” and affectedVersion = latestReleasedVersion() and project = “ORBIT”

• ❏ B. status != “Done” and affectedVersion = latestReleasedVersion(ORBIT)

• ❏ C. status != “Done” and affectedVersion IN releasedVersion(ORBIT) and project = “ORBIT”

• ❏ D. status is not in (“Done”) and affectedVersion = latestReleasedVersion() and project = “ORBIT”

You have just created a new company managed project named Nova from a Kanban template and you assigned Ryan the Administrators project role. Ryan must remain the only project administrator for Nova to preserve configuration consistency. Ryan has collected these requirements from his team. Requirement 1 Create components UI Backend Compliance. Requirement 2 Create a new Kanban board inside the project that displays only Story issue types. Requirement 3 Show the due date on every screen and on the issue layouts used by the project. Requirement 4 Configure the issue layout to hide fields when they are empty. Requirement 5 Grant the Delete issues project permission to the project lead of Nova. All other Jira settings are still at their default values and have never been changed. Which of these configuration tasks can Ryan not perform? (Choose 2)

• ❏ A. Requirement 4 Configure the issue layout to hide fields when they are empty

• ❏ B. Requirement 3 Show the due date on every screen and on the issue layouts used by the project

• ❏ C. Requirement 1 Create components UI Backend Compliance

• ❏ D. Requirement 5 Grant the Delete issues project permission to the project lead of Nova

• ❏ E. Requirement 2 Create a new Kanban board inside the project that only displays Story issue types

You manage a company controlled Scrum board at Aurora Systems and you attempted to add another board administrator but no suggestions for users appeared in the picker. What is preventing the suggested user list from showing up?

• ❏ A. You lack a project role on the project associated with the board

• ❏ B. Refreshing the browser will resolve the issue

• ❏ C. You do not have the Browse users and groups global permission

• ❏ D. The board currently has no administrators assigned

• ❏ E. You are not a site administrator

You must build an automation rule in a company maintained project so that when a sub task’s “Due Date” is changed the parent issue’s “Due Date” becomes the maximum due date among all its sub tasks so what rule configuration will achieve this?

• ❏ A. Configure a When value changes for “Due Date” trigger then require that a parent exists and run a branch over sub tasks and if any sub task has a later due date than the trigger issue edit the issue field “Due Date”

• ❏ B. Use an Issue updated trigger then verify that a parent exists and branch to the parent and if the parent “Due Date” is after the trigger issue edit the parent “Due Date”

• ❏ C. Set the trigger to When value changes for “Due Date” then check that the issue has a parent and branch to the parent and if the parent “Due Date” is before the trigger issue due date then edit the parent “Due Date”

• ❏ D. Trigger on When value changes for “Due Date” then confirm a parent exists and if the trigger issue due date is after the parent “Due Date” then edit the trigger issue “Due Date”

A product team at HarborTech needs to attach an image to a ticket in their issue tracker and they are reviewing available methods to add images to an issue. Which action cannot be performed?

• ❏ A. Click the “Attach” button on the issue to upload the image

• ❏ B. Paste a screenshot taken with your system keyboard shortcut directly into the issue view

• ❏ C. Insert a Google Cloud Storage link to the image in the issue description

• ❏ D. Send the image to the issue using Jira SkyDrop

Which statements about board sub-filters in Jira correctly describe where sub-filters are supported and which board views they change? (Choose 2)

• ❏ A. Sub-filters are available on both company-managed and team-managed boards

• ❏ B. A board sub-filter query changes the issues shown on a Kanban board and its backlog

• ❏ C. Only Jira administrators can create sub-filters for any board

• ❏ D. Sub-filters exist only on company-managed boards

• ❏ E. A sub-filter will alter the Kanban board, the backlog, and the board reports

Which capabilities are unique to organization-managed projects when compared with team-managed projects? (Choose 2)

• ❏ A. Email alerts can be dispatched to specific project roles

• ❏ B. Custom swimlanes can be defined using JQL filters

• ❏ C. Kanban boards can have an enabled backlog

• ❏ D. Boards can be configured with sub-filters

• ❏ E. Issues can be restricted so only certain project roles can view them

All exam questions come from my ACP-620 Udemy Course and the certificationexams.pro website.

A current company-managed project at Meridian Software will be handed over to a new support group and Sofia needs to update the project settings before the transfer. Sofia has the Administer Projects permission for that project. Which project details can Sofia modify from the Details page? (Choose 3)

• ❏ A. Module Lead

• ❏ B. Project Icon

• ❏ C. Project Key

• ❏ D. Project Owner

• ❏ E. Project Template

• ❏ F. Default assignee

Taylor needs a retrospective report for her development team at Meridian Labs. The report must show the issues contained in each sprint and it must group issues in each sprint into “Completed Issues” “Issues Not Completed” and “Issues Removed From Sprint” and issues that were added after the sprint began must be clearly marked and the report must allow linking a Confluence retrospective page to it?

• ❏ A. Epic report

• ❏ B. Velocity Chart

• ❏ C. Burndown chart

• ❏ D. Sprint report

A release manager provides these constraints for a single Jira project used by three feature squads. Every issue must state which squad is responsible or affected. Each squad needs a straightforward way to focus only on their own issues. Each squad must be able to monitor progress with a Velocity Chart that contains only their issues. Which configuration satisfies all of these constraints?

• ❏ A. One Board with three Quick Filters

• ❏ B. One Board with three Swimlanes for squad separation

• ❏ C. Components with three Boards each filtered by a Component

• ❏ D. One Board with three Epics representing each squad

Marcus’ team began their sprint yesterday and they added several new issues using the standard Defect issue type. After adding standard issues into an active sprint what will the burndown chart display? (Choose 2)

• ❏ A. The burndown chart will only register scope changes for subtasks and will ignore additions of standard issues

• ❏ B. The burndown chart will record the newly added items as scope changes when Remaining Estimate and Time Spent is enabled

• ❏ C. The burndown chart will not mark the newly added standard defects as scope changes when Remaining Estimate and Time Spent is disabled

• ❏ D. The burndown chart will record the newly added items as scope changes when Remaining Estimate and Time Spent is disabled

Maya is the board administrator for the company managed board named “NovaPlay Sprint Board” that uses the saved filter project = NOVA order by RANK asc. She met with her team on Friday afternoon and presented all work planned for the coming week using the NovaPlay Sprint Board. After the weekend some team members checked the board and the Issue Navigator and they could work on most issues but several items that appeared on Friday could not be found in either view. No configuration changes were made during the break. Which Jira setting is most likely responsible for those missing issues?

• ❏ A. Saved filter sharing permissions

• ❏ B. Board swimlanes

• ❏ C. Board working days setting

• ❏ D. Issue level security

A project lead asked you to change an automation so that it can be invoked by actions from other automations and so they receive an alert each time that automation fails. Which configuration area of the rule should you update?

• ❏ A. Actions

• ❏ B. Rule settings

• ❏ C. Triggers

• ❏ D. Conditions

Which fields can be edited from the Details screen of a team-managed project in Jira Cloud? (Choose 3)

• ❏ A. Project default assignee

• ❏ B. Project web address

• ❏ C. Project template type

• ❏ D. Project lead

• ❏ E. Project description

• ❏ F. Project avatar

Maya is preparing a team managed project at Northwood Financial that will contain confidential client records which must not be broadly visible. Which project visibility setting should she choose to keep the data restricted to only specific people?

• ❏ A. Limited

• ❏ B. Cloud Identity

• ❏ C. Public

• ❏ D. Open

• ❏ E. Private

• ❏ F. Restricted

Lina needs her Kanban board to automatically show only issues assigned the Marketing component and she requires that this filtering affect only the board so that the Pie Chart report is not altered. Which board feature should she use?

• ❏ A. Quick Filters

• ❏ B. Swimlanes

• ❏ C. Board Sub-Filter

• ❏ D. Card Colors

• ❏ E. Issue Detail View

• ❏ F. Board Filter

Marcus needs a quick way to view how many issues each team member has assigned and he also needs to see the percentage of total work allocated to each assignee and he requires a visual chart that shows the distribution of tasks among assignees and he wants the display to include unassigned issues. Which combination of dashboard gadgets should he add?

• ❏ A. Two Dimensional Filter Statistics and Created vs Resolved Chart

• ❏ B. Pie Chart and Two Dimensional Filter Statistics

• ❏ C. Issue Statistics gadget and Pie Chart gadget

• ❏ D. Filter Results and Issue Statistics

• ❏ E. Average Age Chart and Pie Chart

Maya recently set up her first team managed project using a Kanban template in Jira Cloud and she needs to add a custom role for her team. In which project settings section can she define and manage custom roles?

• ❏ A. Board

• ❏ B. Issue types

• ❏ C. Access

• ❏ D. Details

• ❏ E. Features

A product delivery group at Nebula Solutions uses a Scrum board and they want to add more custom fields to each issue card layout. What is the maximum number of extra custom fields that can be displayed on a card layout?

• ❏ A. 6

• ❏ B. 4

• ❏ C. 3

• ❏ D. 8

Mara and her team at Skylark Software have just launched their new product BeaconApp and they no longer require the associated Jira project which contains sensitive information and must not be accessible to anyone. What steps should Mara perform to ensure the project and its data are fully removed? (Choose 2)

• ❏ A. Archive the project

• ❏ B. Move the project to the trash

• ❏ C. Remove the ‘Browse Projects’ permission

• ❏ D. Permanently delete the project from the trash

• ❏ E. Apply an issue security level

Priya at AtlasWorks needs bar chart summaries of previous sprint results to decide how many story points to plan for the next sprint. Which report should she use?

• ❏ A. Sprint burndown chart

• ❏ B. Sprint velocity chart

• ❏ C. Cloud Monitoring

• ❏ D. Cumulative flow diagram

• ❏ E. Epic burndown report

A product team at Aurora Labs is reorganizing work and wants to understand board behavior after creating boards from different project templates. Which statements about board behavior and permissions are accurate? (Choose 4)

• ❏ A. It is possible to add a Kanban board to a Scrum based project

• ❏ B. Sharing or copying a board always requires the Share dashboards and filters global permission

• ❏ C. Creating a Kanban board from a Scrum project will often leave many issues in the To Do column

• ❏ D. You cannot create a Scrum board inside a project that was configured as Kanban

• ❏ E. Versions can bundle issues for a release in Scrum and they can also be used on Kanban boards

• ❏ F. Once a board is created its type cannot be converted from Scrum to Kanban or the reverse

A product squad at AuroraSoft is deciding which behaviors are only available in team-managed projects in Jira Cloud. Which capabilities are exclusive to team-managed projects? (Choose 2)

• ❏ A. Apply issue-level restrictions so only selected project roles can view issues

• ❏ B. Create multiple issues at once

• ❏ C. Use a shared workflow scheme across several projects

• ❏ D. A project administrator can define custom issue types for the project

• ❏ E. Adjust the set of issue types available in the project

The correct answer is Issue Resolution Time Report.

The Issue Resolution Time Report is designed to show how long issues remain open before they are resolved and it typically presents that information as a bar chart with time buckets so it matches Maya’s need for a vertical bar chart of ticket open durations.

Average Open Age Report shows average age metrics for open issues and it does not provide a distribution histogram of how long tickets stay open before closure.

Pie Chart Report displays proportions of issues by category or field and it will not show time durations as a vertical bar chart.

Single Field Grouping Report groups issues by a single field to show counts per value and it is not intended to display time to resolution distributions.

Time Tracking Report focuses on estimates and logged work time for tasks and it does not measure how long tickets remain open until they are closed.

Issue Date Timeline Report presents issues along a date based timeline and it does not produce a bar chart of resolution times grouped into duration buckets.

When a question asks how long tickets stay open look for keywords like resolution or time to resolution as those reports show duration distributions rather than simple counts or proportions.

The correct answers are Project permissions, Application access, Group membership, and Project role membership.

Project permissions determine whether a user can browse or view issues in a given project. The JQL project = “ORION” will match all issues in that project but Jira will only display the issues each user has permission to see so differing project permissions produce different totals.

Application access controls which Jira products a user can use and it can affect visibility of issues tied to product specific features. If some users lack access to the application that hosts certain issues then they will get fewer results even when the filter is shared broadly.

Group membership is commonly used in permission schemes and in role assignments. If permissions are granted to particular groups then users who are not in those groups will not see the same set of issues as users who are in the groups.

Project role membership affects the permissions a user has inside a project. Users assigned to different roles may have different Browse Projects or other rights and that will change how many issues they can view when running the same filter.

Global permissions apply across the Jira instance and they do not normally restrict visibility of issues in a single project so they are unlikely to cause differing issue totals for a shared project filter.

Filter subscriptions only control who receives scheduled emails about a filter and they do not change what issues appear when a user runs the filter.

Issue type scheme configuration determines which issue types are available in a project and how they behave and it does not control per user visibility of issues so it would not explain the discrepancy.

When a shared filter returns different totals for users first check project permissions. Then verify group and role membership and confirm application access to narrow down the cause.

An epic can span issues across several Jira projects, Users can change an epic’s colour in both Kanban and Scrum projects, and Users must turn on the Kanban backlog to manage epics on a Kanban board are correct.

Epics are a normal issue type and they can be used to group work across projects when your board filters and project permissions include those projects. This makes it possible to track a single large initiative that spans multiple teams and projects.

The ability to choose and change an epic’s colour is provided on the epic panel and in the backlog or board views for both Scrum and Kanban boards. Changing the colour helps visually group issues that belong to the same epic on backlog and board views.

Kanban boards do not enable a backlog by default and the Kanban backlog is a configurable feature. You must enable the Kanban backlog to get the backlog view and the epic panel that helps you manage epics on a Kanban board.

An epic cannot be converted into a subtask is incorrect because Jira provides issue type conversion and move options that let you change an epic to other issue types when appropriate, and with the right steps you can convert or move issues into sub-tasks depending on your configuration.

An epic may contain another epic through an epic link is incorrect because the epic link is intended to associate standard issues like stories and tasks to an epic, and it does not create nested epics. Creating hierarchical relationships between epics is not supported by the basic epic link, though portfolio tools add different hierarchy fields.

An epic is unable to have its own issue screen is incorrect because epics are issue types and they can have their own screens and field configurations through the normal screen scheme and field configuration settings.

When answering Jira questions, imagine the actual board and backlog views and check whether a feature is enabled by default. Focus on how epics behave as a standard issue type and remember that board settings like the Kanban backlog can change how epics are managed. Enablement and issue type configuration are often the key.

Team-managed project using the Kanban template is the correct option.

This template provides a ready made Kanban board where team members can reorder and prioritize issues by dragging and dropping them on the board every day. The Kanban approach does not require fixed sprint lengths so you can run work in iterations that vary in duration from one cycle to the next. Team managed projects also give project administrators direct control of the board configuration so they can manually clear the rightmost column when required without enabling extra global features.

Company-managed project with shared Kanban configuration is incorrect because company managed projects use shared schemes and configurations that often require higher level administration and additional setup before project admins can make the board changes you described.

Team-managed project with Bug tracking template is incorrect because the Bug tracking template is focused on issue capture and basic workflows and does not provide the Kanban board and immediate board reordering features out of the box.

Company-managed project with Kanban template is incorrect because company managed Kanban projects rely on scheme based settings and may restrict board administration and require extra configuration for clear board behaviors that project admins are expected to do immediately.

Company-managed project with Scrum template is incorrect because Scrum enforces sprint based work and is designed for consistent sprint cycles rather than the variable length iterations you described and it does not match the simple, immediate Kanban board controls you need.

Team-managed templates are optimal when one team needs simple, immediate board control and easy admin changes without global configuration.

The correct options are Impacted versions field, Resolved versions field, Versions sidebar and Releases section.

The Impacted versions field is a version picker on the issue screen that lets you choose affected versions and it typically offers inline creation of a new project version when you have the necessary issue edit permission.

The Resolved versions field is the fix version picker that also allows you to select or create a version from the issue view when you have the Edit Issues permission, so you can create a new project version from that field.

The Versions sidebar in a project provides direct access to the project version list and an Add or Create version control, so you can create a project version there as part of normal project navigation.

The Releases section is the project releases or versions management area that includes controls to create and manage versions and releases for the project.

Release Selector custom field is incorrect because a custom field by that name is not a standard Jira mechanism for creating project versions and its behavior depends on custom configuration. A custom selector will not necessarily offer the built in version creation workflow that the built in version picker fields and the project Releases area provide.

When a question mentions creating versions check which UI elements are standard Jira version pickers or project release pages and verify the user has the Edit Issues permission before selecting answers.

“Administer projects” project permission is the correct option.

The “Administer projects” project permission grants the ability to manage project settings and to create and edit versions and components so a user can publish a release for the ORBIT project.

Close issues project permission only allows closing or transitioning issues according to the workflow and it does not provide rights to create or manage project versions.

“Administer Jira” global permission is a site wide administrative right and it is broader than needed. It is not required to create a project version and it is typically reserved for Jira system administrators.

Board administrator permission controls the Kanban board configuration and filters and it does not let users change project settings or add versions which are managed in the project administration.

Focus on the scope of the action and the permission. If the task changes project settings or release versions choose a project level permission that manages versions.

The correct answer is One condition one validator two post functions and one status property.

One condition is needed to restrict the transition button so that only members of the group ‘infosec’ can see the ‘Under Review’ transition button. A single validator is required to ensure that all required fields are not empty when the transition runs. Two post functions are required because one must populate the resolution field and the other must send an email after the transition completes. A single status property is appropriate to limit who can add attachments while the issue is in that status by adjusting the attach permission at the workflow level.

One condition two validators one post function and one status property is incorrect because it includes two validators and only one post function. The scenario needs one validator and two post functions so this option does not meet the requirements.

One condition one validator two post functions and two status properties is incorrect because it adds an extra status property that is not required. A single status property can control the attachment permission so the second property is unnecessary for the stated needs.

Two conditions one validator one post function and one status property is incorrect because it uses two conditions and only one post function. The requirements call for one condition and two post functions so this option does not provide the needed post function to send the email or to populate the resolution field.

When you map transition requirements to workflow elements remember to match behaviors to components such as condition for who sees a transition validator for required input post function for actions after the transition and property for permission changes.

The correct answer is Cumulative flow diagram.

The Cumulative flow diagram shows the amount of work in each workflow state as stacked bands over time and it makes it easy to see how work accumulates and flows between states. The width of each band indicates work in progress for that state and the trend of the bands lets you calculate throughput and estimate cycle time. The diagram also provides both numeric counts and a qualitative visual that highlights historical and current bottlenecks when bands widen or constrict.

The Cumulative flow diagram therefore meets all parts of the requirement because it shows per state WIP, supports throughput and cycle time analysis, and reveals where and when bottlenecks occurred.

Velocity chart is focused on how much work the team completes per sprint and it is useful for capacity forecasting. It does not show work split by workflow state across time so it will not reveal state level bottlenecks in the same way.

Version burndown tracks remaining work for a version or release over time and it helps monitor scope and progress. It does not present work by workflow state or provide the stacked time based view needed to spot where work is queuing.

Control chart displays cycle time distribution and trends for individual issues and it can help with calculating average cycle time and detecting variability. It does not however show how much work is in each workflow state as a stacked timeline so it will not by itself reveal state level bottlenecks visually.

Sprint health report gives a quick summary of sprint progress and high level health indicators and it is useful for status checks. It does not provide the detailed, time based breakdown of WIP by workflow state that is required to analyze historical and current bottlenecks.

When the question mentions visualizing work in each workflow state over time and spotting bottlenecks think of the Cumulative flow diagram because it shows stacked state bands and trends that reveal WIP and constrictions.

The correct answers are Liam lacks Jira Software product access and Ranking is disabled in the board saved filter.

Liam lacks Jira Software product access is correct because Jira Software product access is required to use Scrum boards and backlog features that support drag and drop ranking. A user can have project permissions to create and edit issues but still be unable to use the board backlog or reorder stories if they do not have Jira Software product access.

Ranking is disabled in the board saved filter is correct because a board uses its saved filter to determine whether ranking is available. If the saved filter includes an ORDER BY clause or otherwise disables ranking in the board configuration then drag and drop reordering in the backlog will be prevented.

Liam is missing the Schedule Issues project permission is incorrect because the Schedule Issues permission controls the ability to edit scheduling fields such as due date and start date and it does not affect the ability to rank or reorder backlog items.

Liam needs Jira Administrators product access is incorrect because Jira Administrator product access is not required to reorder issues on a Scrum board and typical backlog actions only require Jira Software access and the appropriate project permissions.

Liam does not have Manage Sprints project permission is incorrect because the Manage Sprints permission is needed to create start and complete sprints and to work with active sprint settings and it does not by itself prevent dragging and ranking issues in the backlog.

When you cannot move issues in a backlog first check the user has Jira Software product access and then check the board saved filter for an ORDER BY clause or settings that disable ranking.

All exam questions come from my ACP-620 Udemy Course and the certificationexams.pro website.

The correct option is Project administrators can add users to roles that are specific to their project.

A user with the Administer Project permission for a single project can manage role membership within that project and assign users to the project specific roles that exist for that project. They do not have broader system administrator powers and their authority is limited to project scoped role assignments.

The statement Project administrators can create new system permissions and assign them to project roles is incorrect. Creating or changing system wide permissions is a system administrator task and is not available to someone who only administers a single project.

The statement Project administrators can map project roles to system permissions is incorrect. Mapping roles to system level permissions is controlled at the system level and requires system administrator rights.

The statement Project administrators can define new project roles and grant them project permissions is incorrect. Defining new roles or altering role definitions is typically a higher level configuration activity and is not allowed for a user limited to Administer Project on one project.

The statement Project administrators can add users directly to system permission groups is incorrect. System permission groups are managed by system administrators and adding users to those groups requires system level privileges.

When you read permission questions focus on whether the action is project level or system level. Project administrators usually manage membership inside their project but cannot change system permissions or groups.

The correct answer is It is not currently supported to rank subtask issue types in the backlog.

Subtasks are treated as child items under their parent issue and they cannot be independently ranked in the backlog, so reordering them is not supported even when a user has full project permissions and board administrator rights.

Hannah is missing a project permission is incorrect because the scenario states Hannah has full permissions in the project to view create delete and edit issues and to manage sprints, so a missing project permission would not explain the inability to reorder subtasks.

Hannah is missing a global permission is incorrect because global permissions control broader system capabilities and would not specifically prevent backlog ranking of subtasks when project level permissions are already granted.

Hannah requires site administrator privileges is incorrect because site admin rights are not required to change backlog ordering and granting those rights would not enable independent ranking of subtasks when that capability is not supported.

When an exam question describes an action that does not work for a specific issue type check whether the feature is supported for that issue type and review product documentation. Pay attention to subtasks because they often have different behavior from standard issues.

The system stops the move because the user lacks the Schedule Issue permission is correct.

Jira controls the ability to add or schedule issues into a sprint with the project permission called Schedule Issues. If a user does not have that permission the platform prevents the operation and the issue is not moved into the sprint.

Jira reorders the issue using the board ranking configuration is incorrect because Jira will not perform ranking changes when the underlying add to sprint action is blocked by missing permissions. Board ranking only applies when a user can actually change issue positions.

Jira places the issue by its summary in alphabetical order is incorrect because Jira does not automatically alphabetize issues by summary when adding them to a sprint. Sorting is driven by board settings and user actions not by automatic alphabetization on insert.

The issue is positioned based on the order it was inserted into the sprint is incorrect because insertion order only matters when the move succeeds. If the move is stopped due to missing permissions there is no insertion and therefore no recorded order.

When a question mentions a specific permission check whether that permission directly relates to the action described. If you see Schedule Issue then assume adding to a sprint will be blocked without it.

Mark version 3.4 as released is the correct action that moves unresolved issues into a new version and keeps the original version selectable in the Affects Versions field.

When you choose Mark version 3.4 as released Jira presents the release dialog where you can select the newly created version 4.0 to receive any unresolved issues. Releasing the version records it as released while leaving the version entry intact so it remains available for selection in Affects Versions.

Delete version 3.4 is incorrect because deleting removes the version from the project and you would no longer have 3.4 available to select in Affects Versions even if unresolved issues are relocated during the delete process.

Archive version 3.4 is incorrect because archived versions are hidden from common selection lists and will not remain selectable in the Affects Versions field.

Merge version 3.4 into another version is incorrect because merging consolidates and removes the source version, so 3.4 would no longer exist as a selectable option after the merge.

Focus on the user interface flows described in the question and think about what preserves a version record while allowing issue reassignment. In Jira the release workflow lets you move unresolved issues and keeps the version visible in Affects Versions.

The correct answer is Sprint Health Gadget.

The Sprint Health Gadget is designed to summarize key sprint indicators for the current sprint and it directly shows the number of days remaining until the sprint closes, the percentage of scope change, and the count of flagged issues. This gadget aggregates these sprint health metrics so the team can quickly see progress and risks on a single dashboard gadget.

Sprint Burndown Gadget is incorrect because it focuses on remaining work over time and the burndown trend rather than reporting the percentage of scope change or the number of flagged issues.

Two Dimensional Filter Statistics is incorrect because it provides a matrix of issue counts by two selected fields and it does not present sprint level metrics like days remaining or scope change percentage.

Velocity Chart Gadget is incorrect because it shows historical completed work per sprint to help estimate future capacity and it does not display days remaining, scope change percentage, or flagged issue counts for the current sprint.

When a question asks for multiple sprint indicators like days remaining, scope change, and flagged issues choose the gadget that explicitly summarizes sprint health rather than one that only charts progress or shows filter counts.

The correct answers are Some issues have ‘Issue Level Security’ enabled and The user lacks the Browse Projects permission for some projects.

Some issues have ‘Issue Level Security’ enabled means that those issues are restricted to specific security levels and only users who are added to those levels can see them. A board will not show issues that the viewing user is not permitted to see even when the board filter would otherwise include them.

The user lacks the Browse Projects permission for some projects means that the user cannot view any issues from projects where they do not have that permission. A cross project Kanban board will only display issues from projects the user can browse, so missing project permissions explain absent issues.

A Quick Filter is active and is hiding a subset of the issues can hide issues when a quick filter is selected, but this would be visible in the board controls and is not the same as permission or security restrictions.

The board’s saved filter uses JQL that excludes the missing issues is possible when the board query deliberately excludes certain issues, but if the board is configured to include the relevant projects then JQL exclusion is less likely than permission or issue security problems.

When you see missing issues check Issue Level Security and the user’s Browse Projects permissions first before changing board filters or quick filters.

Fix versions is the correct choice.

When a subtask is created under an existing parent issue, Jira generates the subtask in the same project and carries over several contextual fields from the parent. Fix versions are not copied to the subtask by default because version assignments represent planned releases at the parent issue level and are typically managed separately for subtasks.

Sprint assignment is incorrect because the sprint field is inherited by the subtask when it is created on the same board or sprint, so the subtask will have the same sprint as the parent.

Issue security level is incorrect because the subtask inherits the parent issue’s security level at creation according to the project security scheme unless it is changed afterwards.

Project is incorrect because a subtask must exist in the same project as its parent and it therefore inherits the project automatically when created.

Focus on whether a field is inherited by a subtask or set separately per issue when you answer. In standard Jira setups the fix versions field is commonly not inherited by subtasks.

The best approach is Ask the Jira administrator to export the automation rules as a JSON file from the staging site and import that JSON into the live site.

This method exports the complete rule definitions so that conditions, actions, branches, and smart values are preserved. The JSON export and import process is faster and more reliable than rebuilding rules by hand because it avoids human error and keeps the logic identical across environments. You should still ensure you have administrator permissions and verify referenced project keys and custom fields after import.

Recreate all automation rules manually in the live instance is incorrect because manual rebuilding is slow and error prone. Manual recreation increases the chance of configuration drift and missed conditions or actions.

Attempt to export and import rules at the project level from staging to production is incorrect because many Jira setups do not offer a reliable project level bulk export for automation rules. Export and import is typically performed using the rule JSON or global exports so a project level attempt may be incomplete or fail.

Open a support ticket with Atlassian and request that they migrate the automation rules between sites is incorrect because this approach is slower and usually unnecessary. Atlassian support does not typically perform routine configuration moves and relying on them adds avoidable delay compared with using the JSON export and import.

When a question asks about moving configurations choose the option that preserves the full definition and avoids manual retyping. Use JSON export and import when available and confirm administrator permissions before migrating to production.

The correct option is Hide completed issues.

Using Hide completed issues in the board settings lets you hide items in the Done column that were completed more than a specified number of days ago. You can set that period to seven days to display only issues closed during the current week and keep recent closures visible without permanently changing the board scope.

Quick filters are ad hoc toggles that apply JQL to the visible issues and they would require crafting a date based JQL to show this week only. They are not the simplest or most direct way to collapse older Done items.

Board filter defines which issues belong to the board and changing it would permanently alter the board membership rather than just hiding older completed issues for viewing purposes.

Swimlanes only change how issues are grouped on the board and they do not limit which Done issues are shown by completion date.

Board sub-filter can further restrict the board query but it is not the intended or easiest way to temporarily show only this week’s completions. The dedicated hide completed setting is designed for this use case.

Automation rule could update or move issues but it cannot adjust the board display in the same simple way and using automation would be unnecessary overhead for a view change.

When a question asks about showing only recent closures look for board display settings such as Hide completed issues before choosing filters or automation.

The correct option is Global Create team-managed projects permission. This permission is set at the site level and controls which users can create team-managed projects, so removing or restricting it will stop users from creating new team-managed projects while leaving their existing board and issue access intact.

Creating a team-managed project is a global action and not governed by project specific or board specific roles. If Global Create team-managed projects permission was changed during the recent configuration update then that explains why team members can still view and modify issues but cannot create projects.

Application access setting is unlikely because that setting governs whether users can access the Jira product at all. If it had been removed those users would normally lose the ability to view or edit issues as well.

Project level permission is not correct because project permissions apply to actions inside an existing project. They do not grant the ability to create new team-managed projects which requires a global permission.

Board administrator role is incorrect because board administrators manage board configuration and filters. That role does not allow creation of team-managed projects unless the global create permission is also granted.

When users suddenly lose the ability to create team-managed projects check the Global Create team-managed projects permission in site settings first before digging into project or board permissions.

project = BEACON AND issuetype = Story AND fixVersion in releasedVersions() is correct and will return the stories delivered in the released version 2.0 when run today.

The function releasedVersions() returns all versions for the project that are marked as released and using it with fixVersion in releasedVersions() ensures issues assigned to released versions such as 2.0 are returned. Since 2.0 was released last Friday it will be included in that set and the query will find the delivered stories.

project = BEACON AND issuetype = Story AND fixVersion in 2.0 is incorrect because the JQL syntax is invalid. The in operator expects a list and literal version names need quoting and parentheses. A correct explicit form would be fixVersion = “2.0” or fixVersion in (“2.0”).

project = BEACON AND issuetype = Story AND fixVersion IS NOT EMPTY is incorrect because it returns any issue that has any fixVersion set. That will include stories assigned to other released or unreleased versions and it will not restrict results to version 2.0.

project = BEACON AND issuetype = Story AND fixVersion = latestReleased() is incorrect because latestReleased() returns only the single most recent released version. That may match 2.0 today but it is brittle and it will not reliably target 2.0 if additional releases are added. Using releasedVersions() is the safer choice for capturing issues in versions that have been released including 2.0.

When you need issues from versions that have already shipped prefer functions like releasedVersions() and check the JQL syntax for whether you need a list or a single value.

Company-managed Scrum project is correct.

Company-managed Scrum project is designed for predictable sprint cycles and provides the Scrum board, sprint planning tools, and the reporting that stakeholders expect such as Epic reporting and sprint reports. These projects offer centralized configuration and governance so Epic tracking and stakeholder reporting work consistently across the engineering squad.

Team-managed Scrum project is not the best choice because team managed projects are intended for a single team and they have simpler configuration and fewer cross team and advanced reports. That makes them less suitable when stakeholders require a formal Epic report and standardized sprint reporting across the squad.

Company-managed Kanban project is not appropriate because Kanban does not use fixed sprint cycles. It is focused on continuous flow and that prevents producing sprint based Epic reports that rely on regular sprint cadence.

Team-managed Kanban project is also incorrect because it combines the limitations of team managed projects with the Kanban flow model. It lacks both the centralized reporting and the sprint structure needed to deliver regular sprint cycles and an Epic report for stakeholders.

When a question mentions regular sprint cycles and stakeholder reports look for a project type with built in Scrum features and centralized reporting such as company-managed Scrum.

The correct answers are Priya is missing the “Assign issues” project permission and Marcus is missing the “Assignable user” project permission.

Priya is missing the “Assign issues” project permission is correct because a user must have the project permission that allows assigning in order to change an issue’s assignee. If Priya lacks that permission she will not be able to assign issues even though she can create comment edit and transition them.

Marcus is missing the “Assignable user” project permission is correct because a person must be allowed to be chosen as an assignee to appear in the assignee picker. The fact that Marcus can assign issues to Priya shows that Marcus has the assign ability and that Priya is assignable, so Marcus not being assignable would prevent Priya from assigning issues to him.

Priya is missing the “Assignable user” project permission is wrong because Marcus is able to assign issues to Priya. If Priya were not assignable then Marcus would not be able to set her as the assignee.

Marcus is missing the “Assign issues” project permission is wrong because the scenario states Marcus can assign issues to Priya. That ability requires the Assign issues permission so Marcus must already have it.

Priya is missing the “Work on issues” project permission is wrong because Priya can create edit and transition issues which shows she already has the permissions needed to work on issues. That permission would not explain why she cannot assign.

Priya is missing the “Edit issues” project permission is wrong because the question states she can edit issues. Losing edit permission would prevent editing but it does not explain an inability to assign when the assign permission is separate.

When you troubleshoot assignment problems check both the actor’s Assign issues permission and the target user’s Assignable user permission in the project permission scheme.

The correct answer is Base swimlanes on Stories.

Choosing Base swimlanes on Stories groups the board by parent story so that sub-tasks are displayed as individual cards within the swimlane for their parent. This configuration lets each sub-task appear underneath its parent on the Kanban board and keeps the parent and its children visually connected.

Show sub-tasks only in the issue detail view is incorrect because that option restricts sub-task visibility to the issue detail panel and does not render sub-tasks as separate cards on the board.

Add sub-tasks to the card layout is incorrect because changing the card layout only alters which fields are shown on a card and does not create separate board cards for each sub-task.

Base swimlanes on Queries is incorrect because using queries requires explicit filters and does not automatically group sub-tasks under their parent issue in the way that the Stories swimlane option does.

Base swimlanes on Epics is incorrect because epic swimlanes group work by epic rather than by the immediate parent issue so sub-tasks would not necessarily appear directly under their Story Task or Bug parent.

When a question asks about showing sub-tasks as individual cards think about how swimlanes group issues and focus on options that group by parent issue such as Stories.

The correct option is Archive the LEARNIFY project.

Archive the LEARNIFY project removes the project from active lists and from most search results while preserving the project data and links. Archiving is intended for projects that are no longer actively worked on so the vendor can still access issues by direct URL and the project can be restored later if needed.

Move the LEARNIFY project to Trash is wrong because moving to trash is not the standard way to preserve searchable state while retaining link access and it generally indicates removal rather than a reversible archival state.

Hide the LEARNIFY project from users is wrong because there is no simple global “hide” toggle that both removes items from advanced search and keeps them accessible by direct link. Changing visibility or permissions would typically block direct link access for users without permission.

Permanently delete the LEARNIFY project is wrong because deletion removes the project and its data permanently and breaks direct links. Deletion is irreversible and is not appropriate when the vendor still needs to access the project content.

When a question asks about removing content from search but keeping it reachable by link think of archiving rather than deletion or permission changes.

Issues move to the Unmapped statuses column and the column status becomes hidden from the board is correct.

Issues move to the Unmapped statuses column and the column status becomes hidden from the board is correct because removing a board column only changes the board mapping and does not delete issues or workflow statuses. The statuses that were mapped to the removed column become unmapped for that board and they appear in the board’s unmapped area, while the board no longer shows a dedicated column for those statuses.

The number of issues in reports changes because deleting the column alters the counts is incorrect because deleting a column does not change the actual issues or their workflow statuses. Reporting that aggregates by status will still count those issues since their status values remain even if they are unmapped on the board.

You cannot remove a column while it still has at least one status mapped to it is incorrect because most board implementations allow a column to be removed and will simply unmap any statuses that were assigned to it. The platform does not block column deletion to force status reassignment.

Statuses associated with that column are deleted from the workflow is incorrect because removing a column from a board does not remove statuses from the underlying workflow. The statuses remain in the workflow configuration and can be remapped to other columns or reused elsewhere.

Some issues are permanently deleted from the project is incorrect because issues are not deleted when a column is removed. The issues remain in the project and retain their status values even when those statuses become unmapped on the board.

When answering questions about board configuration think about the difference between the board view and the underlying data. Removing a board column usually changes only the board mapping and not the issues or workflow definitions.

Stop watching the selected resolved issues is the correct option.

This bulk change is valid because many issue trackers let you update watcher settings for a selected set of issues in one operation and stopping watching resolved issues is a typical bulk action you can perform when you have the appropriate permissions.

Add my supervisor Alicia as a watcher on all my assigned open issues is incorrect because adding another user as a watcher normally requires explicit permission and is often performed per issue or via a different bulk action than the one described here.

Bulk edit the Description field of urgent issues is incorrect because free form text fields like Description are not commonly overwritten across many issues in a single safe bulk operation and systems often restrict or require careful scripting for such changes.

Change the Resolution field on all withdrawn tickets is incorrect because the Resolution field is usually controlled by workflow transitions and cannot typically be set arbitrarily across many issues without performing the appropriate transitions or using a specialized workflow bulk transition feature.

When answering bulk change questions focus on what actions affect watchers and which fields are controlled by workflows or require special permissions. Pay attention to whether the change is a watcher update or a field change.

The correct answer is affectedVersion = earliestUnreleasedVersion(“MOBILE_APP”) OR fixVersion = earliestUnreleasedVersion(“MOBILE_APP”).

This query uses earliestUnreleasedVersion(“MOBILE_APP”) to identify the imminent unreleased version for the MOBILE_APP project and it checks both the affectedVersion and the fixVersion fields so it returns issues that are planned to be fixed in that version and issues that are affected by it.

project = “MOBILE_APP” and fixVersion = releasedVersions(“MOBILE_APP”) is incorrect because releasedVersions(“MOBILE_APP”) returns versions that are already released and it will not find the upcoming unreleased version that Leah needs to inspect.

affectedVersion = latestReleasedVersion(“MOBILE_APP”) AND fixVersion = latestReleasedVersion(“MOBILE_APP”) is incorrect because latestReleasedVersion(“MOBILE_APP”) points to the most recently released version rather than the next unreleased one and using AND requires both fields to match the same released version which is overly restrictive for this use case.

project = “MOBILE_APP” and fixVersion = nextUnreleasedVersion() is incorrect because it only filters the fixVersion field and will miss issues where the upcoming version is set in the affectedVersion field. The function without a project argument can also be ambiguous when you need the next unreleased version for a specific project.

When you need all issues tied to an upcoming release include both fixVersion and affectedVersion in your JQL and use a version function that targets the unreleased version for the specific project.

All exam questions come from my ACP-620 Udemy Course and the certificationexams.pro website.

The correct options are Edit issues project permission and Schedule issues project permission.

The Edit issues project permission allows a user to modify issue content and many of the issue fields so it is required to perform edits on an issue within the project.

The Schedule issues project permission specifically controls the ability to change scheduling fields such as the due date and the start date so you need it to add or update the Due date even if you can edit other parts of the issue.

The Make bulk changes global permission is for running bulk operations across multiple issues and it is a global level capability so it does not grant the normal ability to set or change the Due date on an individual issue.

The Resolve issues project permission only permits transitioning an issue to a resolved or closed state and it does not allow editing scheduling fields like the Due date.

The Set due dates global permission is not a standard Jira permission and there is no separate global permission named that for due dates. Due dates are controlled at the project level by the Schedule issues permission.

When answering permission questions remember that Edit issues and Schedule issues are separate rights and both may be required. Use the project permission helper to verify who actually has each permission.

The correct answer is Both team-managed and company-managed project types.

Both team-managed and company-managed project types are correct because sprints are a feature provided by Jira Software boards and both project types offer boards that can run Scrum sprints independently. Each squad can have its own board or its own project board and start and finish sprints on its own cadence, so concurrent sprints across squads are supported.

Team-managed project projects give each team a simple, project-scoped board and sprint controls so a squad can run sprints independently without shared configuration. Company-managed project projects also support boards and sprints and add more advanced configuration and the ability to share boards across projects, which still allows squads to run their own sprints concurrently.

Team-managed project is incorrect as a lone choice because it implies only team-managed projects can run concurrent sprints, and that ignores the fact that company-managed projects also support independent sprinting.

Company-managed project is incorrect as a lone choice for the same reason because it implies exclusivity, while team-managed projects can also host independent sprints for each squad.

Watch for words like both in answer choices and remember that sprints are tied to boards, so focus on whether the project type provides a board rather than assuming exclusive capability.

The correct options are Team member, Administrators, Developer, and Project Lead.

These titles are not provided as built-in roles by default in a team-managed project because team-managed projects normally ship with a concise set of standard roles and they allow teams to define or customize additional role names. Titles such as Developer, Team member, Project Lead, and the plural form Administrators are typically created or assigned at the project level rather than appearing out of the box.

Viewer is usually a standard built-in role that grants read only access, so it is provided by default and is not one of the roles you should select as missing.

Administrator is commonly included as a built-in role in team-managed projects, so the singular form is provided out of the box and therefore it is not correct to mark it as missing.

Member is often the default role for general project participation, so it is normally provided by default and is not a correct choice for this question.

Read role names carefully and watch for small differences in wording or plural versus singular forms because those details often determine whether a role is built in or a custom title.

Time tracking has been turned off at the workflow status level is correct because a workflow-level setting can prevent logging work on an issue and that will stop Olivia from adding a work log even though she has the Work on issues permission.

Workflows can include properties or status-level settings that disable the worklog field or the Log Work action while an issue is in a particular status. When time tracking is turned off at that level the system will not allow new worklogs regardless of the standard work permissions.

The user lacks the “Edit own Worklogs” project permission is incorrect because that permission controls editing existing worklogs created by the same user and does not explain why Olivia cannot add a new work log when time tracking is disabled by the workflow.

The user lacks the “Edit all Worklogs” project permission is incorrect because that permission governs editing other users’ worklogs and would not prevent Olivia from adding her own worklog if time tracking were enabled for the issue.

The user lacks the “Edit issues” project permission is incorrect because editing the issue itself is distinct from logging work and the ability to log time is controlled by time tracking settings and the Work on issues permission rather than the Edit issues permission.

When a user can perform an action in general but cannot do it on a specific issue check the issue’s workflow status and any workflow properties that may restrict that action.

The correct option is Project administrator permission.

The most likely cause is that Maya no longer has Project administrator permission on the NOVA company managed project after the configuration update. In company managed projects the ability to change the issue view layout is controlled at the project administration level, and losing that project role or permission will prevent her from modifying issue layouts.

Board administrator permission is incorrect because board administrators manage board settings and filters and not the issue view layout for a company managed project. Losing board administration would not remove access to issue layout settings if the user still has project administrator rights.

Issue layout admin permission is incorrect because there is no separate global permission named Issue layout admin for company managed projects. The layout controls are tied to project administration rather than a distinct named permission called Issue layout admin.

Global permission is incorrect because global permissions apply instance wide and usually refer to higher level roles like Jira administrators. A change that affects only the NOVA project after a configuration update points to a change in the project level role or project permissions rather than a global permission change.

When a capability disappears in a single project first check the user s project role and the project s permission scheme before investigating global permissions.

The correct option is status != “Done” and affectedVersion = latestReleasedVersion(ORBIT).

This query uses status != “Done” to exclude issues in the Done state and it uses affectedVersion = latestReleasedVersion(ORBIT) to match the affected version to the most recently released version for the ORBIT project. The function latestReleasedVersion accepts a project key and returns that project’s most recently released version so a separate project clause is not required.

status is not “Done” and affectedVersion = latestReleasedVersion() and project = “ORBIT” is incorrect because the operator form is not is not valid JQL syntax and the function call without a project parameter will not reliably target the ORBIT project.

status != “Done” and affectedVersion IN releasedVersion(ORBIT) and project = “ORBIT” is incorrect because releasedVersion(ORBIT) is not a standard JQL function name for returning the latest released version. The correct function for the single most recently released version is latestReleasedVersion(project).

status is not in (“Done”) and affectedVersion = latestReleasedVersion() and project = “ORBIT” is incorrect because the operator syntax is wrong. The correct negation form is status not in (“Done”) or status != “Done”. In addition the latestReleasedVersion function should include the project key when you intend to target a specific project.

When a JQL function accepts a project key it is usually cleaner to pass the key to the function rather than adding a separate project = clause. Also check operator syntax carefully and prefer != or not in for negation.

Requirement 3 Show the due date on every screen and on the issue layouts used by the project and Requirement 5 Grant the Delete issues project permission to the project lead of Nova are the tasks Ryan cannot perform from his project administrator role on a company managed project with default Jira settings.

Showing the Due Date on every screen requires editing screen schemes and the field configuration that controls which fields appear on screens. Those screen and field configuration changes are global administration actions that require Jira Administrator level permissions, so a project administrator cannot make those changes for the project.

Granting the Delete Issues permission requires changing the permission scheme or assigning a permission to a role within the scheme. Editing permission schemes is a global administration task and is not available to project administrators. Project admins can assign users to roles but they cannot modify which permissions those roles have when the scheme is managed at the global level.

Requirement 1 Create components UI Backend Compliance is something a project administrator can do because components are managed per project in project settings and do not require global admin rights.

Requirement 2 Create a new Kanban board inside the project that only displays Story issue types can be done by creating a board scoped to the project and using a filter or board configuration to show only Story issue types. Creating and configuring boards does not require Jira Administrator rights.

Requirement 4 Configure the issue layout to hide fields when they are empty can be performed by a project administrator for a company managed project because the issue layout and its field visibility options can be adjusted at the project level without global admin privileges.

When a task involves changing screens or permission schemes remember that those actions need Jira Administrator rights while project admins can manage components, boards, and the issue layout in company managed projects.

You do not have the Browse users and groups global permission is correct. The user picker that shows suggested users depends on the global permission to browse users and groups and without that permission the suggestion list will remain empty.

The Browse users and groups global permission is a site level permission that controls whether an account can search for and see other users and groups. If you do not have it then the picker cannot return matches even if you can otherwise manage the board. Granting that global permission or asking someone who can manage global permissions to grant it will enable the suggestions.

You lack a project role on the project associated with the board is incorrect because project role membership does not affect the global user search that powers the suggestion list. The picker relies on global visibility of users rather than on project role membership.

Refreshing the browser will resolve the issue is incorrect because a browser refresh will not change your account permissions. The absence of suggestions is caused by a permission setting and not by a temporary UI glitch in most cases.

The board currently has no administrators assigned is incorrect because the presence or absence of other board administrators does not prevent the user picker from suggesting users. The picker behavior is controlled by your permission to browse users and groups.

You are not a site administrator is incorrect because being a site administrator is not required just to see user suggestions. You only need the specific Browse users and groups global permission which can be granted without making someone a site administrator.

When a user picker or suggestion list is empty check the Browse users and groups global permission first because it commonly controls whether suggestions appear.

The correct option is Set the trigger to When value changes for “Due Date” then check that the issue has a parent and branch to the parent and if the parent “Due Date” is before the trigger issue due date then edit the parent “Due Date”

This option works because the rule runs only when a due date changes so it reacts to sub task updates and the condition that the issue has a parent ensures it does not run for standalone issues. Branching to the parent lets the rule evaluate and update the parent issue directly and the compare that updates the parent only when the parent due date is before the sub task due date ensures the parent becomes the maximum of its sub tasks without lowering the parent when a sub task is earlier.

Configure a When value changes for “Due Date” trigger then require that a parent exists and run a branch over sub tasks and if any sub task has a later due date than the trigger issue edit the issue field “Due Date” is incorrect because it branches over sub tasks and then edits the trigger issue. That approach would modify the sub task rather than updating the parent and it does not directly set the parent to the latest sub task date.

Use an Issue updated trigger then verify that a parent exists and branch to the parent and if the parent “Due Date” is after the trigger issue edit the parent “Due Date” is incorrect because the comparison is reversed and would try to edit the parent when the parent date is already later. The trigger is also broader than necessary which can make the rule run for unrelated updates.

Trigger on When value changes for “Due Date” then confirm a parent exists and if the trigger issue due date is after the parent “Due Date” then edit the trigger issue “Due Date” is incorrect because it edits the sub task instead of the parent. The logic should update the parent when a sub task is later so that the parent reflects the maximum due date among its children.

Use the Field value changed trigger and a Branch rule to the parent when propagating values from child issues so you compare and then edit the correct issue.

The correct action that cannot be performed is Send the image to the issue using Jira SkyDrop.

Send the image to the issue using Jira SkyDrop cannot be performed because Jira SkyDrop is not a standard or supported attachment method in current Jira documentation and product features. It does not appear as a documented way to add images and therefore is not a valid upload mechanism.

Click the “Attach” button on the issue to upload the image is incorrect because most issue trackers including Jira provide an Attach button that lets you upload image files directly from your device. This is a common and supported method for adding images to issues.

Paste a screenshot taken with your system keyboard shortcut directly into the issue view is incorrect because the issue editor in many modern browsers and Jira editors accepts pasted images from the clipboard and creates an attachment automatically. Browser or admin settings can affect this but it is a supported workflow.

Insert a Google Cloud Storage link to the image in the issue description is incorrect because you can include a link to an image hosted in Google Cloud Storage in the description. You must ensure the object is accessible by the issue readers by making it public or by using an appropriate signed URL, but linking to a GCS object is a valid approach.

When you see a feature name that is unfamiliar ask whether it is documented or supported by the vendor and think about access control for linked images by using a public or signed URL.

The correct options are Sub-filters exist only on company-managed boards and A board sub-filter query changes the issues shown on a Kanban board and its backlog.

Sub-filters exist only on company-managed boards means that sub-filters are a configuration feature of classic company-managed boards and are not available in the simplified team-managed board settings. In company-managed boards you can add a sub-filter to refine what the board and backlog display without changing the main board filter.

A board sub-filter query changes the issues shown on a Kanban board and its backlog explains that a board sub-filter is applied in addition to the board filter so it narrows the issues that appear on the Kanban board and in the backlog. The sub-filter affects what is visible on those board views rather than modifying the underlying project data.

Sub-filters are available on both company-managed and team-managed boards is incorrect because sub-filters are implemented only for company-managed boards and the team-managed project model does not include that board-level feature.

Only Jira administrators can create sub-filters for any board is incorrect because creating or editing a sub-filter is done by users with the appropriate board or project administration permissions and it is not restricted solely to Jira system administrators.

A sub-filter will alter the Kanban board, the backlog, and the board reports is incorrect because a sub-filter changes the board and backlog views but it does not automatically change the standard board reports which often rely on the board filter or stored historical data rather than the active sub-filter.

When a question contrasts company-managed and team-managed features focus on the project type first and then check which board-level settings like sub-filters are available in that model.

The correct options are Custom swimlanes can be defined using JQL filters and Boards can be configured with sub-filters.

Custom swimlanes can be defined using JQL filters is unique to organization managed projects because those projects support advanced board configuration and full JQL based controls. Team managed projects use a simplified board model that does not expose the same JQL driven swimlane configuration and that limits how you can group issues on a board.

Boards can be configured with sub-filters is also unique to organization managed projects because sub filters let administrators refine which issues appear on a board beyond the main filter. This level of filter customization relies on the classic board settings and JQL features that are available in organization managed projects but not in the simplified team managed boards.

Email alerts can be dispatched to specific project roles is incorrect because sending notifications can be achieved through automation rules or site level notification schemes and so it is not a capability that only organization managed projects offer.

Kanban boards can have an enabled backlog is incorrect because backlog behavior depends on board and project settings and is not a capability that is exclusive to organization managed projects.

Issues can be restricted so only certain project roles can view them is incorrect because visibility controls and notification methods are handled through broader permission and security mechanisms that are not strictly limited to organization managed projects in all deployments.

When the question asks which features are unique to organization managed projects focus on features that require full JQL or advanced board settings. Those are the most reliable clues on this topic. Also pay attention to wording that implies advanced configuration rather than simple or automated behaviors.

All exam questions come from my ACP-620 Udemy Course and the certificationexams.pro website.

The correct options are Project Icon, Project Owner, and Default assignee.

Because Sofia has the Administer Projects permission she can change project level details on the Details page, and that includes updating the Project Icon, assigning or changing the Project Owner, and setting the Default assignee for issues in the project. The Project Icon controls the visual identifier used across the product. The Project Owner is the contact or responsible person listed in project details and can be edited there. The Default assignee determines who receives newly assigned issues by default and is set from the Details screen.

The Module Lead is not a field you modify from the Details page in this context and is managed elsewhere in project configuration or via specific role assignments.

The Project Key is a system identifier that is established at or outside project creation and is not typically changed from the Details page by someone with only the Administer Projects permission.

The Project Template is chosen when the project is created and cannot be altered from the Details page afterwards.

When a question mentions the Administer Projects permission focus on editable project level settings such as the icon, the owner, and the default assignee rather than properties set at creation like the template or fixed identifiers like the project key.

The correct answer is Sprint report.

The Sprint report is designed to show the issues contained in a specific sprint and it groups those issues into Completed Issues, Issues Not Completed, and Issues Removed From Sprint. The report also marks issues that were added after the sprint began and it supports linking to a Confluence retrospective page so teams can connect the issue list to their retrospective content.

Epic report is centered on issues that belong to a particular epic and it does not provide the per sprint grouping of completed, not completed, and removed issues required for a sprint retrospective.

Velocity Chart displays the amount of work completed across multiple sprints as story points or issue counts and it helps forecast capacity. It does not list individual issues in a sprint nor categorize them into completed, not completed, or removed for a retrospective.

Burndown chart visualizes remaining work over the sprint timeline and it helps teams track progress during a sprint. It does not present the issue level groupings, the markers for issues added after the sprint start, or a direct link to a Confluence retrospective page.

When a question asks for an issue level report that groups sprint work and highlights changes made after the sprint start look for the phrase sprint report or wording about Completed Issues and Issues Removed From Sprint.

The correct option is Components with three Boards each filtered by a Component.

Components with three Boards each filtered by a Component is the right configuration because you can assign each issue a component that identifies the responsible or affected squad and then create one board per squad that filters on that component. Each squad board will show only its component issues and the board scoped Velocity Chart will reflect only those issues so squads get a straightforward view and separate velocity reporting.

One Board with three Quick Filters is incorrect because quick filters only change what is visible on the board when you apply them and they do not change the board scope for built in reports like the Velocity Chart. The shared board would still include all project issues in reports unless the board filter itself is narrowed.

One Board with three Swimlanes for squad separation is incorrect because swimlanes provide a visual grouping on the board and they do not act as filters for the board scope. Reports and the Velocity Chart remain based on the board filter and sprint selection.

One Board with three Epics representing each squad is incorrect because epics group related work but they are not a substitute for a board filter that limits issues by ownership. Using epics alone does not give each squad its own board scoped Velocity Chart unless you also create separate boards filtered by those epics.

When a question asks about per team reporting focus on the board filter scope and whether reports like the Velocity Chart are tied to that scope. Prefer creating separate boards filtered by a clear issue field such as components for simple per team views and reporting.

The correct answers are The burndown chart will record the newly added items as scope changes when Remaining Estimate and Time Spent is enabled and The burndown chart will record the newly added items as scope changes when Remaining Estimate and Time Spent is disabled.

Both The burndown chart will record the newly added items as scope changes when Remaining Estimate and Time Spent is enabled and The burndown chart will record the newly added items as scope changes when Remaining Estimate and Time Spent is disabled state that adding standard issues to an active sprint is recorded as a scope change on the burndown chart. The burndown chart records additions and removals of sprint issues as scope changes and the Remaining Estimate and Time Spent setting affects how time based values are shown but it does not prevent scope change entries from appearing.

The burndown chart will only register scope changes for subtasks and will ignore additions of standard issues is incorrect because the burndown chart does not limit scope change recording to subtasks. Standard issue types such as defects that are added to an active sprint are treated as scope changes.

The burndown chart will not mark the newly added standard defects as scope changes when Remaining Estimate and Time Spent is disabled is incorrect because disabling Remaining Estimate and Time Spent does not stop the chart from recording scope changes. Scope change markers reflect changes to the sprint composition independent of time tracking settings.

When answering these questions focus on whether an action changes scope rather than on time tracking. Adding or removing issues usually shows as a scope change even if time tracking is disabled.

Issue level security is the correct option.

Issue level security restricts visibility of individual issues by assigning a security level to an issue. If a user is not a member of the security level applied to an issue then that issue will not appear for them in the Issue Navigator or on the board even when the saved filter matches. This behavior explains why some items that were visible on Friday were missing for some team members after the weekend without any board configuration changes.

Issue level security is applied at the issue level and can be changed independently of board and filter settings. That means changes to who can see specific issues will make those issues disappear for certain users while leaving other issues visible.

Saved filter sharing permissions would control who can see or use the saved filter itself and would typically affect the whole filter or board. It would not selectively hide only a few issues while leaving most visible.

Board swimlanes only change how issues are grouped and displayed on the board. Swimlane settings do not remove issues from the board or from the Issue Navigator.

Board working days setting affects sprint calculations and reporting such as burndown charts. It does not change issue visibility on the board or in the Issue Navigator.

When issues are missing from both the board and the Issue Navigator check whether issue level security or a security level on individual issues is restricting visibility.

The correct option is Rule settings.

You should update Rule settings because this area controls how the automation is exposed to other automations and how execution outcomes are reported. Changing the Rule settings lets you permit other automations to invoke this automation and lets you configure notifications or alerts to be sent when the automation fails.

Actions are what the rule performs when it runs and they do not control whether other automations can invoke the rule or how failure alerts are sent.

Triggers define the events that start a rule and they are not the place to change invocation permissions for external automations or to configure failure notifications.

Conditions determine when a trigger should actually fire and they do not manage who can call the automation or the notification settings for failures.

Focus on the configuration area that controls who can invoke the automation and how failures are reported when you need to enable cross automation calls and alerts.

Project web address, Project description, and Project avatar can be edited from the Details screen of a team-managed project in Jira Cloud.

The Details screen is used to manage basic project metadata and it includes fields to update the project web address which affects the project URL, the project description which appears in the project header and issue views, and the project avatar which is used to visually identify the project.

Project default assignee is not edited from the Details screen in team-managed projects. Default assignee settings are managed in other project configuration areas rather than on the Details screen.

Project template type cannot be changed from the Details screen because the template is chosen when the project is created and changing it is not supported via the Details screen.

Project lead is not an editable field on the Details screen of a team-managed project. People and role assignments are managed in the project people settings rather than in Details.

When you see questions about what can be changed on the Details screen focus on basic project metadata such as the web address, description, and avatar and remember that structural settings are often managed elsewhere.

The correct setting is Private.

The Private visibility restricts project access so only specified users or groups can view and manage the project. This prevents confidential client records from being broadly visible and ensures access is granted only to people who need it.

Limited is not a standard project visibility label for restricting access to named users and it is ambiguous about who can see the data.

Cloud Identity is a Google identity and access product and not a project visibility setting, so it does not itself control project visibility.

Public would make the project broadly visible and could expose confidential records to anyone, so it is not appropriate for restricted data.

Open also implies broad visibility and does not limit access to specific people, so it is not suitable for confidential records.

Restricted sounds like limited access but it is not the correct label in this context and may not guarantee that only specific people can view the project.

When a question asks about restricting access to confidential data choose the option that explicitly limits access to named users such as Private rather than options that imply broad or ambiguous sharing.

The correct option is Board Sub-Filter. This option lets Lina limit the Kanban board to only issues with the Marketing component while leaving other filters and reports unchanged.

A Board Sub-Filter is an extra JQL clause that is applied on top of the board filter and it affects only that board. You can add a component condition to the sub-filter so the board will automatically display only Marketing issues and the underlying saved filter used by reports will remain the same.

Quick Filters are user selectable buttons that temporarily narrow the visible cards when clicked. They do not apply automatically for all users so they do not meet Lina’s requirement for an automatic board level filter.

Swimlanes change how issues are grouped into rows on the board and they do not exclude issues from the board. They will not prevent non Marketing issues from appearing.

Card Colors only change the visual appearance of cards and they do not filter or remove issues. This feature cannot be used to restrict which issues are shown.

Issue Detail View displays fields and details when you open a card and it is not a filtering mechanism. It cannot be used to limit the set of visible issues.

Board Filter is the main saved filter that defines the board contents for everyone. Editing the board filter would change the shared filter and could alter reports such as the Pie Chart, so it is not appropriate when you need the change to affect only the board.

When a question asks to change what a single board shows without affecting reports think about a board sub-filter because it layers JQL on the board only.

The correct answer is Issue Statistics gadget and Pie Chart gadget.

The Issue Statistics gadget and Pie Chart gadget combination is correct because the Issue Statistics gadget gives a quick numeric breakdown of how many issues are assigned to each user and it can be configured to show the Assignee field including unassigned issues. The Pie Chart gadget complements that by showing the same Assignee field as a visual slice chart so you can see the percentage of total work for each assignee at a glance.

Two Dimensional Filter Statistics and Created vs Resolved Chart is incorrect because the Created vs Resolved Chart tracks issue flow over time and not the distribution of work among assignees. The Two Dimensional gadget can show counts by two fields but it does not provide the simple numeric list and percentage visual that the question requires.

Pie Chart and Two Dimensional Filter Statistics is incorrect because although the Pie Chart provides the visual percentage distribution you also need a gadget that gives a quick list of counts per assignee. The Two Dimensional gadget does not serve as the straightforward per-assignee count list that the Issue Statistics gadget provides.

Filter Results and Issue Statistics is incorrect because the Filter Results gadget shows a list of issues but it does not produce a visual percentage chart. Combining it with Issue Statistics gives counts but still lacks the required visual distribution by percentage.

Average Age Chart and Pie Chart is incorrect because the Average Age Chart reports how long issues have been open and it does not show counts or distribution by assignee. Pairing it with a Pie Chart therefore does not deliver the quick per-user counts along with the distribution view that Marcus needs.

When a question asks for both a quick numeric breakdown and a visual percentage choose one gadget that lists counts per field and one that renders percentage slices. The Issue Statistics gadget and the Pie Chart gadget are the usual pair for this need.

The correct option is Access.

The Access section of a team managed project in Jira Cloud is where project admins can define and manage custom roles and control who has which role within the project. This area provides the UI to add roles, assign users to roles, and adjust role-level access without changing global schemes.

Board is incorrect because the board settings adjust columns, card display, and board-specific behaviors and they do not control project roles.

Issue types is incorrect because that section manages the types of issues and their screens and workflows rather than user roles and access.

Details is incorrect because it contains project metadata such as the project name, key, and description and it does not provide role management features.

Features is incorrect because it lets you enable or disable project features like releases and components and it does not handle definition or assignment of custom roles.

When a question asks where to manage people or roles in a team managed project look for the setting named Access or similar project level access controls rather than board or issue configuration sections.

The correct option is 3.

Jira Software board card layouts permit showing up to 3 extra custom fields on each issue card. This limit is configured in the board settings under the card layout and it helps keep cards concise and readable on Scrum boards.

6 is incorrect because the product does not support displaying six extra fields on a card and the UI limit is lower.

4 is incorrect because four exceeds the supported number of extra fields and the configurable maximum is 3.

8 is incorrect because eight far exceeds the allowed number and is not supported by the board card layout.

When you see a question about interface limits focus on the specific UI element mentioned and remember that card layouts are intentionally small and typically allow only three extra fields.

Move the project to the trash and Permanently delete the project from the trash are the correct options because they implement Jira Cloud’s deletion workflow and ensure the project and its data are removed.

First you must Move the project to the trash which places the project into the project trash and allows a short recovery window. After that you must Permanently delete the project from the trash to remove all issues, attachments, and metadata irreversibly. Permanent deletion is typically restricted to Jira administrators or site administrators and cannot be undone.

Archive the project is incorrect because archiving makes the project read only and preserves all issues and data for future reference instead of removing them.

Remove the ‘Browse Projects’ permission is incorrect because removing that permission only limits who can see the project but it does not delete the project or its data and administrators may still access it.

Apply an issue security level is incorrect because issue security only restricts visibility of individual issues inside the project and does not remove the project or its stored data.

When the question asks about fully removing data choose the option that follows the product deletion workflow. Archiving and permission changes are not the same as permanent deletion.

The correct answer is Sprint velocity chart.

The Sprint velocity chart presents a bar chart of completed story points for previous sprints so Priya can see how many points the team has delivered over time and use that history to plan the next sprint.

The Sprint velocity chart also lets teams compare completed work across multiple sprints and compute an average velocity which helps with forecasting how many story points to commit to in the upcoming sprint.

The Sprint burndown chart shows work remaining within a single sprint and focuses on progress toward the current sprint goal. It does not provide a bar chart of completed points across past sprints so it is not the right choice.

The Cumulative flow diagram visualizes work in different workflow states over time and highlights bottlenecks. It does not present sprint level completed story point bars so it is not what Priya needs.

The Epic burndown report tracks progress toward completing an epic rather than showing completed story points per sprint for the team. It can be useful for scope tracking but it does not provide the sprint velocity bars.

The Cloud Monitoring option is a Google Cloud service for infrastructure and application metrics. It is not a Jira report and it will not provide sprint story point history.

When a question asks about historical totals and forecasting look for a report that shows completed story points per sprint such as the velocity chart.

All exam questions come from my ACP-620 Udemy Course and the certificationexams.pro website.

The correct options are It is possible to add a Kanban board to a Scrum based project, Creating a Kanban board from a Scrum project will often leave many issues in the To Do column, Versions can bundle issues for a release in Scrum and they can also be used on Kanban boards, and Once a board is created its type cannot be converted from Scrum to Kanban or the reverse.

It is possible to add a Kanban board to a Scrum based project is true because boards are views built on filters and issue sources rather than rigid project templates. You can create a Kanban board that queries issues from a Scrum project so the same project can be viewed with a Kanban workflow if that view suits the team.

Creating a Kanban board from a Scrum project will often leave many issues in the To Do column is true because Scrum projects frequently use sprints and backlog handling that do not map one to one onto Kanban columns. When a Kanban board is created against a Scrum project the column to status mapping and any sprinted issues can cause a large number of backlog or unassigned issues to remain mapped to the To Do column until the board configuration is adjusted.

Versions can bundle issues for a release in Scrum and they can also be used on Kanban boards is true because Versions or Fix Versions are issue fields that exist independently of board type. You can group and track issues for a release using versions in Scrum via sprints and on Kanban boards by filtering or displaying the Fix Version field.

Once a board is created its type cannot be converted from Scrum to Kanban or the reverse is true because the board type is chosen at creation and Jira does not provide a direct conversion between board types. To change type you create a new board of the desired type and reuse the same filter or copy configuration as needed.

Sharing or copying a board always requires the Share dashboards and filters global permission is incorrect because sharing a board is typically about sharing the underlying filter or configuring board browse permissions and it does not always require that specific global permission. The actual requirement depends on how the board and its filter are shared or who needs access.

You cannot create a Scrum board inside a project that was configured as Kanban is incorrect because project template or initial configuration does not prevent creating a different board type for that project’s issues. Boards are separate constructs and you can create a Scrum board that uses issues from a project originally set up with a Kanban template.

When answering board questions focus on whether the statement refers to the board as a view or to project configuration. Remember that boards use filters and fields like Fix Version so they are flexible even if the project template is different.

The correct options are Create multiple issues at once and A project administrator can define custom issue types for the project.

Team-managed projects expose a simple, per-project interface that lets the team add many items quickly, which is why Create multiple issues at once is exclusive to team-managed projects. This capability is part of the self-contained project experience and does not rely on shared administration across the site.

Team-managed projects are designed so the project admin controls project-level configuration, which is why A project administrator can define custom issue types for the project is correct. In team-managed projects issue types are created and managed inside the project by the project admin rather than by global schemes.

Apply issue-level restrictions so only selected project roles can view issues is wrong because issue security schemes and fine grained issue level restrictions are handled in company-managed projects and require global or site level configuration rather than the per-project controls used by team-managed projects.

Use a shared workflow scheme across several projects is wrong because team-managed projects do not support shared workflow schemes. Workflows in team-managed projects are configured per project and they are not managed through shared schemes that span multiple projects.

Adjust the set of issue types available in the project is wrong as an exclusive behavior because both project types can have their available issue types changed, and company-managed projects achieve this through shared issue type schemes. The ability to change which issue types are available is not unique to team-managed projects.

Focus on whether a feature is managed locally inside the project or by shared schemes across the site. Team-managed equals local project control, and company-managed equals shared schemes and global administration.