How to pass Jira's ACP-620 Managing Cloud Projects certification exam on the first try

A product group at Nimbus Labs uses a workflow with three statuses To Do In Progress and Done. Maya needs to locate every reopened issue so she can assign them to her team and reopened issues are returned to the To Do status. Which JQL will retrieve only issues that were previously in Done and are now in To Do?

• ❏ A. status = “To Do” AND resolution is EMPTY

• ❏ B. status was not in (“In Progress”, “Done”)

• ❏ C. status was “Done” AND status = “To Do”

• ❏ D. status changed FROM “Done” TO “To Do”

• ❏ E. status was “Done” AND resolution is EMPTY

Marina and her product team share a common board with other groups in the organization and she needs a simple way to view only the tickets tagged with her team name without changing the board reporting settings, what board configuration should be adjusted to enable that? (Choose 2)

• ❏ A. Board filter

• ❏ B. Quick filters

• ❏ C. Swimlanes

• ❏ D. Column mappings

• ❏ E. Board sub-filter

A product owner asked you to configure a team-managed scrum project for a development squad and the setup must meet these requirements. Only a specific set of users should be able to create new issues. Every user who can access the site must be able to attach files to the issues they are allowed to view. All story issues must be visible only to project Members and Administrators. Which project access level should you configure?

• ❏ A. Private project

• ❏ B. Issue security scheme

• ❏ C. Limited project access

• ❏ D. Open project

• ❏ E. Project visible to Members and Administrators only

At Riverbend Tech the project lead is evaluating how the “Components” field helps organize issues across projects. Which of the following statements about the “Components” field cannot be achieved using Components? (Choose 2)

• ❏ A. Automatic issue assignment when a component is chosen

• ❏ B. Can be shared across projects

• ❏ C. Allow selecting multiple components on an issue

• ❏ D. Must be managed by a Jira administrator

• ❏ E. Can be managed by a project administrator

Maya needs a dashboard gadget that displays the percentage breakdown of issues assigned to her team using a saved filter. Which gadget will display that percentage view? (Choose 2)

• ❏ A. Heat Map

• ❏ B. Two Dimensional Filter Statistics

• ❏ C. Pie Chart

• ❏ D. Filter Results

• ❏ E. Issue Statistics

• ❏ F. Bubble Chart

You are the board administrator for the “Orbit” Kanban Board and you can view and edit every issue in the Backlog and on the Kanban board. Despite that you cannot see the board’s Roadmap and a message is shown. What possible explanations might cause this? (Choose 2)

• ❏ A. A quick filter is active

• ❏ B. This board belongs to a team-managed project which uses a different roadmap configuration

• ❏ C. The board filter returns issues from more than one project

• ❏ D. The board filter excludes the Epic issue type or parent issues

• ❏ E. You lack permission to view the roadmap

Ava from Northbridge Systems needs the Fix Status field cleared automatically whenever an agent reopens a ticket. How can this behavior be implemented efficiently? (Choose 2)

• ❏ A. Workflow conditions

• ❏ B. Automation rule

• ❏ C. Workflow post functions

• ❏ D. ScriptRunner validator

• ❏ E. Bulk change operation

Which permission allows Aisha to create and modify project versions and manage the project components?

• ❏ A. Schedule Issues

• ❏ B. Manage Components

• ❏ C. Administer Projects

• ❏ D. Manage Project Roles

Ava at Nimbus Apps has noticed that her company managed Kanban board control chart is omitting several critical tasks even though her team can view and update those issues. What are the most likely root causes? (Choose 2)

• ❏ A. Report filter

• ❏ B. Project permission scheme

• ❏ C. Board filter

• ❏ D. Issue security level

• ❏ E. Board sub filter

Which statements correctly describe issue types in a company managed project within a Jira instance? (Choose 2)

• ❏ A. Project administrators can add new issue types for company managed projects

• ❏ B. Only Jira administrators can create new issue types across the instance

• ❏ C. Issue types are always ordered with Epic first then standard types then sub task types

• ❏ D. The default issue type for a scheme can be set to None

Your delivery organization at Nimbus Labs is moving to scaled agile and plans to adopt Advanced Roadmaps for Jira. Which of the following is a feature of Advanced Roadmaps for Jira?

• ❏ A. Allows teams to create their own custom progress metrics

• ❏ B. Provides a built in report sharing capability between users

• ❏ C. Scales to support hundreds or many thousands of users across an enterprise

• ❏ D. Edits made within an Advanced Roadmaps plan remain in the plan until you save them into Jira Software

Two squads spent 18 months working in separate Jira projects and then created a single shared board that spans both projects. Which board capabilities are available when the board covers multiple projects? (Choose 2)

• ❏ A. Show versions from both projects on the Releases page

• ❏ B. Advanced Roadmaps

• ❏ C. Enable the Kanban backlog for the shared board

• ❏ D. Drag issues from one project into epics created in the other project

• ❏ E. Drag issues from one project onto versions that belong to the other project

Lucas and his development team are using an organizational project that was created from an Agile template and has remained on the original default settings without any updates. Which statement about how the velocity chart handles subtasks is true?

• ❏ A. The velocity chart will include subtasks in its calculation when an “Include child issues” setting is enabled at the report level

• ❏ B. The velocity chart includes subtasks only when the parent issue has an “Include child issues” toggle turned on

• ❏ C. The velocity chart always counts estimates from subtasks together with parent issue estimates when computing team velocity

• ❏ D. The velocity chart excludes estimates from subtasks and uses only parent issue estimates to compute the team velocity

Marina discovered that the People Operations Jira project at Brightfield was using the wrong project key and she changed the key from “PR” to “PE” while renaming the project. What effect will this have on Jira?

• ❏ A. Dashboard gadgets that use the project key will need manual updates

• ❏ B. Saved filters will continue to function using the old project key

• ❏ C. A new project can be created using the previous project key

• ❏ D. Web links that contained the former project key will stop working

A delivery team at Northbay Solutions uses a Kanban board in their scrumtuous.com project and they find the rightmost column cluttered with finished tasks, and they want the board to automatically show only items completed in the current week without manual intervention. Which board configuration should be changed?

• ❏ A. Main board filter

• ❏ B. Hide completed issues older than setting

• ❏ C. Board sub-filter

• ❏ D. Quick filters

AgileTrack automation reduces repetitive manual tasks so teams can concentrate on delivery. Which statements about AgileTrack automation are correct? (Choose 3)

• ❏ A. An automation can only be applied to one project

• ❏ B. By default the actor on a rule is the Automation for AgileTrack service user

• ❏ C. A failing rule always sends an email notification to the rule owner

• ❏ D. Rules can trigger other rules

• ❏ E. Automations can publish events to Google Pub/Sub for downstream processing

• ❏ F. The Audit Log contains execution records and status for automation rules

A product team at Aurora Systems needs to add a subtask to an issue that is already in an active sprint. The Scrum board has the Remaining estimate and Time spent feature enabled. How will the added subtask affect the sprint scope and the burndown chart?

• ❏ A. The subtask will be counted as a scope change but it will not update the burndown chart

• ❏ B. The subtask will be treated as a scope change and it will be shown in the burndown chart

• ❏ C. The subtask will not change sprint scope but it will appear on the burndown chart

• ❏ D. The subtask will not alter sprint scope and it will not be reflected in the burndown chart

SummitTech is moving its deployment from Jira Software Server to Jira Software Cloud Premium and the product owner wants to know which Advanced Roadmaps capability supports coordinating multiple agile teams. Which statement about Advanced Roadmaps is accurate?

• ❏ A. Export plans into Excel XML or PDF formats

• ❏ B. Visualize plan and monitor progress for multiple agile teams up to the program level

• ❏ C. Jira Align

• ❏ D. Provide reporting at levels from single teams through the entire enterprise

Rina created a Jira filter called “Portfolio Filter” that includes issues from both team managed projects and company managed projects. She then built a company managed Kanban board named “Portfolio Kanban” using that filter. Which statement about the board is correct?

• ❏ A. Team managed project issues will appear on the company managed Kanban board but they cannot be moved between statuses from that board

• ❏ B. Team managed project issues will appear on the company managed Kanban board and permitted users can transition them between statuses

• ❏ C. No issues will be shown on the company managed Kanban board because the filter spans multiple project types

• ❏ D. Team managed project issues will be excluded and only company managed project issues will be visible on the board

Which capabilities are not supported by a team managed project in Jira Cloud? (Choose 2)

• ❏ A. Enable release and milestone tracking

• ❏ B. Restrict who can transition issues by referring to a group custom field

• ❏ C. Create cascading select fields where one dropdown depends on another

• ❏ D. Default a Timestamp field to the current date and time

• ❏ E. Modify the set of “Resolution” values for the project

Maya must create a new board for this situation. Project members should be able to control their own permissions. The board must support flexible timing for when tasks are completed. Which project type should Maya select?

• ❏ A. Company-managed Scrum project

• ❏ B. Team-managed Kanban project

• ❏ C. Team-managed workflow project

• ❏ D. Company-managed Kanban project

At Meridian Dynamics the team uses company managed boards and they want to know who can change the configuration of a board that is associated with a project. Who can change the configuration of that board? (Choose 2)

• ❏ A. Site administrator

• ❏ B. Project lead for the project where the board is located

• ❏ C. Board administrator

• ❏ D. Board owner

• ❏ E. Project administrator for the project where the board is located

In which situations is it appropriate to use Jira groups instead of project roles or individual user assignments? (Choose 4)

• ❏ A. Team members need the ‘Work On Issues’ permission to record time spent

• ❏ B. Assign group membership when members must perform bulk edits across many issues

• ❏ C. Allow a project administrator to directly add or remove users from a group

• ❏ D. Use groups to grant global system permissions across the Jira site

• ❏ E. Create groups when the same set of users will collaborate across several projects

• ❏ F. Use groups when overall membership should be controlled by a site administrator

Maya manages the company managed project “ORION” which uses a single workflow with the statuses Open, In progress, Pending review and Done. She needs a filter that returns issues that were previously in the Done status and are now in a different status so she can receive daily email notifications. Which JQL query will identify those reopened issues?

• ❏ A. status changed from “Done” to “Open” OR “In progress” OR “Pending review”

• ❏ B. status in (“Open”, “In progress”, “Pending review”)

• ❏ C. status was “Done” and status != Done

• ❏ D. status changed from “Done”

Six distinct feature teams must work within a single organization managed project and the project uses Components to mark functional areas. Each team must be able to generate a Cumulative Flow Diagram that displays only the issues for that team. What is the minimum number of boards required to satisfy these conditions?

• ❏ A. Six boards

• ❏ B. One board

• ❏ C. Four boards

• ❏ D. Twelve boards

In the Titan Projects instance at example.com what is the correct behavior for archived release entries in the “Fix Versions” and “Affects Versions” field dropdowns?

• ❏ A. Archived releases remain selectable in both the “Fix Versions” dropdown and the “Affects Versions” dropdown

• ❏ B. Archived releases are not selectable in either the “Fix Versions” dropdown or the “Affects Versions” dropdown

• ❏ C. Archived releases are selectable only in the “Fix Versions” dropdown and not in the “Affects Versions” dropdown

• ❏ D. Archived releases are selectable only in the “Affects Versions” dropdown and not in the “Fix Versions” dropdown

You are the release coordinator for a vendor overseen project and you must configure automation so the team receives a Slack alert whenever critical priority tickets are assigned changed or moved. Which automation rule would you implement?

• ❏ A. Configure three separate automation rules where one uses the “Issue Assigned” trigger the next uses the “Issue Transitioned” trigger and the third uses the “Issue Updated” trigger with a JQL condition priority = Critical and a Slack message action

• ❏ B. Implement a single scheduled automation that runs every five minutes queries for recently changed issues with priority = Critical and posts a message to Slack

• ❏ C. Create a single automation that listens for multiple issue events including “Issue Updated” “Issue Assigned” and “Issue Transitioned” applies a JQL condition priority = Critical and sends a Slack notification

• ❏ D. Create two automation rules where the first uses the “Issue Assigned” trigger and the second uses the “Issue Updated” trigger and both check priority = Critical before sending a Slack message

Which reports and dashboard gadgets honor a board’s “Working days” configuration when calculating their metrics? (Choose 3)

• ❏ A. Cumulative flow diagram

• ❏ B. Sprint health gadget

• ❏ C. Velocity chart

• ❏ D. Sprint report

• ❏ E. Control chart

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

Marina has been promoted to lead for a development team at scrumtuous.com. Her supervisor asked her to update every team member’s time entries and to remove everyone’s worklogs in a Jira project. Which issue permissions should Marina request from the project administrator? (Choose 3)

• ❏ A. Modify Personal Worklogs

• ❏ B. Remove All Worklogs

• ❏ C. Schedule Issues

• ❏ D. Log Work on Issues

• ❏ E. Remove Personal Worklogs

• ❏ F. Modify All Worklogs

You are the project lead for the team-managed project “TRK” at a delivery startup called Fleetly. The project was previously open so every Jira user on your site could create view and edit issues. You changed the project access to Limited and did not add any Jira users to the project. What is true about this change?

• ❏ A. Reporters will not be able to see the project board

• ❏ B. Reporters will no longer be able to view their own issues

• ❏ C. Users assigned to issues will still be able to attach files to the issues they own

• ❏ D. Assignees will be able to change issue ranking

• ❏ E. Assigned users will lose the ability to add comments on their assigned issues

Priya needs to locate overdue tasks from both the company-controlled project “APOLLO” and the team-run project “LUNA” that have priority at least High and whose assignee is a member of the group “alpha_squad” What JQL will return these issues?

• ❏ A. project = “APOLLO” OR project = “LUNA” OR priority = “High” AND assignee = membersOf(“alpha_squad”) AND due < current()

• ❏ B. project in (“APOLLO”,”LUNA”) AND priority >= “High” AND assignee = membersOf(“alpha_squad”) AND due < “0”

• ❏ C. project in (“APOLLO”,”LUNA”) AND priority >= “High” AND assignee in membersOf(“alpha_squad”) AND due < now()

• ❏ D. project = “APOLLO” AND project = “LUNA” AND priority >= “High” AND assignee in membersOf(“alpha_squad”) AND due < now()

Marco works on the Scrum board LedgerApp Sprint Board for the company-managed project LEDGR and he observes that tasks older than six weeks are automatically excluded from the board while they remain findable in issue search results. He needs all tasks to stay visible on the board regardless of age. Which board configuration must be changed?

• ❏ A. Update quick filters

• ❏ B. Adjust the hide completed issues older than setting

• ❏ C. Change the board saved filter

• ❏ D. Modify the board sub filter

Which of the following statements about Jira project and board administration is accurate?

• ❏ A. A Jira project can have multiple project leads

• ❏ B. A board is allowed to have more than one board administrator

• ❏ C. A saved search filter can be owned by several users

• ❏ D. The default assignee for issues can be either the project lead or the component lead

• ❏ E. Project administrators can create new global roles and assign members to them

Maya works with a corporate managed Scrum board for her squad and she can confirm that the board saved filter returns all issues when she uses the “Advanced issue search” however some issues are not visible on the board view. What might cause those tickets to be missing? (Choose 2)

• ❏ A. The board saved filter

• ❏ B. The board quick filters

• ❏ C. Issue security level

• ❏ D. Status mapping to columns

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

• ❏ F. The board sub filter

Maria is a scrum master who uses Jira Software Cloud to track team work for NovaTech. She was added to the “Regulatory” company managed Scrum project. She can edit comment and transition issues that are assigned to her but she cannot edit several other issues in the same project. What action should be taken to allow Maria to edit those issues?

• ❏ A. Modify global permissions

• ❏ B. Adjust project permission scheme

• ❏ C. Change issue security level

• ❏ D. Contact Atlassian support

Priya needs a weekly email each Friday that contains a compiled list of all blocker tickets for her team across the project. Which Jira features must Priya use to receive that consolidated weekly list? (Choose 2)

• ❏ A. Automation

• ❏ B. Subscription

• ❏ C. Notifications

• ❏ D. Filters

• ❏ E. Global Permission

• ❏ F. Post Function

Brightline uses scrumtuous.com for issue tracking and runs organization-managed projects. Which of the following reports are available only on the Scrum board in such an organization-managed project? (Choose 4)

• ❏ A. Control Chart

• ❏ B. Iteration Burndown Chart

• ❏ C. Cumulative Flow Diagram

• ❏ D. Burnup Chart

• ❏ E. Velocity Report

• ❏ F. Iteration Summary Report

Maya manages the project “ORBIT” and the project currently contains versions “2.0” and “2.2”. Maya needs to remove the “2.0” version from the project and move all issues assigned to “2.0” into “2.2”. Which actions on the Releases page will let Maya accomplish this? (Choose 2)

• ❏ A. Release version

• ❏ B. Merge versions

• ❏ C. Archive version

• ❏ D. Delete version

• ❏ E. Unrelease version

Priya oversees more than 13 Jira projects and she wants the board to display issues grouped by their project while keeping every issue visible. Which board feature should she use?

• ❏ A. Board Sub Filter

• ❏ B. Issue Detail View

• ❏ C. Swimlanes

• ❏ D. Quick Filters

• ❏ E. Hide Completed Issues

• ❏ F. Board Filter

You were just added to a Jira Software Cloud instance for a product team at Nimbus Labs and the site is using its default configuration. What must you do to be able to create team managed projects?

• ❏ A. Request membership in a site administration group

• ❏ B. Request specific project permissions from an existing project administrator

• ❏ C. No additional action is required you can create team managed projects with the default site settings

• ❏ D. Ask a site administrator to grant the Create team managed projects global permission

Several squads at a software consultancy need to run sprints concurrently from the same backlog because they are delivering different components. Which Jira project type allows multiple active sprints to run at the same time?

• ❏ A. Neither team-managed nor company-managed projects support parallel sprints

• ❏ B. Company-managed projects only

• ❏ C. Both team-managed and company-managed projects

• ❏ D. Team-managed projects only

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

Maya is the board administrator for a Kanban board at SummitTech and she needs issues that have been resolved for more than 2 days to be removed from the company-managed board automatically with minimal ongoing maintenance, how can she achieve this?

• ❏ A. Adjust the board filter

• ❏ B. Use the Hide completed issues older than setting

• ❏ C. Modify the board sub-filter

• ❏ D. Create a board automation rule to transition resolved issues off the board

Raj needs a visual that displays how many work items were in each workflow state over a two week period. Which chart should he use?

• ❏ A. Burndown chart

• ❏ B. Velocity chart

• ❏ C. Control chart

• ❏ D. Sprint report

• ❏ E. Cumulative flow diagram

Alyssa is the billing lead in the Accounting Group and she must add a new Jira account plus grant access to the company applications and billing features. Which Jira user role best matches Alyssa’s duties?

• ❏ A. Jira Software user

• ❏ B. Jira administrator

• ❏ C. Site administrator

• ❏ D. Project administrator

Mina is the technical lead for the Platform Squad and she uses a company managed project board. She wants platform related tickets to appear in the top horizontal lane and the other tickets to appear in lanes beneath it. Which board feature will let her arrange issues in that way?

• ❏ A. Quick Filters

• ❏ B. Board Sub Filter

• ❏ C. Issue Detail View

• ❏ D. Swimlanes

• ❏ E. Hide Completed Issues

• ❏ F. Board Filter

NovaCorp manages a scrum project named “NOVA” and they notice that when issues move into the “QA” status they are automatically assigned to Priya. Which two settings or configurations could cause that automatic reassignment? (Choose 2)

• ❏ A. Components

• ❏ B. Workflow post functions

• ❏ C. Project default assignee

• ❏ D. Global automation rule

• ❏ E. Workflow validators

• ❏ F. Automation rule

Diego has just spun up a company-managed project from a template named “SPRINTX” and the new project is called “ARC-2025”. Diego wants to know which schemes are provisioned as unique to this freshly created company-managed project rather than being shared with other projects. Which schemes are unique to the new project? (Choose 3)

• ❏ A. Field Configuration Scheme

• ❏ B. Issue Type Scheme

• ❏ C. Notification Scheme

• ❏ D. Workflow Scheme

• ❏ E. Screen Scheme

• ❏ F. Issue Security Scheme

• ❏ G. Priority Scheme

Which behaviors are true for team-managed projects in Jira Cloud when using boards and bulk issue creation? (Choose 2)

• ❏ A. The issue navigator cannot be turned on or used in team-managed projects

• ❏ B. Clearing a parent issue from the board also clears its subtasks regardless of each subtask’s status

• ❏ C. You can create multiple issues at once by pasting several lines into the create box on the board

• ❏ D. You can set a project wide default issue security level in a team-managed project

• ❏ E. In a scrum template team-managed project you can create issues directly from any board column even when sprints are active

Marisol is the board administrator for the company managed board named Orbital Expeditions Board and she notices that several tickets appear in the issue navigator when using the saved filter but they do not appear on the Kanban board view. Which Jira setting is most likely causing those tickets to be excluded from the board?

• ❏ A. Quick filter

• ❏ B. Swimlanes

• ❏ C. Issue level security

• ❏ D. Board sub filter

A new set of engineers will join a team to develop a customer portal. As the project administrator Maya needs a way to control who can perform actions inside the project. Which permission construct should Maya add to the project permission scheme?

• ❏ A. Individual users

• ❏ B. Project roles

• ❏ C. Groups

Alex is the finance lead for several project streams at Meridian Accounting. He wants his Kanban board to automatically show only issues tagged with the finance component without requiring any clicks on the board. He also needs the filtering to leave the Cumulative Flow Diagram report results unchanged. Which board feature should he use?

• ❏ A. Quick Filters

• ❏ B. Board sub-filter

• ❏ C. Swimlanes

• ❏ D. Board Filter

• ❏ E. Issue Detail View

• ❏ F. Hide completed issues

Aria at Skyline Software needs a report that shows how long a single issue or a group of issues has been sitting in a given status. Which report should she create?

• ❏ A. Velocity chart

• ❏ B. Issue age report

• ❏ C. Cumulative flow diagram

• ❏ D. Control chart

• ❏ E. Burndown chart

Which statements about labels in the issue tracker at scrumtuous.com are accurate? (Choose 3)

• ❏ A. Labels can be included in reports

• ❏ B. Labels can contain inconsistent values

• ❏ C. Labels are only accessible at the project level

• ❏ D. Label values are not dependable for filtering and searching issues

• ❏ E. Labels are governed by a central taxonomy that enforces allowed values

• ❏ F. The Bulk Change tool can find and remove label values across many issues

Jordan is maintaining a Scrum board that spans several company-managed projects and has mapped every workflow status to a column on the board. Jordan reports that certain issues are not visible on the Active sprints board or in the Backlog. Which settings could be responsible for this? (Choose 4)

• ❏ A. Board saved filter

• ❏ B. Hide completed issues older than setting

• ❏ C. Project permissions

• ❏ D. Board sub filters

• ❏ E. Board quick filters

• ❏ F. Global permissions

• ❏ G. Issue security levels

• ❏ H. Unmapped statuses

A project lead named Aisha created a new company managed project by choosing the shared configuration option. Which project specific settings will she need to update manually? (Choose 3)

• ❏ A. Priority scheme

• ❏ B. Components

• ❏ C. Notification scheme

• ❏ D. Versions

• ❏ E. Project avatar

• ❏ F. Issue status

status was “Done” AND status = “To Do” is correct.

This query uses the history operator was to confirm the issue was at some point in Done and it also requires the issue to be currently in To Do. The combination ensures you only get issues that were previously in Done and are now returned to To Do which matches Maya’s need to find reopened items.

status = “To Do” AND resolution is EMPTY is incorrect because it only finds issues that are currently in To Do with no resolution and it does not verify that they were ever in Done.

status was not in (“In Progress”, “Done”) is incorrect because it selects issues that have never been in those statuses which is the opposite of finding issues that were previously in Done.

status changed FROM “Done” TO “To Do” is incorrect because it matches only issues that had a direct transition from Done to To Do and it can miss cases where an issue was in Done and later ended up in To Do by a different path. The status was approach captures any past time in Done regardless of the transition path.

status was “Done” AND resolution is EMPTY is incorrect because it ensures the issue was in Done and is unresolved but it does not require the issue to be currently in To Do. That means it can return issues in other open statuses.

When you need to find issues that were in a past status and are now in a specific status use the was operator for history and combine it with status = to restrict the current state.

The correct options are Quick filters and Swimlanes.

Using Quick filters lets Marina apply a temporary, top level filter on the shared board so she can instantly view only the tickets that carry her team tag. Quick filters are ideal for ad hoc, per user views because they do not change the board’s saved reporting settings and they can be toggled on and off.

Using Swimlanes lets the board group issues into horizontal lanes based on JQL, assignee, or a custom field and you can create a swimlane for the team tag so those issues appear in a dedicated lane. Swimlanes are a board configuration that helps surface team tagged tickets in a clear grouped view without altering column mappings.

Board filter is not correct because the board filter is the primary JQL that defines which issues appear on the board and changing it affects the entire board and its reporting rather than providing a simple, user specific view.

Column mappings is not correct because column mappings control how workflow statuses map to board columns and they do not provide filtering by team tag.

Board sub-filter is not correct because a sub filter is a global restriction applied to the board and it is not meant for ad hoc or per user views of issues tagged to a single team.

Use Quick filters for fast ad hoc, per user views and use Swimlanes when you want a persistent grouped view for a team on the board.

Limited project access is correct because it lets you restrict who can create and manage issues to a defined set of project members while still allowing any site user who can view an issue to attach files, and it ensures story issues are only visible to project members and administrators.

This access level restricts project actions to the project membership and administrators, and it relies on global and project permissions to allow attachments for users who can view issues. That combination meets all three requirements in the question.

Private project is incorrect because making a project private would block visibility and actions for users who are not explicitly added, so it would prevent the requirement that every site user be able to attach files to issues they can view.

Issue security scheme is incorrect because issue security schemes are not a team-managed project feature and they control per-issue visibility rather than project-level creation permissions, so they do not provide the required project-level access control for this scenario.

Open project is incorrect because an open project allows broader access and would not limit issue creation to a specific set of users, so it fails the requirement to restrict who can create new issues.

Project visible to Members and Administrators only is incorrect because that phrasing is not the specific team-managed project access setting and it does not by itself address the creation permission or align with how team-managed projects handle attachments and membership controls.

Read the question and identify the project type first. If it is a team-managed project then choose the access setting that limits membership for creation and rely on global permissions for attachments.

The correct answers are Can be shared across projects and Must be managed by a Jira administrator.

The statement Can be shared across projects is not achievable because Components in Jira are defined at the project level and there is no built in way to share a single Component definition across multiple projects.

The statement Must be managed by a Jira administrator cannot be achieved because Components are typically created and maintained by a project administrator through the project settings and they do not require site or system administrator privileges to manage.

Automatic issue assignment when a component is chosen is incorrect because Jira supports assigning a default assignee for a Component and you can also use automation rules to route issues based on the Component field.

Allow selecting multiple components on an issue is incorrect because issues can include one or more Components and the interface allows selecting multiple entries for that field.

Can be managed by a project administrator is incorrect because this is actually true in Jira and project administrators can add and edit Components from their project settings.

Read the question carefully and watch for the word cannot or cannot be achieved because those change what you are selecting. Remember that Components are project level features in Jira and that project administrators can usually manage them.

The correct options are Pie Chart and Issue Statistics.

Pie Chart displays the issues returned by a saved filter as slices where each slice represents a group and its proportion of the total, so it is the straightforward gadget for showing percentage breakdowns visually.

Issue Statistics groups the issues from a saved filter by a chosen field and reports the counts per group, which can be interpreted as each group�s share of the total and used to present a percentage view on a dashboard.

Heat Map is incorrect because it visualizes density or activity patterns and not a simple percentage breakdown of issues by assignee or other single field.

Two Dimensional Filter Statistics is incorrect because it produces a matrix of counts across two fields for cross tabulation rather than a single percentage breakdown by one field.

Filter Results is incorrect because it lists individual issues returned by a filter and does not aggregate those issues into percentage slices.

Bubble Chart is incorrect because it shows relative volumes as bubble sizes for comparison and it does not provide the clear percentage slice view that a pie chart or grouped issue statistics deliver.

When a question asks for a percentage breakdown look for gadgets that aggregate results and provide visual proportions. Use saved filters so the gadget targets the correct set of issues.

The correct options are The board filter returns issues from more than one project and The board filter excludes the Epic issue type or parent issues.

The board filter returns issues from more than one project can prevent the roadmap from appearing because roadmaps are typically scoped to a single project and a board that pulls issues from multiple projects cannot build a single project roadmap to display.

The board filter excludes the Epic issue type or parent issues will hide the Epics or parent relationships that the roadmap relies on so the roadmap cannot render the hierarchy and it will show a message instead.

A quick filter is active is not the cause because quick filters only change which issues are temporarily highlighted or shown on the board for the current user and they do not alter the board s underlying filter or the roadmap configuration.

This board belongs to a team-managed project which uses a different roadmap configuration is unlikely in this scenario because the described message is about missing epics or a multi project filter rather than differences in team managed versus company managed roadmap features.

You lack permission to view the roadmap is not correct because you can already view and edit every issue in the backlog and on the board so you have the necessary project browsing and editing permissions and the problem is about filter composition not access rights.

When a roadmap is not visible first check the board filter to see if it spans multiple projects and confirm that Epic and parent issue types are included.

Automation rule and Workflow post functions are correct because they can be used to automatically clear the Fix Status field when an agent reopens a ticket.

Automation rule can trigger on the issue reopened event and then run an action to update or clear the Fix Status field. Automation rules are efficient for handling repeated events across issues and they do not require modifying the workflow for every project where the behavior is needed.

Workflow post functions run as part of a transition such as a reopen transition and can update fields during that transition. Use a post function when you want the field change to be tied directly to the workflow step so the update happens reliably during the transition.

Workflow conditions are checks that decide whether a transition can proceed and they do not perform field updates, so they cannot be used to clear the Fix Status field on reopen.

ScriptRunner validator runs before a transition to validate data and possibly block the transition. A validator is not intended to change field values during the transition, so it is not the right mechanism for clearing a field.

Bulk change operation is a manual operation to modify many issues at once and it does not run automatically when an agent reopens a single ticket, so it does not meet the automation requirement.

When deciding between options identify the event or trigger first and then pick an action that updates fields. Prefer Automation rules for repeated or cross project events and prefer workflow post functions when the change must occur as part of a specific transition.

The correct option is Administer Projects.

Administer Projects grants project level administration rights so a user can create and modify project versions and manage the project components. This permission covers the configuration and settings for a project which includes adding and editing versions and components and other release related configuration.

Schedule Issues is incorrect because that permission only allows users to set scheduling fields on issues and it does not give access to create or manage project versions or components.

Manage Components is incorrect because most permission schemes do not define a separate global permission with this exact name and component management is handled through the project administration permission. The ability to add and edit components is therefore provided by project administration rather than a distinct “Manage Components” permission.

Manage Project Roles is incorrect because it only lets a user create and modify project roles and their membership and it does not allow creating versions or managing components.

When a question asks about creating or configuring project objects look for permissions that reference administration or project settings because configuration tasks are usually tied to administrative permissions.

The correct options are Report filter and Board filter.

The Report filter defines which issues a report includes and can therefore exclude tasks from the control chart even when users still have permission to view and update those issues. Reports use their own filter criteria so a restrictive report filter will omit issues from the chart.

The Board filter determines which issues belong to the board and the control chart is built from the board’s issue set. If the board filter excludes certain tasks they will not appear on board-based reports even though the team can interact with those issues elsewhere.

Project permission scheme is unlikely because the scenario states the team can view and update the issues, and project permissions would prevent visibility or editing rather than selectively removing issues from a report.

Board sub filter is not the primary cause here because the main board filter or the report filter are the usual reasons for missing items. The sub filter further narrows results but the symptoms point to the higher level filters first.

Issue security level is also unlikely since security levels restrict who can see an issue and the team already has view and edit access, so security settings would not explain the selective omission from the control chart.

When issues are missing from a report check the board filter and the report filter first and then run a JQL search to confirm which issues are being included or excluded.

The correct options are Only Jira administrators can create new issue types across the instance and The default issue type for a scheme can be set to None.

In Jira the set of issue types is a system wide configuration and Only Jira administrators can create new issue types across the instance. Project administrators can manage which existing issue types are associated with a project but they cannot create new global issue types.

An issue type scheme can be left without a default and The default issue type for a scheme can be set to None. This lets projects require that users pick an issue type at creation or rely on other project specific behaviors instead of forcing a particular default.

Project administrators can add new issue types for company managed projects is incorrect because creating new issue types is performed at the instance level by Jira administrators. Project administrators can only associate or reorder existing issue types for their projects.

Issue types are always ordered with Epic first then standard types then sub task types is incorrect because ordering is determined by the issue type scheme and project configuration and it is not a fixed global rule. Sub task types are managed separately and display order can vary by scheme and UI context.

When choosing answers focus on whether the change is global or project specific and watch for wording that mentions the instance or an issue type scheme.

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

The correct option is Edits made within an Advanced Roadmaps plan remain in the plan until you save them into Jira Software.

Advanced Roadmaps provides a draft editing surface so that edits made within a plan are staged and do not modify Jira issues until you explicitly save or commit those changes back to Jira. This behaviour lets planners experiment with scheduling, hierarchy adjustments and bulk updates and then push a single set of changes to the source issues when they are satisfied.

Allows teams to create their own custom progress metrics is incorrect because Advanced Roadmaps uses built in progress calculations and fields from Jira and it does not offer a general feature to define arbitrary new progress metrics inside the plan interface. Teams can use custom fields in Jira but that is different from an in‑plan custom metric builder.

Provides a built in report sharing capability between users is incorrect because Advanced Roadmaps focuses on planning and publishing changes and it does not provide a separate dedicated report sharing system. Users can share plan views, export data or grant access in Jira but there is no distinct built in report sharing feature apart from those options.

Scales to support hundreds or many thousands of users across an enterprise is incorrect as stated because Advanced Roadmaps is an app on top of Jira and scalability depends on your Jira deployment, licensing and plan sizes. While it is designed for multi team planning it is not a standalone claim that it will perform uniformly at very large user counts without considering Jira capacity and configuration.

When a question mentions plan changes look for words like save or commit. Those words usually indicate that changes are drafts in the plan until you push them to Jira.

The correct options are Enable the Kanban backlog for the shared board and Drag issues from one project into epics created in the other project.

Enable the Kanban backlog for the shared board is available because the Kanban backlog is a board level feature that you can turn on for any Kanban board. When a board is based on a filter that spans multiple projects the backlog panel and its controls belong to the board and therefore can be enabled for that shared view.

Drag issues from one project into epics created in the other project works because epics are just an issue type and the epic link can associate issues across projects when those issues are visible to the board. If the board filter includes both projects you can associate or drag issues into epics that originate in a different project.

Show versions from both projects on the Releases page is incorrect because the Releases page and versions are project scoped. Versions belong to individual projects so the Releases view will not automatically merge versions from separate projects into a single project scoped Releases list.

Advanced Roadmaps is incorrect because Advanced Roadmaps is a separate planning tool and not a board capability. It provides cross project planning when set up, but it is not something that is simply enabled on a shared board as a board feature.

Drag issues from one project onto versions that belong to the other project is incorrect because versions are tied to a specific project. You cannot assign an issue to a version that belongs to another project simply by dragging on the shared board unless that version is available in the issue’s project context.

When a question contrasts board features and project settings check whether the feature is tied to the board or to a project. Board level features can span projects if the board filter includes them. Project scoped items such as versions usually do not.

The correct answer is The velocity chart excludes estimates from subtasks and uses only parent issue estimates to compute the team velocity.

This reflects the default behavior of the Jira Software Scrum velocity chart when an Agile template is used and settings remain unchanged. The report aggregates estimates at the parent issue level only and it does not add estimates placed on subtasks to the sprint totals.

If a team puts estimate values on subtasks those values will not contribute to the displayed team velocity unless the estimates are moved up to the parent issues or a custom roll up process is implemented. In practice teams either keep story points on parent issues or use automation or reporting tools to combine subtask estimates into parent totals.

The velocity chart will include subtasks in its calculation when an “Include child issues” setting is enabled at the report level is incorrect because Jira does not provide a report level “Include child issues” toggle in the default velocity report. The built in report reads estimates from sprint issues without that report level switch.

The velocity chart includes subtasks only when the parent issue has an “Include child issues” toggle turned on is incorrect because there is no per parent issue toggle in the standard Scrum velocity chart that causes subtask estimates to be counted. The chart relies on parent issue estimates by default.

The velocity chart always counts estimates from subtasks together with parent issue estimates when computing team velocity is incorrect because the chart does not automatically combine subtask estimates with parent estimates. Subtask estimates are ignored for the built in velocity calculation unless you change how estimates are recorded or create a custom report.

When a question asks about default report behavior remember to think about where estimates must live to be counted. If estimates are on subtasks they are commonly not rolled up to the velocity chart and you should prefer answers that reference parent issue estimates.

Saved filters will continue to function using the old project key is correct.

Saved filters will continue to function using the old project key is correct because Jira preserves and updates the underlying references when a project key is changed so queries that reference the project still return the expected issues. Jira stores project references by internal identifiers and it will either update saved JQL or resolve the old key to the project so saved filters keep working after the key change.

Dashboard gadgets that use the project key will need manual updates is incorrect because gadgets that are driven by saved filters or by Jira query references continue to work since the filters and references are updated or resolved automatically. You normally do not have to manually edit each gadget after a project key change.

A new project can be created using the previous project key is incorrect because the old key remains associated for compatibility and redirect purposes and so it is not simply freed up for immediate reuse as a different project key.

Web links that contained the former project key will stop working is incorrect because Jira provides redirects and maintains mappings from old issue keys to the new keys so links that used the former key will continue to reach the correct issues.

When answering questions about changing project keys remember that Jira updates internal references and uses redirects to preserve access. Focus on whether a feature relies on stored queries or on static URLs when picking the correct option.

The correct option is Board sub-filter.

The Board sub-filter is applied in addition to the board filter and it lets you add JQL that automatically restricts what appears on the board. You can add a clause such as resolved >= startOfWeek() to limit the view to issues completed in the current week. Changing the sub-filter makes the board update automatically without users needing to apply a manual filter.

The Main board filter defines the overall set of issues that belong to the board and changing it can affect backlogs and other views. It is not the best place to add a time based display rule for completed items because it changes the permanent issue scope for the board.

The Hide completed issues older than setting is a UI convenience that only hides items based on a fixed age threshold. That control cannot reliably express a calendar week like the current week and it is less flexible than using JQL in the sub-filter.

The Quick filters are user triggered buttons that apply temporary JQL when clicked. They do not change the board view automatically so they do not meet the requirement of showing only items completed in the current week without manual intervention.

Use a board sub-filter with JQL functions like startOfWeek() so the board updates automatically and avoid relying on manual quick filters.

The correct answers are By default the actor on a rule is the Automation for AgileTrack service user, Rules can trigger other rules, and The Audit Log contains execution records and status for automation rules.

By default the actor on a rule is the Automation for AgileTrack service user means the automation engine runs actions under a service identity so executions are consistent and traceable to the automation system rather than to an individual human user.

Rules can trigger other rules explains that automations may be chained so that the outcome or events from one rule can start another rule and this enables building multi step workflows inside AgileTrack.

The Audit Log contains execution records and status for automation rules indicates that runs, results, and status information are recorded in the audit trail so administrators can review execution history and troubleshoot failures.

An automation can only be applied to one project is incorrect because automations are not necessarily limited to a single project and they can often be reused or applied across scopes depending on how AgileTrack is configured.

A failing rule always sends an email notification to the rule owner is incorrect because notification behavior depends on how alerts and notifications are configured and failures do not automatically produce an email unless an explicit notification action is set up.

Automations can publish events to Google Pub/Sub for downstream processing is incorrect because publishing to Pub/Sub is not a default capability of AgileTrack automations and such integrations require specific support or connectors that may not be available by default.

Read each statement carefully and decide true or false on its own merit. Pay attention to what happens by default and what requires explicit configuration.

The correct option is The subtask will be treated as a scope change and it will be shown in the burndown chart.

Because the Scrum board has Remaining estimate and Time spent enabled, adding a subtask to an issue that is already in the active sprint increases the sprint’s total remaining estimate when the subtask has an estimate. This increase is treated as a sprint scope change and the burndown chart will reflect the change in remaining work so the new subtask appears on the chart.

The subtask will be counted as a scope change but it will not update the burndown chart is incorrect because when remaining estimates are tracked the burndown chart updates to show the added remaining work. A scope change that affects remaining estimates will be visible on the chart.

The subtask will not change sprint scope but it will appear on the burndown chart is incorrect because a new subtask added to an issue in the active sprint does change the sprint scope if it carries remaining estimate. It cannot appear on the burndown without affecting the tracked remaining work.

The subtask will not alter sprint scope and it will not be reflected in the burndown chart is incorrect because adding a subtask with an estimate during an active sprint alters the sprint scope and the burndown chart will reflect that added remaining work.

When a question states that Remaining estimate or time tracking is enabled, assume that adding tasks with estimates will change sprint scope and appear on the burndown.

The correct answer is Visualize plan and monitor progress for multiple agile teams up to the program level.

This capability is delivered by Advanced Roadmaps in Jira Software Cloud Premium and it is designed to give a combined view of work across multiple teams. Advanced Roadmaps lets product owners roll up estimates and progress, show dependencies between teams, and plan at the program level so coordinated delivery can be monitored.

Export plans into Excel XML or PDF formats is incorrect because exporting in that specific Excel XML format is not a core Advanced Roadmaps capability and exports are generally handled via CSV or browser print options rather than a dedicated Excel XML export feature.

Jira Align is incorrect because it is a separate Atlassian product for enterprise level agile planning and it is not an Advanced Roadmaps feature included in Jira Software Cloud Premium.

Provide reporting at levels from single teams through the entire enterprise is incorrect because Advanced Roadmaps targets team to program and some portfolio level planning and it does not claim full enterprise wide reporting across every organizational layer in the way that a dedicated enterprise product like Jira Align does.

When you see phrasing about program level or coordinating multiple teams think of Advanced Roadmaps and treat full enterprise scale reporting as a cue for a separate enterprise product.

The correct answer is Team managed project issues will appear on the company managed Kanban board and permitted users can transition them between statuses.

A company managed board displays the issues that match its board filter and it can include issues from both company managed and team managed projects when the filter selects them. The Team managed project issues will appear on the company managed Kanban board and permitted users can transition them between statuses option is correct because showing issues and allowing actions is driven by the filter and by the users permissions in each project.

Team managed project issues will appear on the company managed Kanban board but they cannot be moved between statuses from that board is incorrect. Team managed issues can be transitioned from a company managed board if the board shows those issues and the user has the required project permissions and the workflow defines the transition.

No issues will be shown on the company managed Kanban board because the filter spans multiple project types is incorrect. Filters can span many projects and a company managed board will display the filter results regardless of project type as long as the user can see the issues.

Team managed project issues will be excluded and only company managed project issues will be visible on the board is incorrect. A board includes whatever the filter returns and it does not automatically exclude team managed project issues solely because of project type.

When answering these questions check the filter scope and the relevant project permissions because boards show filter results and actions depend on user rights rather than on project type alone.

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

Restrict who can transition issues by referring to a group custom field and Modify the set of “Resolution” values for the project are not supported by a team managed project in Jira Cloud.

Restrict who can transition issues by referring to a group custom field is not available because team managed projects use simplified, project scoped configuration and they do not support workflow conditions that depend on global group custom fields. Limiting transitions by group normally requires a company managed workflow or global custom field plus administrator level configuration which you cannot create inside a team managed project.

Modify the set of “Resolution” values for the project is not available because resolution values are a global Jira configuration that only Jira administrators can change. The resolution list is managed in global administration and cannot be customized per team managed project.

Enable release and milestone tracking is incorrect because team managed projects do support release and milestone tracking through the project releases and roadmap features that teams can enable at the project level.

Create cascading select fields where one dropdown depends on another is incorrect because team managed projects provide configurable custom fields and support dependent dropdown behavior such as cascading selects within the project.

Default a Timestamp field to the current date and time is incorrect because team managed projects support date and time custom fields and you can set default values including the current date and time for those fields at the project level.

Focus on whether a feature is global and requires Jira administrator rights or is project level and configurable by the team. Global settings are the ones most likely to be unsupported in team managed projects.

Team-managed Kanban project is correct because it allows project members to control their own permissions and it supports flexible timing for when tasks are completed.

Team-managed projects are designed to give teams autonomy over project settings and permissions so people on the project can adjust roles and access without waiting for a central administrator to change them.

Kanban boards use a continuous flow model rather than fixed length sprints so work items can be completed whenever the team is ready and timing can remain flexible.

Company-managed Scrum project is incorrect because Scrum emphasizes fixed length sprints and company managed projects use centralized permission schemes so individual project members cannot fully control their own permissions.

Team-managed workflow project is incorrect because Jira does not define a standard project type called workflow project and that name does not match the available team managed project templates.

Company-managed Kanban project is incorrect because company managed projects keep permissions under centralized control even though Kanban supports flexible timing, so project members would not be able to manage their own permissions.

When a question asks for member controlled permissions and flexible timing think team-managed together with Kanban.

The correct options are Board administrator and Project administrator for the project where the board is located.

Board administrator is correct because the board administrator role grants explicit permissions to change board configuration such as columns, filters, swimlanes, and card layout. These settings are controlled at the board level and the board administrator is the role intended to manage them.

Project administrator for the project where the board is located is correct because project administrators can administer boards that are tied to their project for company managed boards. Project administrators therefore have the ability to change board configuration for boards associated with their project without needing site wide privileges.

Site administrator is incorrect because site administrators manage the overall site settings but they are not automatically granted board configuration rights for company managed boards unless they are separately made a board administrator or project administrator.

Project lead for the project where the board is located is incorrect because being a project lead does not automatically confer project administrator permissions and the lead role alone does not guarantee the ability to change board settings.

Board owner is incorrect because Jira manages board configuration through the board administrator role and there is no distinct permission named board owner that independently controls board configuration.

When you encounter similar questions look for roles that explicitly include the word administrator. Think about whether the permission is granted at the board level or the project level and choose roles that match that scope.

The correct answers are Assign group membership when members must perform bulk edits across many issues, Use groups to grant global system permissions across the Jira site, Create groups when the same set of users will collaborate across several projects, and Use groups when overall membership should be controlled by a site administrator.

Assign group membership when members must perform bulk edits across many issues is correct because groups let you grant the same permissions to many users at once and simplify bulk operations across projects and issues. Using a group reduces administrative overhead when many people need identical capabilities for wide ranging changes.

Use groups to grant global system permissions across the Jira site is correct because global permissions are managed at the site level and groups provide a single place to assign those permissions so they apply consistently across all projects. This is the appropriate mechanism for site wide capabilities that are not tied to a single project.

Create groups when the same set of users will collaborate across several projects is correct because groups represent a stable collection of users that can be reused in multiple projects. Creating a group avoids repeated assignments and keeps membership consistent across projects.

Use groups when overall membership should be controlled by a site administrator is correct because groups are typically managed by site admins and they allow centralized control of who is inside the group. This is useful when membership decisions must be handled by administrators rather than by individual project leads.

Team members need the ‘Work On Issues’ permission to record time spent is incorrect because the question is about when to use groups rather than about specific permissions. Time tracking depends on the project permission scheme and that permission can be granted via roles or groups as needed so creating a group solely for logging work is not a typical reason to prefer groups.

Allow a project administrator to directly add or remove users from a group is incorrect because project administrators normally cannot manage global groups. Group membership is managed at the site administration level so groups are not the right choice when you want project administrators to control membership directly.

Focus on whether the need is site wide or cross project and who must control membership. If permissions must apply across projects or be managed by site admins then groups are appropriate. If control must be flexible per project then consider project roles.

The correct answer is status was “Done” and status != Done.

status was “Done” and status != Done returns issues that were at some point in the Done status and that are not in Done right now. status was “Done” uses the history operator to match past states and status != Done ensures the current status differs from Done so the filter yields reopened issues for daily notifications.

status changed from “Done” to “Open” OR “In progress” OR “Pending review” is not correct because the clause is not valid JQL as written and it mixes logical operators in a way that would not reliably capture all reopened issues or enforce the current status is different from Done.

status in (“Open”, “In progress”, “Pending review”) is not correct because it only checks the current status and does not look at the issue history. That means it will include issues that were never in Done and it will miss the requirement to detect issues that were previously Done.

status changed from “Done” is not correct because it finds any transition out of Done but it does not require the issue to currently be outside Done. An issue could have been reopened and later moved back to Done and this query would still match it.

When you need to find reopened issues combine a history check with a current state check. Use was to look at past statuses and use a current comparison like != to exclude the closed state.

The correct answer is One board. A single board can be filtered to show only the issues for a given team so each feature team can produce a Cumulative Flow Diagram that reflects only its work.

Components in the project can mark functional areas and the board supports filtering by component or by saved filters. The Cumulative Flow Diagram on a board reflects the board’s filters so you can view a CFD for any individual team without creating a separate board for each team.

Six boards is incorrect because creating one board per team is unnecessary when board filters and component queries provide the required isolation of issues.

Four boards is incorrect because it still suggests multiple boards are required and it does not meet the minimum since one board already satisfies the filtering and CFD requirement.

Twelve boards is incorrect because having two boards per team is redundant and it does not represent the minimum number needed to achieve the requested per‑team CFDs.

When a question asks for a minimum number think about whether filtering or permissions can satisfy the requirement. Use components or saved filters on a single board to get per‑team reports instead of creating extra boards.

Archived releases are not selectable in either the “Fix Versions” dropdown or the “Affects Versions” dropdown.

This is because archived releases are hidden from the version pickers so they cannot be chosen when creating or editing issues. Existing issues that already reference an archived version will still display that value but the archived item will not be available as a selectable option for new changes.

Archived releases remain selectable in both the “Fix Versions” dropdown and the “Affects Versions” dropdown is incorrect because archiving removes versions from the picklists and prevents new selections.

Archived releases are selectable only in the “Fix Versions” dropdown and not in the “Affects Versions” dropdown is incorrect because archiving affects visibility in both pickers and does not leave one picker selectable while hiding the other.

Archived releases are selectable only in the “Affects Versions” dropdown and not in the “Fix Versions” dropdown is incorrect for the same reason because archived versions are removed from both dropdowns and are not available for selection in either field.

When a question asks about the effect of archiving think about visibility for new selections. Archived usually means removed from pickers and not selectable for new issues, so choose answers that deny new selection.

Create a single automation that listens for multiple issue events including “Issue Updated” “Issue Assigned” and “Issue Transitioned” applies a JQL condition priority = Critical and sends a Slack notification is the correct choice.

The single automation that listens for multiple issue events is efficient because Jira Automation supports combining multiple issue events in one rule and you can use a JQL condition such as priority = Critical to ensure only critical issues trigger the action. An event driven rule sends notifications immediately when an assignment, transition or update occurs and the Slack action delivers the alert to the team without the delay or overhead of separate rules.

Configure three separate automation rules where one uses the “Issue Assigned” trigger the next uses the “Issue Transitioned” trigger and the third uses the “Issue Updated” trigger with a JQL condition priority = Critical and a Slack message action is not ideal because it creates extra maintenance work and it increases the risk of duplicate notifications when more than one event happens in quick succession.

Implement a single scheduled automation that runs every five minutes queries for recently changed issues with priority = Critical and posts a message to Slack is incorrect because scheduled polling introduces delays and can miss the immediacy of event driven notifications and it can also complicate de-duplication when the same issue changes multiple times between runs.

Create two automation rules where the first uses the “Issue Assigned” trigger and the second uses the “Issue Updated” trigger and both check priority = Critical before sending a Slack message is incomplete because it omits the “Issue Transitioned” event and so it would not notify on state changes that are important for releases.

When deciding choose event-driven automations with a narrow JQL condition to limit scope and test rules to avoid duplicate Slack messages.

The correct options are Sprint health gadget, Sprint report, and Control chart.

The Sprint report is time aware and shows completed and incomplete work by day for a sprint. It uses the board’s configured working days when computing sprint durations and daily breakdowns so the report reflects only the board’s working days.

The Sprint health gadget surfaces sprint progress and short term forecasts and it relies on the board’s working days for its time based calculations. That means the gadget’s view of daily progress and day based indicators follow the working days configuration.

The Control chart calculates cycle time and lead time and plots those values across business days. It honors the board’s working days so averages and day based trends exclude non working days defined by the board.

Cumulative flow diagram is incorrect because it displays counts of issues in each status over time and focuses on inventory levels rather than time based business day calculations, so it does not rely on the board’s working days.

Velocity chart is incorrect because it summarizes completed work per sprint using sprint boundaries rather than daily business day calculations, so the board’s working days setting does not change the velocity chart.

When a question mentions a board’s working days setting favor answers that perform time based calculations because those reports and gadgets are most likely to honor the configuration.

The correct permissions are Remove All Worklogs, Modify All Worklogs, and Log Work on Issues.

Remove All Worklogs is required because Marina must be able to delete worklogs created by other team members across the project and that permission specifically allows deletion of all users worklogs.

Modify All Worklogs is required because updating or correcting time entries for other people requires the ability to edit worklogs created by anyone rather than only the owner.

Log Work on Issues is required because adding or recording time against issues is controlled by the log work permission and Marina needs to create or add worklogs as part of updating entries.

Modify Personal Worklogs is incorrect because it only permits changes to the user’s own worklogs and does not allow editing other people’s worklogs.

Schedule Issues is incorrect because it relates to scheduling fields like start and due dates and it does not grant any capabilities to create, edit, or remove worklogs.

Remove Personal Worklogs is incorrect because it only allows a user to delete their own worklogs and not the worklogs of other team members which Marina needs to remove.

When a question asks about changing or deleting other users worklogs ask for permissions that include the word All rather than Personal.

Users assigned to issues will still be able to attach files to the issues they own is correct.

This happens because changing a team managed project to Limited removes broad browse access for users who are not added to the project but it does not remove issue level access for people who are explicitly involved with an issue. Assignees retain the ability to view and interact with the issues they are assigned to and that includes attaching files to those issues.

Reporters will not be able to see the project board is incorrect because reporters who are involved with issues are not broadly blocked from interacting with their issues. Limited access restricts general site users but does not automatically strip involved users of access to the issues they reported.

Reporters will no longer be able to view their own issues is incorrect because reporters keep issue level access to the issues they created and can still view and interact with those issues even after the project is set to Limited.

Assignees will be able to change issue ranking is incorrect because changing issue rank is governed by board and project permissions and is not granted automatically simply because a user is the assignee. Ranking typically requires explicit board or project privileges.

Assigned users will lose the ability to add comments on their assigned issues is incorrect because assignees retain the normal interaction rights for issues they are assigned to and that includes commenting.

When a question mentions project access think about the difference between project wide browse permissions and issue level participation. Limited blocks general browsing by non members but people involved in an issue usually keep the ability to view and act on that issue.

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

The correct answer is project in (“APOLLO”,”LUNA”) AND priority >= “High” AND assignee in membersOf(“alpha_squad”) AND due < now().

This query uses project in (“APOLLO”,”LUNA”) to include issues from either project in a single expression. It uses priority >= “High” to match High and any higher priority levels. It uses assignee in membersOf(“alpha_squad”) which correctly tests membership of the assignee against the group. It uses due < now() to find issues whose due date is before the current time and are therefore overdue.

project = “APOLLO” OR project = “LUNA” OR priority = “High” AND assignee = membersOf(“alpha_squad”) AND due < current() is wrong because the OR operators make the logic return issues that match any of those clauses rather than all of the required conditions. The clause also uses assignee = membersOf(“alpha_squad”) which is incorrect because membersOf returns a set and must be used with in. The function current() is not the correct JQL time function.

project in (“APOLLO”,”LUNA”) AND priority >= “High” AND assignee = membersOf(“alpha_squad”) AND due < “0” is wrong because it uses assignee = membersOf(“alpha_squad”) instead of assignee in membersOf(“alpha_squad”). It also uses due < “0” which is not a valid way to compare dates in JQL and will not return overdue issues.

project = “APOLLO” AND project = “LUNA” AND priority >= “High” AND assignee in membersOf(“alpha_squad”) AND due < now() is wrong because an issue cannot belong to both projects at the same time. Using AND between two project equals conditions excludes all issues. The rest of the query is valid but the project clause makes the whole expression return nothing.

When reading JQL watch boolean operators and function usage. Use in membersOf() for group membership and use now() for current time checks.

The correct answer is Change the board saved filter.

The board membership is defined by its saved filter and that filter uses JQL to select which issues appear on the board. If tasks older than six weeks are being excluded then the saved filter likely contains a date clause that limits results to a recent time window. Editing the board saved filter to remove or adjust that clause will allow all tasks to remain visible regardless of age.

Update quick filters is incorrect because quick filters only apply on top of the board view when a user toggles them. They do not permanently change which issues belong to the board and they will not cause automatic exclusion of issues by age.

Adjust the hide completed issues older than setting is incorrect because that setting only hides completed issues after a configured time period. It does not affect open or active tasks and therefore would not explain general disappearance of tasks older than six weeks.

Modify the board sub filter is incorrect because the sub filter is an additional restriction applied after the main saved filter and it is used for special exclusions. The primary set of issues is still controlled by the saved filter so the saved filter is the place to change to ensure all tasks remain on the board.

When issues are missing from a board check the saved filter first since it defines the board membership and often contains date or status clauses that remove older issues.

The correct answer is A board is allowed to have more than one board administrator.

This is correct because boards in Jira can have multiple administrators who share responsibility for configuring the board settings and board-specific features such as columns, quick filters, and card layout. Board administrators manage the board level configuration and they can be added or removed independently of project roles.

A Jira project can have multiple project leads is incorrect because a Jira project has a single project lead field and that lead is one user who is designated as the project lead for ownership and default responsibility.

A saved search filter can be owned by several users is incorrect because saved filters have a single owner and can be shared with groups or projects but ownership remains with one user.

The default assignee for issues can be either the project lead or the component lead is incorrect because default assignee choices are configured at the project level and may be set to the project lead or to be unassigned, while component leads provide a default assignee for issues assigned to that component only. The statement as written implies both apply universally which is not accurate.

Project administrators can create new global roles and assign members to them is incorrect because creating and managing project roles and global role definitions is an administrative action reserved for Jira administrators rather than project administrators.

When you see role and ownership questions focus on the exact scope of the role and whether the action is at the board, project, or global level. That distinction usually tells you who can perform the change.

The board quick filters and Status mapping to columns are correct.

The board quick filters can hide issues on the board even when the saved filter returns them in advanced issue search. Quick filters are ad hoc JQL filters that apply only to the board view and a filter left enabled will exclude matching issues from the board while they still appear in search results.

Status mapping to columns can also cause issues to be missing because if an issue’s status is not mapped to any column on the board then Jira will not display it on the board. Ensuring all expected statuses are mapped to columns makes those issues visible in the board view.

The board saved filter is not the cause because the question states that the saved filter returns all issues in advanced issue search, so the base filter is not excluding them.

Issue security level would prevent users from seeing issues in both search and board if they lack permission, so it is unlikely here since Maya can see the issues in advanced issue search.

“Hide completed issues older than” setting only affects resolved issues that are older than the chosen time window, so it would not hide open issues or issues with unmapped statuses that match the saved filter.

The board sub filter can restrict what the board shows in some setups but the symptoms described point to either a quick filter being applied in the board view or statuses not being mapped to columns, so the sub filter is not the primary cause here.

When a board shows fewer tickets than an equivalent search first check the quick filters active on the board and then verify the status to column mapping in Board settings.

The correct option is Adjust project permission scheme.

Adjust project permission scheme is correct because Jira grants edit and transition rights through a project permission scheme and the Edit Issues permission is controlled at that level. Maria can edit issues assigned to her because the current permission scheme likely grants those rights to the assignee role or a specific project role. Updating the project permission scheme or adding Maria to the appropriate project role or group will give her edit access to the other issues.

Modify global permissions is incorrect because global permissions control site wide administrative abilities and not the ability to edit individual issues in a specific project. Changing global permissions will not grant issue level Edit Issues rights for just this project.

Change issue security level is incorrect because issue security schemes control who can see or view an issue and not who can edit it. Altering the issue security level may affect visibility but it does not grant Edit Issues permission.

Contact Atlassian support is incorrect because this is a configuration task for a project admin or Jira administrator rather than a support case. Atlassian support will not change your project permission scheme for you as part of normal troubleshooting.

When a question is about who can edit or transition issues think about the project permission scheme and the Edit Issues permission and check project roles or groups before considering global settings.

The correct options are Subscription and Filters.

Filters are used to define and save the query that finds all blocker tickets across the project. You can create the JQL or basic search that matches blocker issues and then save it as a filter so the same consolidated list can be reused.

Subscription is the feature that schedules delivery of a saved filter by email on a regular cadence. Priya can subscribe the saved filter to run every Friday and send the compiled list to herself or to the team.

Automation is not the best choice here because automation rules are used to perform actions in response to events or on schedules and they are more suited to workflow changes or custom notifications rather than the built in filter subscription workflow for scheduled reports.

Notifications control who gets alerted for issue events and they do not produce a consolidated, scheduled list of filter results in an email.

Global Permission relates to user rights and access across Jira and it does not provide a way to compile and email a weekly list of issues.

Post Function runs during workflow transitions to update issues or trigger actions when an issue moves and it cannot be used to create a recurring, consolidated email report.

When you see a question about a scheduled report think of two steps. First create a saved filter that returns the issues you need. Then use the filter subscription to schedule the email delivery on the desired day.

The correct options are Iteration Burndown Chart, Burnup Chart, Velocity Report, and Iteration Summary Report.

These four reports are tied to sprint or iteration data and so they appear only on a Scrum board in an organization-managed project. Scrum boards define sprints and track completed work and the reports need that sprint context to produce meaningful metrics.

The Iteration Burndown Chart shows remaining work within a sprint and depends on sprint start and end dates and on sprint scope. Because it measures work remaining per iteration it is only available where sprints are defined, which is the Scrum board in an organization-managed project.

The Burnup Chart visualizes scope changes and work completed across a sprint or release and it requires sprint or version boundaries to show progress versus scope. That dependence on iteration or release context is why the Burnup Chart is available only on the Scrum board.

The Velocity Report summarizes the amount of work completed per sprint over recent iterations and it uses completed sprint data to calculate averages. That sprint focus makes the Velocity Report a Scrum board only report in organization-managed projects.

The Iteration Summary Report gives an overview of what was completed, moved, or carried over during a sprint and it explicitly reports on one sprint at a time. For that reason the Iteration Summary Report is available only on the Scrum board.

Control Chart is incorrect because it focuses on cycle time and throughput metrics and it is not limited to Scrum boards. The control chart can be used with other board types where cycle time data is relevant.

Cumulative Flow Diagram is incorrect because it shows work in each workflow state over time and it is commonly available across board types. It is not exclusive to Scrum boards and therefore it is not one of the reports that appear only on the Scrum board in an organization-managed project.

Focus on whether a report requires sprint or iteration data. If a report needs sprint context it is usually available only on a Scrum board in an organization-managed project.

The correct options are Merge versions and Delete version.

Using Merge versions Maya can move all issues from the old version into the target version and consolidate the two versions so the issues end up assigned to the desired release. This operation is intended to combine the contents of one version into another while removing the source version.

Using Delete version Maya can remove the unwanted version and choose where existing issues should be reassigned during the deletion process. The delete workflow offers the option to move issues to an existing version such as the target version before the source version is removed.

Release version is incorrect because that action only marks a version as released and does not move issues into another version or remove the version.

Archive version is incorrect because archiving hides the version to reduce clutter but does not reassign issues or merge them into another version.

Unrelease version is incorrect because it only changes the released status of a version and does not transfer issues to a different version.

When a question asks to remove a version and reassign its issues look for operations that explicitly move or merge issues such as merge or deleting with reassignment rather than actions that only change status or visibility.

The correct option is Swimlanes.

The Swimlanes feature groups issues into horizontal lanes so you can create a lane per project and keep every issue visible on the board. Swimlanes are configured to separate work by project or by JQL so they show all issues in their respective lanes rather than hiding them with additional filtering.

Board Sub Filter is incorrect because it further restricts which issues appear on the board and would hide issues rather than group them.

Issue Detail View is incorrect because it only shows details for a selected issue and does not change how issues are grouped on the board.

Quick Filters is incorrect because quick filters temporarily hide issues to narrow focus and they do not provide persistent grouping by project.

Hide Completed Issues is incorrect because that option removes completed work from view and so it will not keep every issue visible.

Board Filter is incorrect because the board filter determines the overall issue set shown and is used to limit issues across the board rather than to group issues by project.

When a question asks to show items grouped without removing any of them think grouping not filtering. Use swimlanes to separate work by project and use filters only when you need to reduce what is visible.

No additional action is required you can create team managed projects with the default site settings.

This is correct because Jira Software Cloud enables creation of team managed projects by default to promote team autonomy. Team managed projects are designed so that standard site users can create and manage them without requiring site administrator privileges or special global permissions.

Request membership in a site administration group | correct: false is incorrect because becoming a site administrator is not required to create team managed projects. Site administrator membership grants broad site control and is not needed for creating team managed projects under the default settings.

Request specific project permissions from an existing project administrator | correct: false is incorrect because project level permissions apply to actions within an existing project. Granting project permissions from a project administrator does not give a user the ability to create new team managed projects across the site.

Ask a site administrator to grant the Create team managed projects global permission | correct: false is incorrect because there is no separate global approval required for creating team managed projects in the default configuration. Administrators can change site level controls to restrict project creation, but by default users can create team managed projects without requesting a special global permission.

When a question refers to default configuration assume services behave as shipped unless the prompt indicates restrictions. For Jira focus on whether a permission is global or project level.

The correct answer is Team-managed projects only.

Team-managed projects in Jira Software allow multiple active sprints to run concurrently from the same backlog so different squads can run parallel sprints against shared work. This capability is part of the team-managed project model which gives teams more flexible sprint management for separate components or streams of work.

Neither team-managed nor company-managed projects support parallel sprints is incorrect because team-managed projects do support multiple active sprints and so the statement is false.

Company-managed projects only is incorrect because company-managed projects do not provide the same ability to run several active sprints from one backlog. Company-managed boards typically have a single active sprint at a time and require different workarounds to run parallel streams.

Both team-managed and company-managed projects is incorrect because the company-managed model does not support multiple concurrent active sprints the way team-managed projects do.

When answering sprint behavior questions check whether the project is team-managed or company-managed because their sprint capabilities differ and remembering this distinction will help you choose the correct option.

The correct option is Modify the board sub-filter. Using the board sub-filter lets Maya update the board specific JQL so that issues resolved more than two days ago are excluded automatically from the company managed Kanban board.

The board sub-filter is applied in addition to the board filter and runs dynamically so no manual cleanup is needed. Maya can add a simple JQL condition that shows unresolved issues and resolved issues within the last two days. A common example is resolutiondate >= -2d OR resolution is EMPTY which will keep recent resolved items on the board and hide items resolved earlier than two days.

Adjust the board filter is incorrect because changing the main board filter affects the global set of issues returned by the board and can have wider impact. The main filter is not the lightweight way to hide only older resolved items on a board without affecting other uses of the filter.

Use the Hide completed issues older than setting is incorrect because that option is not the standard, low maintenance control for company managed Kanban boards and may apply only to specific views or team managed boards. It is not the general board level JQL control that reliably filters resolved issues by age on company managed boards.

Create a board automation rule to transition resolved issues off the board is incorrect because automation would require additional rules management and can change issue statuses or flows. That approach adds ongoing maintenance and possible side effects, while the board sub-filter accomplishes the requirement through JQL without changing issue history or workflow.

When a question asks for the least ongoing maintenance prefer configuration that runs automatically. Use a board sub-filter with relative JQL dates to hide older resolved issues instead of changing status or adding automation.

The correct answer is Cumulative flow diagram.

A Cumulative flow diagram is a stacked area chart that shows how many work items were in each workflow state over time. The diagram makes it easy to see the size of each state and how work flows through the process over a two week period or any other timeframe.

Burndown chart is incorrect because a burndown chart tracks remaining work over time for a sprint or iteration and it does not show the count of items in each workflow state.

Velocity chart is incorrect because velocity shows how much work a team completes per sprint and it does not break work down by workflow state over time.

Control chart is incorrect because a control chart highlights cycle time or lead time variation for individual items and it does not display stacked counts of items in each state across a time range.

Sprint report is incorrect because a sprint report summarizes committed versus completed work for a sprint and it does not provide a continuous, state by state view of work items across a two week period.

When a question asks about the number of items in each workflow state over time look for a stacked area or cumulative flow visualization as that is the standard way to represent state counts across a timeframe.

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

The correct option is Site administrator.

Site administrator can add and manage users across the organization and grant access to company applications and billing features. This role controls site level user management and billing settings which matches Alyssa’s duties to add a new Jira account and manage billing access.

Jira Software user is incorrect because this role only provides regular product access for using Jira Software and it does not include permissions to manage other users or billing.

Jira administrator is incorrect because that role focuses on product configuration and global settings within Jira rather than organization wide user and billing management. A Jira administrator may manage schemes and permissions but they do not necessarily control billing or product access across the entire site.

Project administrator is incorrect because it grants permissions only at the project level. Project admins can change project settings and manage project roles but they cannot add users across the site or manage billing.

Focus on keywords like adding users and managing billing or company application access. Choose the role with site level permissions rather than a project or product specific role.

The correct option is Swimlanes.

Swimlanes let you group issues into horizontal lanes on a board so you can place platform related tickets in the top lane and have other tickets appear in lanes beneath. You configure Swimlanes in the board settings and you can base lanes on queries, epics, stories, or other fields to match your squad workflow.

Quick Filters create temporary filters that show or hide cards on a board and they do not create persistent horizontal lanes for arranging issues.

Board Sub Filter is used to further restrict which issues are visible on a board and it does not create separate horizontal lanes to organize work into rows.

Issue Detail View shows the information for a single issue when you open it and it does not affect the board layout or lane organization.

Hide Completed Issues controls visibility of finished work and can remove done issues from view but it does not arrange issues into top and bottom lanes.

Board Filter defines which issues are included on the board as a whole and it does not split the board into horizontal swimlanes.

When a question mentions arranging work into horizontal rows think Swimlanes and check the board settings for lane configuration.

Workflow post functions and Automation rule are correct.

Workflow post functions run during a workflow transition and they can update issue fields as part of that transition. If a post function on the transition into the QA status was configured to assign the issue to Priya then every issue that moves into QA will be reassigned automatically.

Automation rule can trigger on events such as a status change and then perform actions like assigning an issue. A rule scoped to the project or to the instance that watches for the QA status and assigns Priya will produce the observed behavior.

Components usually control component leads and can influence assignment at creation when the component lead is chosen. They do not by themselves reassign issues when the status changes to QA unless combined with an automation or workflow step.

Project default assignee is a fallback for newly created issues or for unassigned issues. It does not trigger reassignment on a status transition by itself.

Global automation rule is misleading as listed here. Global automation rules do exist but the general category of Automation rule is the relevant cause and the specific phrasing in this option is not the intended answer.

Workflow validators run checks before a transition to decide if the transition is allowed. Validators do not change issue fields or assign users so they cannot cause the reassignment on their own.

When you see automatic assignment check both the workflow transition and any automation rules. Look for post functions on the transition and for project or global automation rules that trigger on status changes.

The correct options are Issue Type Scheme, Workflow Scheme and Screen Scheme.

Issue Type Scheme, Workflow Scheme and Screen Scheme are commonly provisioned as project‑specific artifacts when a company‑managed project is created from a template. These schemes define the issue kinds the project uses the steps and transitions for those issues and the fields and layouts that appear when users view and edit issues. Creating dedicated copies allows the new project to evolve its types workflows and screens without impacting other projects that may share global schemes.

Field Configuration Scheme is typically a shared or global scheme that controls field behaviors across multiple projects and is not usually created uniquely for each new company‑managed project.

Notification Scheme is generally shared and managed at the site or project level so that multiple projects can reuse the same notification behavior instead of each project getting a unique scheme by default.

Issue Security Scheme is often defined centrally and can be applied to multiple projects to maintain consistent security levels so it is not usually unique to a freshly created company‑managed project.

Priority Scheme reflects global priority values and is managed at the instance level so new projects commonly reference the existing priority configuration rather than receiving a private copy.

When a question asks which schemes are project unique think about schemes that affect issue behavior and layout. Workflows, Issue type schemes and screen schemes are the most likely to be created as dedicated copies for company‑managed projects.

Clearing a parent issue from the board also clears its subtasks regardless of each subtask’s status and You can create multiple issues at once by pasting several lines into the create box on the board are correct.

The first correct behavior means that on team-managed boards the board action that clears or removes a parent issue will also clear its subtasks on the board view even if those subtasks are in different statuses. This is a board level behavior in team-managed projects and it applies regardless of each subtask’s individual status.

The second correct behavior refers to the board create box which accepts multiple lines of text and creates one issue per line. This allows quick bulk creation directly from the board by pasting several lines into the create box and submitting them.

The issue navigator cannot be turned on or used in team-managed projects is incorrect because you can use the global issue search and issue navigator to find and filter issues from team-managed projects. The issue navigator remains available in Jira Cloud even though some project settings differ between project types.

You can set a project wide default issue security level in a team-managed project is incorrect because issue security schemes and project wide default security levels are features of company managed projects. Team-managed projects do not support configuring issue security at the project scheme level.

In a scrum template team-managed project you can create issues directly from any board column even when sprints are active is incorrect because when sprints are active the board behavior for creating and placing new issues is restricted. New issues typically need to be added in ways that align with the active sprint workflow and you cannot freely create them into any column while the sprint is running.

When comparing options focus on differences between team-managed and company-managed projects because configuration capabilities like issue security and advanced schemes are often the deciding factor.

Board sub filter is the correct option.

The board applies its saved filter together with a board sub filter to decide which issues appear on the Kanban board. If the sub-filter further restricts results such as excluding closed issues or certain projects then tickets that show in the issue navigator can be omitted from the board. As a board administrator Marisol can open board settings under General to review or edit the Board sub filter to confirm whether it is excluding those tickets.

Quick filter is incorrect because quick filters are toggles a user applies on the board to temporarily narrow visible issues and they are not applied automatically to the saved filter that the issue navigator uses.

Swimlanes is incorrect because swimlanes only change how issues are grouped visually on the board and they do not remove issues from view. Missing tickets would still appear in a swimlane or an unassigned lane if they matched the board filters.

Issue level security can hide issues from specific users based on security schemes and it can cause missing issues for those users. However Marisol is the board administrator and if she can see the tickets in the issue navigator it is less likely that issue security is the cause. The board sub filter is the more probable setting that would exclude issues from the board while they still appear in the navigator.

When the issue navigator shows issues that the board does not check the board settings first and review the board sub filter because it can further restrict which issues appear on the board.

Project roles is the correct option for Maya to add to the project permission scheme.

Project roles provide a per project, role based way to grant permissions that maps responsibilities to people or groups. You can assign users or groups to a role and then give that role the appropriate permissions in the permission scheme which makes it simple to change who can perform actions as the team changes.

Individual users is incorrect because granting permissions directly to single users does not scale and forces administrators to update permissions for each person when membership changes. Permission schemes are meant to use roles or groups rather than binding permissions to individual accounts.

Groups is incorrect because groups are global and do not provide the same per project mapping of responsibilities. Groups can be used but Project roles are preferable when you need flexible, per project assignment of who can perform actions.

When a question asks about controlling actions inside a project think about constructs that are scoped to the project and support flexible assignment and use roles when you need per project control.

The correct option is Board sub-filter.

Board sub-filter adds an extra JQL clause that automatically limits which issues are shown on the Kanban board without changing the board’s primary filter. This means Alex can restrict the board to the finance component and the filtering will happen automatically while the Cumulative Flow Diagram and other reports still use the main board filter and remain unchanged.

Quick Filters are clickable buttons that users must activate to change the board view, so they do not provide an automatic, always-on filter as required.

Swimlanes organize and group issues visually on the board rather than excluding issues, so they will not limit the board to only finance component issues by themselves.

Board Filter is the main JQL that defines which issues belong to the board and changing it would also change reports and the Cumulative Flow Diagram, which Alex needs to keep unchanged.

Issue Detail View only shows information about a selected issue and does not control which issues are visible on the board automatically.

Hide completed issues affects only issues in completed statuses and does not filter issues by component, so it will not meet Alex’s requirement.

Remember that a board sub-filter changes the board view without altering report data. Check whether a change affects the main board filter before updating it.

The correct answer is Control chart.

A Control chart visualizes cycle time and lead time and shows the distribution of how long issues take to move through the workflow. It is designed to show how long a single issue or a group of issues has been sitting in a given status and to highlight variation and outliers that indicate delays.

The Velocity chart reports completed work per sprint and helps with forecasting future sprint capacity. It does not measure how long issues sit in a particular status.

The Issue age report shows how long issues have been open or unresolved since creation or since they entered a board. It does not provide the per-status time distribution and cycle time detail that a control chart provides.

The Cumulative flow diagram shows the count of issues in each status over time to reveal bottlenecks and workflow stability. It does not display the time each issue spends in a given status or the distribution of those times.

The Burndown chart tracks remaining work in a sprint or release and is focused on scope and progress rather than the amount of time issues spend in specific statuses.

When you see phrases like how long or time in status look for reports about cycle time and distribution and think of the Control chart.

The correct answers are Labels can contain inconsistent values, Label values are not dependable for filtering and searching issues, and The Bulk Change tool can find and remove label values across many issues.

The option Labels can contain inconsistent values is correct because labels are typically free form and depend on users to create and apply them. Users can use different spellings, casing, or naming conventions and that leads to inconsistent values across the issue set.

The option Label values are not dependable for filtering and searching issues is correct because inconsistent, user defined labels reduce the reliability of exact matches when you filter or search. Labels are useful for ad hoc grouping but they do not replace structured fields when you need precise or repeatable queries.

The option The Bulk Change tool can find and remove label values across many issues is correct because many issue trackers include bulk edit or bulk change features that let you search for a label value and then remove or replace it on multiple issues at once. That capability is the standard way to clean up inconsistent label usage.

Labels can be included in reports is incorrect because inclusion in reports depends on the reporting tool and how it is configured. Labels are not always surfaced or aggregated by default and so they cannot be assumed to be present in every report.

Labels are only accessible at the project level is incorrect because labels are attached to issues and most systems allow you to view and search labels across different scopes. Accessibility depends on the tracker implementation and permissions but labels are not inherently limited to a single project view.

Labels are governed by a central taxonomy that enforces allowed values is incorrect because most trackers treat labels as free form tags and do not enforce a central controlled vocabulary unless an explicit taxonomy or governance feature has been added by the administrators.

When you see questions about labels think about whether they are free form or centrally enforced and look for any mention of a bulk change or bulk edit capability which usually indicates label cleanup is possible.

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

The correct options are Board saved filter, Project permissions, Board quick filters, and Issue security levels.

Board saved filter controls which issues are included on the board by applying the board’s underlying JQL. If the saved filter excludes certain projects, issue types, or specific criteria then those issues will not show up on the Active sprints board or in the Backlog even though their statuses are mapped to columns.

Project permissions determine who can browse and view issues in a project. If a user or the board context does not have the Browse Projects permission for a given project then those project issues will be invisible on the board and in the backlog regardless of status mapping.

Board quick filters are applied interactively on top of the board filter when a user enables them. An active quick filter can hide issues from both the Active sprints view and the Backlog until the filter is cleared, so a visible quick filter is a common cause of missing issues.

Issue security levels restrict visibility at the individual issue level. If an issue is assigned a security level that the viewer is not part of then that issue will not appear on the board or in the backlog even though it exists and has a mapped status.

Hide completed issues older than setting only affects how long resolved or completed issues remain visible after they are done. It does not hide active or backlog items and would not explain missing non completed issues.

Board sub filters are not the primary mechanism for items disappearing from a Scrum board that spans multiple projects. The saved filter and quick filters are the typical culprits for global exclusions.

Global permissions govern site wide capabilities and administration rights. They do not hide specific issues from a board in the way a saved filter, project permission or issue security level would.

Unmapped statuses would hide issues if statuses were not mapped to board columns, but Jordan has mapped every workflow status to a column so unmapped statuses cannot be the cause in this scenario.

When troubleshooting missing issues start by checking the board’s saved filter and any active quick filters. Then verify project permissions and issue security levels for the affected issues.

The correct answers are Components, Versions, and Project avatar.

When you create a company managed project using the shared configuration option you inherit the shared schemes such as workflows screens permission schemes and notification schemes but you still need to set project specific metadata manually. That is why Components and Versions must be created or adjusted for the new project and why you must upload or choose a Project avatar for the project.

Components are the logical parts of the project used to group issues and assign ownership. They are stored at the project level so they are not supplied by the shared scheme and must be defined after project creation.

Versions represent milestones or releases for that specific project. Versions are maintained per project so you need to add or edit them to reflect the new project timeline.

Project avatar is a visual property for that project and it is not part of the shared configuration schemes. You must set the avatar to identify the project in lists and boards.

Priority scheme is incorrect because priorities are usually defined globally or through a shared scheme and will be inherited from the shared configuration rather than needing per project setup.

Notification scheme is incorrect because notification behavior is controlled by the shared notification scheme that you chose and it does not require per project manual setup when using a shared configuration.

Issue status is incorrect because statuses are part of the workflow and workflow schemes which are shared when you use the shared configuration. They are therefore inherited rather than created per project.

Remember that shared configuration gives you schemes to inherit while items that describe the project itself remain project specific. Check for components versions and the avatar after creating a project from a shared configuration.