Atlassian ACP-620 Jira Projects Certification Sample Questions

The correct options are A Scrum team can configure a different card layout for the backlog and for the active sprint and Card layout changes apply only to the board where they are configured.

A Scrum team can configure a different card layout for the backlog and for the active sprint is correct because many Agile boards provide separate layout settings for the backlog view and for the active sprint or board view. The backlog layout typically emphasizes fields useful for refinement and prioritization while the active sprint layout shows fields that support day to day tracking.

Card layout changes apply only to the board where they are configured is correct because card layout is a board level setting and changes do not automatically propagate to other boards even when those boards reference the same project or filter.

Users can add up to 6 custom fields to display on cards is incorrect because there is no single universal rule that limits card fields to six. The number of fields you can display and how they appear depends on the product UI and configuration and limits can vary by version or plan.

Only board owners are permitted to edit card layouts is incorrect because editing card layouts is governed by board administration or project permissions and is not restricted to a single owner role. Users with board admin or appropriate project permissions can update the layout.

The correct answers are archivedVersions() and mergedVersions().

Neither archivedVersions() nor mergedVersions() is part of the core JQL function set provided by Jira. Those names are typically seen only when a plugin or custom extension adds functions and they do not appear in the standard built in functions list. The common built in functions for version queries include releasedVersions(), unreleasedVersions(), and latestReleasedVersion().

releasedVersions() is a standard JQL function that returns versions marked as released for a project or set of projects. Because it is a built in function it is not a correct choice for nonstandard names.

unreleasedVersions() is a standard JQL function that returns versions that are not yet released. It is part of the default JQL functions so it is not one of the nonstandard options.

latestReleasedVersion() is a standard JQL function that returns the most recent released version for a project. It is included in core JQL and therefore it is not among the names that are not part of the standard set.

The correct options are Permission to browse projects, Schedule issues permission and Edit issues permission.

Permission to browse projects is required because a user must be able to see the project and its backlog before they can move issues into a sprint. Without browse access the board and backlog are not visible and the action cannot be performed.

Schedule issues permission controls changes to scheduling and sprint related fields and it is needed when assigning an issue to a sprint or changing its sprint membership. Moving an issue from the backlog into the current sprint updates those scheduling fields.

Edit issues permission is needed because moving an issue into a sprint modifies the issue record and the change must be saved. Edit rights allow the necessary field updates to be applied.

Manage sprints permission is typically used to start, complete, or manage sprint settings and not to grant the minimal project ability to move individual backlog items into a sprint. It is not the required project permission for this action.

View read only workflow permission only provides visibility into the workflow and does not allow changing issue fields or assigning issues to sprints, so it does not enable moving items into the current sprint.

Resolve issues permission permits marking issues as resolved or transitioning to resolution related statuses and does not grant the ability to edit scheduling or sprint assignment required to move issues into a sprint.

The correct options are Project category assignment, Project web address, and Project summary and description.

An administrator can change Project category assignment because categories are project metadata used to organize projects and they can be edited in the project details settings after the project exists.

An administrator can change Project web address because the project URL or web address is part of the project details and can be updated by an admin if a different link or display address is needed.

An administrator can change Project summary and description because those are descriptive fields stored on the project record and are intended to be edited as the project evolves.

Project template is incorrect because the template is chosen when a project is created and it is not an optional metadata field that an admin can simply toggle in the project details. Changing a template usually requires migration or recreating the project and is therefore not treated as an editable optional setting.

She will be able to add the new column and the existing status will be automatically associated with it.

In boards that use the simplified workflow Jira maps columns to statuses by name. When Sofia adds a column whose name matches a status that already exists in Jira the board will automatically associate that existing status with the new column so no extra status creation step is needed.

Project administrators can manage board columns so Sofia has the ability to add the column directly. The simplified workflow behavior makes the matching automatic even if the status was not previously used by the project.

She can add the column but it will not have any status mapped to it is incorrect because a matching status will be mapped automatically when the column name matches an existing status.

She must rename the column because it duplicates an existing status name is incorrect because duplicate names are resolved by mapping the existing status to the column rather than forcing a rename.

She must create the status first using the “add status” button before adding the column is incorrect because the status already exists in Jira and does not need to be recreated for the board to use it.

A scheduled JQL search is returning more than 1000 issues is correct. This specific condition is a common trigger for Jira automation throttling because scheduled rules that scan very large result sets are deliberately limited to protect platform performance.

When a scheduled rule runs a JQL and that query returns more than the documented threshold it can be throttled or partially executed to avoid overloading the automation engine. The automation subsystem imposes limits on how many issues a scheduled evaluation will process in one run and exceeding that practical ceiling will cause the rule to be slowed or skipped.

Monthly execution cap for single-project automation is not the most likely cause in this scenario because a monthly cap would affect aggregate executions over time and would not specifically correlate with daily scheduled runs returning very large issue sets. Monthly quotas also vary by plan and are usually surfaced differently than immediate throttling of a scheduled rule.

Rule making an excessive number of webhook calls is also not the best explanation because excessive webhooks would lead to outbound rate limit or delivery failures and different error symptoms. Webhook volume can cause issues but it does not directly explain why a scheduled JQL query would be throttled when it returns more than 1000 issues.

Control chart is the report not available in a team-managed Jira Software project.

Team-managed projects provide a smaller set of built in agile reports and do not include the Control chart that is available in company-managed projects. The control chart relies on board and issue configuration that team-managed projects do not expose in the same way.

Team-managed projects do include common sprint and flow reports such as Burnup report, Velocity report, Cumulative flow diagram, and Sprint burndown chart which cover most sprint and workflow tracking needs.

Burnup report is available because team-managed boards can track completed work against scope and provide a burnup visualization in the project reports.

Velocity report is available for scrum style, sprint based work so teams can review completed story points per sprint in a team-managed project.

Cumulative flow diagram is available to show work in progress across statuses and it is provided in team-managed board reporting to help teams spot bottlenecks.

Sprint burndown chart is available for sprint tracking and it is included in team-managed scrum project reports so teams can monitor remaining work during a sprint.

The correct options are Issue types, JQL queries, Priorities, and Assignees.

You can assign card colors by Issue types so that Stories, Bugs, Tasks, and other types each display a distinct color on a company managed board. This helps teams quickly distinguish the nature of work at a glance.

Boards support coloring by JQL queries which provides the greatest flexibility because you can target combinations of fields, values, and conditions to create complex color rules for cards.

Coloring by Priorities is supported so you can make high priority issues visually prominent and use different colors for lower priorities to aid triage and focus.

Boards also allow colors by Assignees so that each person can be associated with a color and ownership is easy to scan across the board.

Labels cannot be used to assign card colors on a company managed board. Labels are not offered as a native card color rule in the board settings, although you can achieve similar behavior by creating equivalent JQL queries that match issues with particular labels.

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.

The correct answer is Limited project access.

Limited project access is a project access level that enforces membership based controls so only specific users are granted the ability to create issues while keeping visibility restricted to project members and administrators. At the same time it allows site users who can view an issue to attach files to that issue which matches the requirement that every site user can attach files to issues they can view and that story issues are visible only to Members and Administrators.

Issue security scheme controls who can see an individual issue by assigning security levels to issues but it does not by itself establish the project wide membership and creation rules or the simple site user attachment behavior described in the question.

Permission scheme defines detailed permissions such as Create Issues and Attach Files and it can be used to craft similar behaviors but it is a more granular mechanism. The scenario in the question refers to the preset membership and visibility model provided by the access level rather than a custom permission scheme.

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.

The correct options are Board filter returns issues from multiple projects and Board filter excludes the Epic issue type.

If the Board filter returns issues from multiple projects the roadmap cannot present a coherent single project timeline and the roadmap view is often not available or will not show items. Roadmaps are tied to a project or to a board scope that supports epic timelines so a cross project filter can prevent the roadmap from populating for that board.

If the Board filter excludes the Epic issue type there will be no epic-level items for the roadmap to display. Roadmaps rely on Epic issues to render bars and timelines so excluding the Epic issue type from the board filter will make the roadmap empty or hide roadmap functionality.

Roadmaps feature is disabled for the site is unlikely because a site wide disable would affect all users and projects not only one board. The question indicates the board admin can view and edit issues so a global feature disable is not the most probable cause.

A quick filter is active is not the cause because quick filters are applied interactively by users and they only change the board issue view. Quick filters do not change the underlying board filter or the issue types that the board includes so they would not prevent the roadmap from displaying epics.

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.

The correct answers are Board filter and Report filter.

A Board filter defines which issues belong to the board and therefore controls the dataset available to the Kanban control chart. If the board filter excludes issues then those issues will not be shown on the control chart even though they exist in the project.

A Report filter applies directly to the chart or report and can reduce the results that are plotted. When a report filter is set it will omit issues that do not match the filter criteria even if they are on the board.

Issue security level is an issue visibility and permission mechanism rather than a board setting. It can hide issues from specific users who lack permission but it is not the typical board configuration that causes a control chart to omit issues for all viewers.

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.

Enable the Kanban backlog and Drag issues into epics across projects are the correct options for a board that spans multiple Jira projects.

Enable the Kanban backlog is available because backlog support is a board level feature for Kanban boards and it operates based on the board filter. When a board includes issues from multiple projects the Kanban backlog shows the issues that match the board filter across those projects so you can manage work in one backlog view.

Drag issues into epics across projects is available because epics are issue types that can be associated with issues from any project included by the board filter. If the board brings in issues and epics from multiple projects you can link or drag issues into epics across those projects subject to permissions and issue type configurations.

Show versions from both projects on the Releases page is incorrect because the Releases page is project scoped and shows versions defined for a single project. A multi project board does not merge project version lists into a single Releases view for the board.

Advanced Roadmaps is incorrect in this context because it is a separate planning product and not an automatic capability of a multi project board. Advanced Roadmaps provides cross project planning features but it requires its own configuration and licensing rather than being a native board feature.

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.

Board sub filter is correct because it is the board configuration designed to apply an additional JQL filter on top of the main board filter so you can automatically limit which completed issues are visible and show only those completed in the current week.

Board sub filter is configured in the board settings and can contain JQL that uses time functions such as startOfWeek() or resolutionDate to keep the view dynamic and automatic. This lets the board hide completed issues from earlier weeks without changing the main board filter or requiring users to select a filter manually.

Quick filters are incorrect because they are user selectable shortcuts that change the view only when someone clicks them and they do not enforce automatic visibility on board load.

Hide completed issues older than is incorrect for this question because that setting is a simple age based option and it is less flexible than using a JQL sub filter. It often cannot express dynamic week based logic as precisely as a sub filter that uses functions like startOfWeek().

Main board filter is incorrect because it sets the overall scope of issues on the board and changing it affects all users and board behavior. The main filter is not the intended place for a temporary or view specific rule that should only show items completed in the current week.

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.

The correct answer is Visualize plans and monitor progress for multiple teams at program level.

This capability is exactly what Advanced Roadmaps provides because it can aggregate work across teams and present timelines and dependency views so program managers can coordinate delivery and monitor progress at the program level.

The Export plans to Excel or PDF option is an export and reporting feature and it does not provide the cross team aggregation or dependency planning needed to coordinate multiple agile teams.

The Jira Align entry refers to a separate Atlassian product that also supports enterprise level planning and coordination but it is not an Advanced Roadmaps capability and so it is not the correct choice for this question.