Jira ACP-120 Certification Practice Exams

Orion Solutions manages a company project named “Atlas” and the project permission scheme and issue security tiers are configured in this way. Any logged in user can Browse Projects. The Set issue security permission is granted to the Project Role “Developers”. Any logged in user can Edit issues. The security tiers are defined as Tier1 default which includes Reporter Assignee and Project Role “Developers”. Tier2 includes Reporter Assignee Project Role “Developers” and Project Role “Analysts”. Tier3 includes Reporter Project Role “Analysts” and Project Role “Compliance”. Tier4 includes Project Role “Compliance” Project Role “Developers” and the single user “alex”. Which statement is correct?

• ❏ A. Newly created issues will be visible to all members of the Atlas project role Analysts

• ❏ B. Every member of the Atlas project role Developers can assign any security tier to an issue

• ❏ C. Members of the Atlas project role Analysts can view issues across three security tiers

• ❏ D. Members of the Atlas project role Analysts can change an issue from Tier2 to Tier3

• ❏ E. The individual user alex will be restricted to viewing issues in a single security tier

When a development group rearranges parent tasks on their Scrum backlog how do the child sub-tasks behave and which statements about sub-task ordering are accurate? (Choose 2)

• ❏ A. Child sub-tasks move together with their parent issue when the parent is reordered

• ❏ B. All child items must be arranged before the parent task can be moved

• ❏ C. Individual sub-tasks can be reordered relative to other sub-tasks under the same parent

• ❏ D. Sub-tasks always keep a ranking value that is different from their parent

Leah must satisfy several needs. She needs a way to group issues across multiple company managed projects. She also needs to quickly view the total number of issues and the number completed for each group without adding extra reporting or gadgets. She needs to be able to bulk edit every issue within a group with minimal effort. Which configuration element satisfies all of these requirements?

• ❏ A. Filters

• ❏ B. Components

• ❏ C. Boards

• ❏ D. Releases

• ❏ E. Epics

Which user interface elements can be recoloured using the global Look and Feel settings in a project management instance? (Choose 2)

• ❏ A. The background colour of the project sidebar

• ❏ B. The colour palette applied to every button across the application

• ❏ C. The background colour of the primary navigation bar

• ❏ D. The background colour of the issue detail view

• ❏ E. The colour of the create issue button and the highlight used for the currently selected navigation item

After a recent configuration update at Northbridge Labs some team members report that the “Comment” field no longer appears on transition screens in a company-managed project while other users still see it. What configuration change most likely caused this behavior?

• ❏ A. Introduced a workflow condition that restricts who can perform the transition

• ❏ B. Modified a post function on the transition

• ❏ C. Detached or removed the transition screen

• ❏ D. Revoked the project Add Comments permission for affected users

• ❏ E. Added a workflow validator that checks transition input

What configuration allows users whose email addresses end with @example.com to request access automatically to a Jira Cloud site?

• ❏ A. Enable invitation links for the site

• ❏ B. Add example.com to approved domains and require admin approval for access

• ❏ C. Configure Google Workspace SAML single sign on for example.com

Maya at Skylark Systems changed a company managed project key from NVT to RPL. Which statement about links reports saved filters and Confluence issue macros is correct?

• ❏ A. Users must edit their saved filters to use the new project key

• ❏ B. Some dashboards and reports will display errors

• ❏ C. URLs that contain the previous project key will redirect to the new project key

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

• ❏ E. You must manually update Confluence Jira issue macros to reference the new key

Ravi is the Jira administrator for the site scrumtuous.atlassian.net and he created a new company managed project called ASSET with custom settings and user access. After three weeks the project lead Maria asked Ravi to enable issue creation from inbound email. Ravi configured the Default Cloud Mail Server with the email address [email protected] and added a mail handler using the type “Create a new issue from each email message”. He set the handler to use the ASSET project and set the issue type to Task while selecting a default reporter. A test email created an issue successfully but after several days Maria reported that some incoming emails created issues as expected while others did not and she did not receive notifications for the ones that were not created. There is only a single incoming mail server and a single mail handler configured on the site. What best explains this behavior?

• ❏ A. The mail handler is set to add comments to matching issues instead of creating new issues

• ❏ B. The default reporter account does not have the “Create issues” project permission

• ❏ C. Some emails are ignored because they do not reference any issue key

• ❏ D. The mail handler has the Notify Users option turned off

Marisol needs to set the resolution field for every issue marked resolved since the start of the current quarter and after she applied the filters she cannot find the “Bulk change” button. Why is the button not visible?

• ❏ A. Marisol is not a Jira administrator

• ❏ B. Marisol does not have the “Resolve issue” project permission and she also lacks the “Make bulk changes” global permission

• ❏ C. Marisol does not have the “Make bulk changes” global permission

• ❏ D. Marisol does not have the “Edit issue” project permission and she also lacks the “Make bulk changes” global permission

• ❏ E. The filter returned more issues than the instance maximum for bulk operations so the Bulk change button is suppressed

A regional bank called Meridian Ledger uses a company managed project named “FINX” that has an issue security scheme intended to limit issue visibility to members of the “Compliance Team” and the “Compliance Managers” project roles. Hannah reports that she can open an issue she filed even though she is not part of either project role in project “FINX”. What is the most likely reason she can see the issue?

• ❏ A. Hannah is a member of the “atlassian-addons-project-access” project role

• ❏ B. Hannah holds the Administrators project role in project “FINX”

• ❏ C. Hannah is the site administrator for the cloud instance

• ❏ D. No default issue security level is configured for the project security scheme

• ❏ E. Hannah does not have the Set issue security project permission

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

In what situations is it preferable to use a project component instead of adding a global custom field in a Jira Cloud project? (Choose 2)

• ❏ A. The field must be usable across many projects site wide

• ❏ B. You want the issue assignee to be set automatically based on the selected component

• ❏ C. You need a single picklist value to support cross project reporting and filters

• ❏ D. The configuration should be maintained by the project administrator rather than a site administrator

Which configuration actions are not supported in team-managed projects when configuring issue types and workflows? (Choose 2)

• ❏ A. Insert a screen transition into a workflow

• ❏ B. Manage project roles

• ❏ C. Add the “Affects versions” field to an issue type’s field list

• ❏ D. Add the “Fix versions” field to an issue type’s field list

Which of the following statements about filter subscriptions are incorrect? (Choose 3)

• ❏ A. Recipients may receive different issue details from the same filter subscription

• ❏ B. Users can select a project role to receive the subscription email

• ❏ C. You can configure a Jira group as an email recipient for a subscription

• ❏ D. Creating any filter subscription requires the Manage group filter subscriptions global permission

• ❏ E. A filter subscription will never send an email when the query returns zero results

Sofia from Solstice Apps is auditing product access for Jira Software and she observes the groups with their sizes and which ones are defaults. The companyadmins group has 2 members and it is not a default group. The devomega group has 18 members and it is marked as a default group. The trackerteam group has 12 members and it is marked as a default group. The hrstaff group has 6 members and it is not a default group. Sofia then grants Jira Software access to Alex with a “User” product role. Which statement is definitely true?

• ❏ A. Alex will be added to three groups

• ❏ B. Alex will not be added to any existing groups and will still have Jira Software access

• ❏ C. Alex will become a company administrator

• ❏ D. Alex will be added to two groups

• ❏ E. Alex will be added to four groups

Which capability can only be implemented in a company-managed project rather than in a team-managed project?

• ❏ A. Automatically assign an issue during a workflow transition

• ❏ B. Configure notifications to be sent to the selected component lead

• ❏ C. Send notifications to the project lead

• ❏ D. Change the project key

• ❏ E. Enable or disable the Versions page in project navigation

Amira is the Jira administrator and also the project administrator for the company-managed project “HELPDESK” which is used by sales staff developers and QA analysts. The “HELPDESK” project shares its configuration with several other company-managed projects. The sales staff report that they are missing particular email alerts and they provided Amira a list of events for which they must receive notifications. Developers and QA analysts want their existing email notifications to remain unchanged. What is the best approach for Amira to satisfy all parties?

• ❏ A. Create a shared group for the sales staff and add that group to the requested events in the “HELPDESK” notification scheme

• ❏ B. Add each sales staff member individually to the requested events in the “HELPDESK” notification scheme

• ❏ C. Create a new project role add sales staff to that role within the “HELPDESK” project and then include that role for the requested events in the project notification scheme

• ❏ D. Create a project role and make sales staff default members of that role then add the role to the requested events in the “HELPDESK” notification scheme

An excerpt from the permission matrix for the “ORBIT” project lists which project roles hold which permissions. The only global permission assigned is Administer Jira and all other global permissions are empty. Users in the group orbit_team_group must be able to log work and edit issues and also create and share filters. Which two actions together will provide these rights? (Choose 2)

• ❏ A. Add orbit_team_group to Project Role “Developers”

• ❏ B. Add orbit_team_group to Share dashboards and filters global permission

• ❏ C. Add orbit_team_group to Project Role “Analysts”

• ❏ D. Add orbit_team_group to Manage group filter subscriptions global permission

• ❏ E. Add orbit_team_group to Project Role “Scrum Team”

• ❏ F. Add the Project Role “Analysts” to Share dashboards and filters global permission

Which configuration should you change to set a different default option for a custom field in a single company managed project?

• ❏ A. Screen schemes

• ❏ B. Custom field context configuration

• ❏ C. Field configuration scheme

Maya verified she enabled “You are watching this issue” in her account preferences and she stopped receiving email notices when her project team updates issues. Which Jira configuration should she inspect?

• ❏ A. Mail Handler

• ❏ B. Outgoing Mail

• ❏ C. SMTP Mail Server

• ❏ D. Personal Settings

• ❏ E. Global Mail Settings

Maya’s group at HarborCloud needs a new Jira Software project. The group will plan work in weekly sprints and they want the board to group issues by assignee and to show the “due date” on all cards in the board. What type of project meets all of these requirements?

• ❏ A. Team-managed Kanban

• ❏ B. Team-managed Scrum

• ❏ C. Company-managed Scrum

• ❏ D. Company-managed Kanban

Members of the Atlas project role Analysts can view issues across three security tiers

Members of the Atlas project role Analysts can view issues across three security tiers is correct because the role Analysts is explicitly included in Tier2 and Tier3. An Analyst who creates an issue becomes the Reporter and reporters are included in the Tier1 default level. That combination lets an Analyst see issues in Tier1 when they are the Reporter and lets them see Tier2 and Tier3 by role membership, which totals three tiers. Analysts do not automatically see Tier4 unless they are also added to a role or listed individually in that tier.

Newly created issues will be visible to all members of the Atlas project role Analysts is wrong because newly created issues inherit the Tier1 default which lists Reporter, Assignee and Project Role “Developers”. The default does not include Analysts so newly created issues are not visible to all Analysts unless an Analyst is the Reporter or Assignee.

Every member of the Atlas project role Developers can assign any security tier to an issue is wrong because granting the Set issue security permission to Developers allows that role to set a security level but it does not change which users are included in each security tier. The visibility outcome depends on the members listed in the chosen tier and on the project permission configuration.

Members of the Atlas project role Analysts can change an issue from Tier2 to Tier3 is wrong because only users granted the Set issue security permission can change an issue’s security level and that permission is given to the Project Role “Developers” not to Analysts. Being in the visible list for tiers does not grant the ability to change the tier.

The individual user alex will be restricted to viewing issues in a single security tier is wrong because alex is listed in Tier4 but alex could also appear in other tiers by being Reporter or Assignee or by holding a project role that is included in other tiers. Being listed in one tier does not inherently prevent visibility in other tiers when other membership conditions apply.

When you evaluate security tier questions look at both who is explicitly included in each level and which permissions such as Set issue security are granted to roles or users.

The correct answers are Child sub-tasks move together with their parent issue when the parent is reordered and Individual sub-tasks can be reordered relative to other sub-tasks under the same parent.

Child sub-tasks move together with their parent issue when the parent is reordered is correct because most Scrum backlogs treat sub-tasks as children of the parent issue and keep them nested under that parent when the parent is moved on the backlog. The parent and its children stay together visually and in the backlog ordering to preserve the hierarchical relationship.

Individual sub-tasks can be reordered relative to other sub-tasks under the same parent is correct because while sub-tasks remain attached to their parent, you can change the order of those sub-tasks beneath the same parent to reflect local priorities or workflow needs. Reordering applies to siblings under the same parent without affecting the parent position.

All child items must be arranged before the parent task can be moved is incorrect because there is no requirement to manually arrange every child before moving the parent. The parent can be moved and the children will move with it.

Sub-tasks always keep a ranking value that is different from their parent is incorrect because sub-task ranking is typically handled in relation to the parent and to sibling items and there is not always a separate immutable ranking value that is independent of the parent. Systems vary but the statement is too absolute to be true.

When a question focuses on ordering think about whether the items are treated as a single hierarchical group or as independent entries and check whether the wording requires an absolute rule or a typical behavior. Hierarchy and local reordering are often the key concepts.

The correct option is Epics.

Epics act as a container for related issues and they are designed to show progress and completion of work for that container so you can see totals and completed counts without adding extra reporting or gadgets. You can filter by the epic link to list all member issues and then perform a bulk change on that filtered set so you can edit every issue in the group with minimal effort.

Filters can locate and list issues across multiple projects and they can be used as the basis for bulk operations, but they do not provide a native grouping container that displays aggregate progress and completed counts per group without additional dashboarding or gadgets.

Components are defined at the project level and are not intended to group issues across multiple company managed projects, so they do not meet the cross project grouping requirement.

Boards provide a visual view of issues from one or more projects but they are not a grouping element that creates an issue container with built in aggregated counts and they do not inherently provide a single click bulk edit for a logical group.

Releases or versions are tied to individual projects for tracking shipped work and they are not suitable for grouping issues across multiple company managed projects in the way required by the question.

When a question asks for a way to group related work and show progress and completion without extra gadgets think about issue containers such as epics and how filtering by the container enables bulk operations.

The correct options are The background colour of the primary navigation bar and The colour of the create issue button and the highlight used for the currently selected navigation item.

The global Look and Feel controls the top level branding and the primary accent used across the product interface. That is why The background colour of the primary navigation bar is correct because the header or navigation bar is part of the global branding that these settings change.

The same global accent is applied to prominent actions and selection highlights which is why The colour of the create issue button and the highlight used for the currently selected navigation item is correct. The setting provides a single primary color that is used for the main action button and for highlighting the active navigation item to keep the product appearance consistent.

The background colour of the project sidebar is incorrect because sidebars and per project panels are part of the content layout and are not typically overridden by the global Look and Feel branding.

The colour palette applied to every button across the application is incorrect because the global setting usually sets a single primary accent for key actions and highlights and it does not recolour every button variant and contextual control across the product.

The background colour of the issue detail view is incorrect because the issue content area background remains the page or theme default and is not replaced by the global look and feel accent settings.

Look for words like header, navigation, primary or accent when a question asks about global branding. These settings usually affect the top level UI and primary actions and not every content area.

The correct answer is Revoked the project Add Comments permission for affected users.

When the project level Add Comments permission is removed for certain users the comment control on transition screens will no longer appear for those users because the application hides UI elements that the user is not permitted to use. This change would affect only the users who lost the permission and not users who still have it which matches the scenario described.

Introduced a workflow condition that restricts who can perform the transition is incorrect because a condition controls whether a transition is visible or executable for a user and if it were in effect the users would not see the transition at all rather than only losing the comment field.

Modified a post function on the transition is incorrect because post functions run after a transition completes and they do not determine which fields are displayed on the transition screen.

Detached or removed the transition screen is incorrect because removing or detaching the screen would remove the comment field for all users for that transition and would not explain why only some users are affected.

Added a workflow validator that checks transition input is incorrect because validators only evaluate input when the transition is submitted and they do not hide fields on the form before submission.

If a field is missing only for some users first check the project permission scheme and the Add Comments permission for those users to quickly rule out a permission change.

The correct option is Add example.com to approved domains and require admin approval for access.

When you Add example.com to approved domains and require admin approval for access you create an allow list that lets users with emails at that domain trigger the built in request access flow. Those users can request to join the Jira Cloud site and the requests are routed to site or organization administrators for approval so access is controlled but easy for domain users to request.

Enable invitation links for the site is incorrect because invitation links are used to send direct invites or share a link with specific people and they do not enable a domain based automatic request access workflow.

Configure Google Workspace SAML single sign on for example.com is incorrect because SAML SSO manages how users authenticate and can restrict logins but it does not by itself provide the request access mechanism described in the question. User provisioning can be added separately but the option as stated does not implement the request flow.

Read the question carefully to separate authentication features from access request features. The approved domains setting controls who can request access while SSO controls how they sign in.

The correct answer is: URLs that contain the previous project key will redirect to the new project key.

When a project key is changed Jira updates the issue keys and creates redirects from the old issue URLs to the new keys. This means bookmarks and external links that reference the previous key will resolve to the issues under the new key and users will not generally lose access to those linked issues.

Users must edit their saved filters to use the new project key is incorrect because saved filters and JQL queries are resolved by Jira using internal identifiers and the URL redirects preserve access. Most filters do not require manual rewriting after a key change.

Some dashboards and reports will display errors is incorrect in general because gadgets and reports that reference issues or filters will normally continue to work due to the redirects and the underlying issue identifiers. Only very unusual custom integrations that rely on hard coded assumptions might need attention.

A new project can be created using the previous project key is incorrect because the previous key remains associated with the project history and the redirect behavior. You cannot simply reuse the old key without first addressing the existing project and redirect mapping.

You must manually update Confluence Jira issue macros to reference the new key is incorrect because Confluence macros that link to Jira issues will follow the same redirects and will continue to display the linked issues. Manual updates are not normally required for standard issue macros.

Remember that Jira creates redirects when you change a project key so check links and macros but do not assume you must update every saved filter or macro manually.

The default reporter account does not have the “Create issues” project permission is correct.

The mail handler was configured to create new issues and it uses a reporter mapping when the sender cannot be matched to a Jira user. If the configured default reporter account lacks the project permission to create issues then Jira will not be able to create an issue for those incoming messages and the mail is effectively ignored. That explains why some emails created issues while others did not, because emails that matched an existing user with permissions were created but emails that fell back to the default reporter account failed.

The mail handler is set to add comments to matching issues instead of creating new issues is incorrect because the handler type was explicitly set to create new issues. If the handler were set to add comments then incoming messages would require an issue key to match and would not create new issues.

Some emails are ignored because they do not reference any issue key is incorrect because the chosen handler is meant to create a new issue for each message. Lack of an issue key only prevents comment handlers from finding a matching issue, but it does not prevent a create issue handler from creating a new issue.

The mail handler has the Notify Users option turned off is incorrect because turning notifications off affects whether users are emailed about created issues and comments. It does not stop issues from being created. The report that some emails did not create issues indicates a permission or creation failure rather than notification settings.

When mail-based issue creation fails check the default reporter mapping and then verify that account has the Create issues permission in the project before changing handler types.

The correct answer is Marisol does not have the “Make bulk changes” global permission.

The Bulk change button in the issue navigator is shown based on the global “Make bulk changes” global permission. If a user does not have that global permission the button will not be visible even when filters return matching issues. Project level permissions determine what you can do to individual issues, but they do not make the Bulk change button appear for a user who lacks the global permission.

Marisol is not a Jira administrator is not correct because being a Jira administrator is not required to see or use the Bulk change button. The visibility of that control is governed by the specific global permission rather than by admin status.

Marisol does not have the “Resolve issue” project permission and she also lacks the “Make bulk changes” global permission is not correct because the extra claim about a “Resolve issue” project permission is not the reason the button is hidden. The key reason the button is missing is the lack of the global “Make bulk changes” global permission, and the project level claim in this option is unnecessary and inaccurate for visibility.

Marisol does not have the “Edit issue” project permission and she also lacks the “Make bulk changes” global permission is not correct because while the project Edit issue permission affects whether she can change fields on specific issues it does not control whether the Bulk change button is displayed. The missing global “Make bulk changes” global permission is the specific cause of the hidden button.

The filter returned more issues than the instance maximum for bulk operations so the Bulk change button is suppressed is not correct because the Bulk change button is not hidden based on the number of results alone. The UI requires the global permission to display the button. Exceeding any system limits may affect the operation or selection behavior but it is not the primary reason the button would be entirely suppressed from view.

When a UI action like Bulk change is missing check the relevant global permission first and then verify project permissions for the issues you want to change. The Make bulk changes global permission controls the button visibility.

The correct option is No default issue security level is configured for the project security scheme.

If no default issue security level is set then new issues are created without an issue security level and they remain visible to anyone who can browse the project. Because Hannah filed the issue it had no security level restricting it and she can open it even though she is not in the Compliance Team or the Compliance Managers roles. To restrict visibility you must either set a default level on the scheme or have users select an appropriate security level when creating the issue.

Hannah is a member of the “atlassian-addons-project-access” project role is incorrect because that role is intended for application and integration accounts and it does not explain why a normal user would see an issue. It is not a typical cause of user issue visibility.

Hannah holds the Administrators project role in project “FINX” is incorrect because being a project administrator does not automatically bypass issue security levels. Project admin permissions do not grant unrestricted viewing of issues that are limited by an issue security level.

Hannah is the site administrator for the cloud instance is incorrect because site administration privileges do not automatically give a user visibility into every issue across projects that are protected by issue security. Site admin is about managing the instance and users but it does not override issue security rules for viewing issues.

Hannah does not have the Set issue security project permission is incorrect because that permission only controls who can set or change an issue’s security level. Lacking that permission would not itself grant Hannah visibility and it would not explain why she can open the issue she filed.

When you see a question about issue visibility think about whether an issue security level is actually applied. If no default issue security level exists then issues can be visible to anyone with project browse rights even if role based levels are defined in the scheme.

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

The correct options are You want the issue assignee to be set automatically based on the selected component and The configuration should be maintained by the project administrator rather than a site administrator.

You want the issue assignee to be set automatically based on the selected component is correct because Jira components can have a default assignee or component lead. When an issue is created with a component the configured lead or default assignee can receive the issue automatically so you do not need a global custom field to drive assignment.

The configuration should be maintained by the project administrator rather than a site administrator is correct because components are managed at the project level and can be created and edited by project administrators. This keeps the configuration local to the project and avoids requiring site administrator access to change a global custom field.

The field must be usable across many projects site wide is incorrect because components are scoped to a single project and are not available site wide. If you need a field usable across many projects you should use a global custom field or a field with a global context.

You need a single picklist value to support cross project reporting and filters is incorrect because a picklist that must be consistent for reporting across projects should be implemented as a global custom field. Components differ by project and will not provide a single consistent picklist across multiple projects.

Remember that components are project scoped and can set default assignees, while global custom fields are site scoped and provide consistent values across projects.

Insert a screen transition into a workflow and Add the “Affects versions” field to an issue type’s field list are not available in team-managed projects.

The workflow editor in team-managed projects is intentionally simplified and does not let you insert transitions that display specific screens or attach screens to individual transitions. Configuring transition screens and detailed transition behaviour relies on the classic workflow and screen schemes that are available only in company-managed projects, so inserting a screen transition is not possible in a team-managed project.

Team-managed projects handle versions in a simplified way and they expose the Fix versions field for release tracking. The “Affects versions” field is not supported in the issue type field lists for team-managed projects, so you cannot add it there. Full control over both version fields and their schemes requires a company-managed project.

Manage project roles is incorrect because team-managed projects allow project administrators to manage project membership and assign simple project-level roles or access via the project settings. You can control who has what access within a team-managed project without needing the global project role schemes used by company-managed projects.

Add the “Fix versions” field to an issue type’s field list is incorrect because the Fix versions field is available in team-managed projects and can be added to issue types to support release planning.

When a question asks about team-managed versus company-managed features think about whether the feature needs global schemes or shared configuration. If it does then the feature is likely only available in company-managed projects.

The correct answers are Users can select a project role to receive the subscription email, Creating any filter subscription requires the Manage group filter subscriptions global permission, and A filter subscription will never send an email when the query returns zero results.

Users can select a project role to receive the subscription email is incorrect because filter subscriptions do not accept project roles as email recipients. The subscription interface allows individual users, email addresses, and Jira groups to be added, but it does not target project roles for delivery.

Creating any filter subscription requires the Manage group filter subscriptions global permission is incorrect because that global permission only applies when creating or managing subscriptions on behalf of groups. Regular users can create their own filter subscriptions for filters they can view without that global permission.

A filter subscription will never send an email when the query returns zero results is incorrect because delivery behavior can depend on subscription settings and system configuration. Subscriptions can be configured or allowed to send notifications even when a query returns no issues, so it is not true that they will never send in that case.

Recipients may receive different issue details from the same filter subscription is not an incorrect choice because recipients see results based on their permissions and issue security. That means different users can receive different issue details from the same subscription.

You can configure a Jira group as an email recipient for a subscription is not an incorrect choice because Jira supports adding groups as recipients when creating filter subscriptions. Using groups is a standard way to notify multiple users at once.

Carefully map each option to real product behavior before answering and watch for words about project roles, group recipients, and global permissions because those details often determine the correct choice.

The correct answer is Alex will be added to two groups.

Two groups in the list are marked as default for Jira Software, namely devomega and trackerteam. Granting product access with the User product role automatically places the user into the product’s default groups, so Alex will be added to those two existing groups.

Alex will be added to three groups is incorrect because only two groups are marked as default. The group sizes do not change which groups are applied when granting product access.

Alex will not be added to any existing groups and will still have Jira Software access is incorrect because assigning a product role to a user adds them to the product’s default groups when those defaults are set. Alex will therefore be added to the default groups for Jira Software.

Alex will become a company administrator is incorrect because becoming a company administrator requires explicit addition to the administrative group or role. The companyadmins group in this case is not a default group, so granting the Jira Software User role does not make Alex a company administrator.

Alex will be added to four groups is incorrect because only two groups are configured as defaults for the product. There is no information that would cause Alex to be placed into additional groups beyond those defaults.

Count the product’s default groups and focus on which groups are marked as default rather than on group sizes or names when answering these questions.

Configure notifications to be sent to the selected component lead is correct.

This capability depends on having components with assigned component leads and the ability to reference those leads in a project notification scheme. Those features are part of the company managed project model so only a company managed project can configure notifications to go to the selected component lead.

Automatically assign an issue during a workflow transition is not exclusive to company managed projects because both project types can perform automatic assignment either through workflow post functions in company managed projects or through automation rules in team managed projects.

Send notifications to the project lead is not correct because notifying the project lead is a general notification option that can be configured in both project types and is not restricted to company managed projects.

Change the project key is not correct because changing a project key is a project administration action that can be done in either project type when you have the required permissions.

Enable or disable the Versions page in project navigation is not correct because control over project navigation and access to versions is not a capability that exists only in company managed projects and can be managed in different ways across both project types.

When you need to choose between company managed and team managed look for features tied to classic Jira administration such as components or notification schemes because those are typically available only in company managed projects.

The correct option is Create a new project role add sales staff to that role within the “HELPDESK” project and then include that role for the requested events in the project notification scheme.

This approach uses a project role so membership is managed only for the HELPDESK project and does not change recipients in other projects that share the notification scheme. You add the sales staff as members of the project role in HELPDESK and then add that role to the specific events in the notification scheme. That preserves existing notifications for developers and QA because you are not altering global groups or users for the shared scheme.

Create a shared group for the sales staff and add that group to the requested events in the “HELPDESK” notification scheme is incorrect because groups are global. Adding a group to the notification scheme would affect all projects that use that scheme and could cause sales staff to receive notifications from other projects.

Add each sales staff member individually to the requested events in the “HELPDESK” notification scheme is incorrect because individual user entries are hard to maintain and the change to the scheme will apply wherever the scheme is used. Using a role keeps membership manageable and scoped to the project.

Create a project role and make sales staff default members of that role then add the role to the requested events in the “HELPDESK” notification scheme is incorrect because setting default members makes the assignment broader and can cause the sales staff to be added across multiple projects or as a global default. That would alter notifications outside of the HELPDESK project which is not desired.

When notification schemes are shared across projects prefer using project roles so you can change membership only in the affected project without impacting other projects.

Add orbit_team_group to Project Role “Analysts” and Add orbit_team_group to Share dashboards and filters global permission are correct.

Add orbit_team_group to Project Role “Analysts” grants the group the project level permissions that the ORBIT permission matrix assigns to the Analysts role, and those project permissions include the ability to Edit Issues and Log Work when the role is mapped to those rights in the permission scheme.

Add orbit_team_group to Share dashboards and filters global permission grants the ability to create and share filters and dashboards across the instance because creating and sharing filters is controlled by that global permission rather than by a project permission.

Add orbit_team_group to Project Role “Developers” is incorrect because adding the group to Developers will only help if the Developers role actually holds Edit Issues and Log Work in the ORBIT permission scheme, and the given matrix shows those rights on Analysts instead.

Add orbit_team_group to Manage group filter subscriptions global permission is incorrect because that permission only controls managing subscriptions to filters and not the ability to create or share filters.

Add orbit_team_group to Project Role “Scrum Team” is incorrect because the Scrum Team role does not carry the necessary Edit Issues and Log Work permissions according to the provided permission matrix.

Add the Project Role “Analysts” to Share dashboards and filters global permission is incorrect because the actionable change is to grant the global permission to the group that needs the ability, not to try to add a project role to the global permission in this scenario.

When you see permissions questions first check whether the right is project level or global. Then confirm whether you must add a group to a global permission or add the group to the project role that the project permission scheme already maps to the needed rights.

Custom field context configuration is correct because the custom field context is what you change when you want a different default option for that field in a single company managed project.

A custom field context lets you scope a field to particular projects and issue types and it also lets you define the option set and the default value for that scope. You create or edit a context for the specific project and then set the default option for the field in that context so only that project uses the changed default.

Screen schemes is incorrect because screen schemes only control which screens are used for create, edit and view actions and which fields appear on those screens. They do not control the option sets or default values of a custom field.

Field configuration scheme is incorrect because field configuration schemes map field configurations to issue types and control behaviors like required or optional and the renderer. They do not provide per project option lists or per project default values for custom fields.

Focus on the concept of scope when asked about changing defaults for a single project. If a question mentions changing defaults or option lists for only one project then think about custom field contexts rather than screens or field configuration schemes.

The correct option is Outgoing Mail.

Outgoing Mail is the Jira administration area that controls whether the application sends notification emails to users and watchers when issues are updated. If notifications stopped after a change in behavior this is the place to confirm that outgoing email is enabled and to send a test message or view the mail queue and delivery status.

Mail Handler is incorrect because mail handlers deal with incoming email and how Jira creates or updates issues from messages. That setting does not control whether Jira sends notification emails to watchers.

SMTP Mail Server is not the best choice because it normally refers to the low level SMTP server details rather than the switch that enables outbound notifications in the admin UI. In some older Jira versions server entries were managed separately so this option may appear as a legacy configuration on older exams.

Personal Settings is incorrect because Maya already checked her personal preference for watching issues and those settings apply per user. Personal settings will not stop all outgoing mail from the system when the global outgoing mail capability is turned off.

Global Mail Settings is incorrect because the modern admin workflow uses the Outgoing Mail page to enable and troubleshoot notifications. If a legacy named page appears on older documentation it is functionally replaced by the Outgoing Mail controls in current versions.

When email notifications stop first check the Outgoing Mail admin page and try a test email before changing user preferences.

The correct option is Company-managed Scrum.

A Company-managed Scrum project supports Scrum sprints and provides advanced board configuration. It allows the team to run weekly sprints and to configure the board layout and swimlanes so issues can be grouped by assignee and so the due date field can be shown on cards.

Team-managed Kanban is incorrect because Kanban projects are not designed around fixed sprints and team-managed projects have more limited board and card customization, so they do not reliably meet the requirement to group by assignee and show due date on every card.

Team-managed Scrum is incorrect because although it supports sprints, team-managed projects have reduced board configuration compared with company-managed projects. That limitation can prevent setting swimlanes to group by assignee and configuring the card layout to display the due date on all cards.

Company-managed Kanban is incorrect because Kanban boards do not use Scrum sprints. Even though company-managed projects offer the needed customization, the Kanban project type will not meet the requirement to plan work in weekly sprints.

When a question requires both sprints and extensive board customization choose a company-managed Scrum project since it provides the most control over swimlanes and card fields.