CertsOut ATLASSIAN-ACP-120

Page 1


IMPORTANT NOTICE

Feedback

We have developed quality product and state-of-art service to ensure our customers interest. If you have any suggestions, please feel free to contact us at feedback@certsout.com

Support

If you have any questions about our product, please provide the following items: exam code screenshot of the question login id/email please contact us at and our technical experts will provide support within 24 hours. support@certsout.com

Copyright

The product of each order has its own encryption code, so you should use it independently. Any unauthorized changes will inflict legal punishment. We reserve the right of final explanation for this statement.

Question #:1 - [Advanced User Features]

Level custom field contains three options: Beginner, Intermediate, Advanced Pro. You need to find issues in any of the levels. Identify the correct JQL query.

Level = Beginner OR Level = Intermediate OR Level = Advanced Pro

Level IN (Beginner, Intermediate, "Advanced Pro")

Level ~ (Beginner, Intermediate, "Advanced Pro")

Level IN (Beginner, Intermediate OR Advanced Pro)

Answer: B

Explanation

To find issues where the custom field (a single-select field) has any of the values , Level Beginner Intermediate , or , the JQL query must use the operator to check for multiple values. The correct query is

Level IN (Beginner, Intermediate, "Advanced Pro") with quotes. Advanced Pro

Advanced Pro IN (Option B), as it properly handles the multi-word value

Explanation of the Correct Answer (Option B):

The custom field is a single-select field with three options: , , and Level Beginner Intermediate . The operator allows checking if a field’s value matches any of a list of values.

Advanced Pro IN For multi-word values like , quotes are required to treat it as a single value. Advanced Pro

The query searches for issues where the Level IN (Beginner, Intermediate, "Advanced Pro") field is set to , , or , covering all possible values. Level Beginner Intermediate Advanced Pro

Exact Extract from Documentation:

Advanced searching - operators reference

The operator checks if a field’s value matches any of the specified values. IN

Example:

Level IN (Beginner, Intermediate, "Advanced Pro") returns issues where the field is Level set to , , or . : For values containing spaces (e.g., Beginner Intermediate Advanced Pro Note ), enclose the value in double quotes. Advanced Pro (Source: Atlassian Support Documentation, "Advanced searching - operators reference")

Why This Fits: The operator with properly quoted values efficiently searches for all specified IN options, making Option B the correct answer. Level

Why Other Options Are Incorrect:

Level = Beginner OR Level = Intermediate OR Level = Advanced Pro (Option A):

Extract from Documentation:

This query is functionally correct but less efficient than using . It requires multiple IN = operators and does not handle the multi-word value correctly without quotes, Advanced Pro potentially causing a syntax error.

Use for concise queries with multiple values. Multiple clauses are valid but less efficient and require IN OR quotes for multi-word values.

(Source: Atlassian Support Documentation, "Advanced searching - operators reference")

Level ~ (Beginner, Intermediate, "Advanced Pro") (Option C):

Extract from Documentation:

The operator is used for partial text matching (e.g., wildcard searches) and is not valid for ~ single-select fields like , which require exact value matching. This query is Level syntactically incorrect.

The operator is for text fields and partial matching, not for select fields. Use or for exact value matching. ~ = IN

(Source: Atlassian Support Documentation, "Advanced searching - operators reference")

Level IN (Beginner, Intermediate OR Advanced Pro) (Option D):

This query is syntactically incorrect, as the operator requires a comma-separated list of IN values, not logical operators like . Additionally, needs quotes to be OR Advanced Pro treated as a single value.

Extract from Documentation:

The operator requires a list of values (e.g., (value1, value2, "value3")). Logical operators like are not IN OR allowed inside .IN

(Source: Atlassian Support Documentation, "Advanced searching - operators reference")

:

Additional Notes:

The field must be a single-select custom field with the exact options listed.Verify the field’s Level configuration inSettings > Issues > Custom fields

The query can be tested in and saved as a filter. Issues > Search for issues

Ensure the user has permission for the relevant projects. Browse Projects

Atlassian Support Documentation:Advanced searching - operators reference

Atlassian Support Documentation:Search for issues using JQL

Question #:2 - [Issue Types, Fields, Screens]

You renamed a value in the Resolution field from Done to Finished. What might need to be updated as a result?

Workflow post functions

Saved filters

Issue detail view

Issue Statistics gadgets

Issues in team-managed projects

Answer: B

Explanation

Renaming a value in the field (from to ) changes its display name globally in Jira Resolution Done Finished Software Cloud. This can impact configurations or features that reference the resolution value by name, particularly in JQL queries. The element most likely to need updating is (Option B), as they often saved filters use JQL queries that include resolution values.

Explanation of the Correct Answer (Option B):

Saved filtersoften use JQL queries that reference resolution values (e.g., resolution = Done). If the field value is renamed from to , any filters using resolution = Done Resolution Done Finished will no longer match issues with the renamed resolution ( ), as the old value is no longer Finished valid. These filters must be updated to use resolution = Finished to continue returning the correct issues.

Exact Extract from Documentation:

Manage resolutions in Jira Cloud

Resolutions are global values used in the field to indicate an issue’s resolution state. Resolution

Impact of renaming a resolution:

JQL queries in filters, boards, or gadgets referencing the resolution name (e.g., resolution = Done) will no longer match issues if the value is renamed (e.g., to Finished).To update:

Go to . Issues > Manage filters

Edit filters to use the new resolution name (e.g., resolution = Finished). : Renaming a Note resolution affects all projects and requires updating JQL-based configurations.(Source: Atlassian Support Documentation, "Manage resolutions in Jira Cloud")

Why This Fits: Renaming a resolution value impacts that use JQL queries saved filters referencing the old value, requiring updates to maintain functionality, making Option B the correct answer.

Why Other Options Are Incorrect

:

Workflow post functions (Option A):

Extract from Documentation:

Workflow post functionscan set the field (e.g., to ). Resolution Set Issue Resolution Done These post functions typically use the resolution’s internal ID, not its display name, so renaming to does not require changes to post functions. Done Finished

Post functions reference resolution IDs, not names. Renaming a resolution does not affect workflow configurations.

(Source: Atlassian Support Documentation, "Configure advanced work item workflows")

Issue detail view (Option C):

The displays the field value as configured. Renaming to issue detail view Resolution Done updates the display automatically without requiring manual changes to the issue Finished detail view or its configuration (e.g.,issue layout).

Extract from Documentation:

The issue detail view reflects the current resolution name automatically. No changes are needed after renaming a resolution.

(Source: Atlassian Support Documentation, "Configure issue layouts in Jira Cloud")

Issue Statistics gadgets (Option D):

Issue Statistics gadgets(e.g., on dashboards) can display data based on fields like . While gadgets may reference resolution values in their configuration, they Resolution typically use resolution IDs or dynamically update to reflect the renamed value. The impact is less direct than with saved filters, which rely on explicit JQL queries.

Extract

from Documentation:

Gadgets like Issue Statistics use field values or IDs. Renaming a resolution may not require gadget updates unless JQL queries are explicitly used.

(Source: Atlassian Support Documentation, "Manage dashboards in Jira Cloud")

Issues in team-managed projects (Option E):

Extract from Documentation:

Resolutionsare global and apply to both company-managed and team-managed projects. Renaming to updates the value for all issues, including those in team- Done Finished managed projects, without requiring changes to the issues themselves. The change is reflected automatically.

Resolutions are global and apply to all projects. Renaming a resolution updates its display for all issues without requiring issue-level changes.

(Source: Atlassian Support Documentation, "Manage resolutions in Jira Cloud")

Additional Notes:

Renaming a resolution is done in and requires Settings > Issues > Resolutions Jira administrator privileges.

Other JQL-based features (e.g., automation rules, boards) may also be impacted if they reference the resolution name, but are the most commonly affected. saved filters

To minimize impacts, use resolution IDs in JQL queries (e.g., resolution = 10000), though this is less common.

: Atlassian Support Documentation:Manage resolutions in Jira Cloud

Atlassian Support Documentation:Configure advanced work item workflows

Atlassian Support Documentation:Configure issue layouts in Jira Cloud

Atlassian Support Documentation:Manage dashboards in Jira Cloud

Question #:3 - [Workflows and Automation]

An automation rule should send an email with the issue key in the subject line. Identify the correct syntax to use in the Send Email action.

{{triggerIssue.issuekey}}

{{issue.key}}

{{issueKey}}

{issue.issuekey}

issue.key

Answer: B

Explanation

In Jira Software Cloud, automation rules use to reference issue fields, such as the issue key, in smart values actions like sending emails. The correct syntax for referencing the issue key in the action’s subject Send Email line is (Option B). {{issue.key}}

Explanation of the Correct Answer (Option B):

Exact Extract from Documentation:

Use smart values in automation rules

The smart value retrieves the issue key (e.g., PROJ-123) of the issue that triggers or {{issue.key}} is processed by the automation rule. This can be used in the subject line of the action Send Email to include the issue key dynamically.

Smart values allow you to access issue fields and other data in automation actions. To reference the issue key:

Use to insert the issue key (e.g., PROJ-123) in fields like email subjects or {{issue.key}} bodies.Examples:

Email subject: Issue {{issue.key}} Updated

Output: Issue PROJ-123 Updated : Smart values are enclosed in double curly braces Note ({{}}). Use dotnotation to access fields (e.g., {{issue.key}}, {{issue.summary}}).(Source: Atlassian Support Documentation, "Use smart values in Jira automation")

Why This Fits: The syntax is the standard way to reference the issue key in Jira {{issue.key}} automation, making it the correct choice for the action’s subject line. Send Email

Why Other Options Are Incorrect:

{{triggerIssue.issuekey}} (Option A):

The smart value refers to the issue that triggers the rule, but the field is , {{triggerIssue}} key not . The correct syntax is , not . issuekey {{triggerIssue.key}} {{triggerIssue.issuekey}} Additionally, is sufficient for most rules unless specifically targeting the {{issue.key}} trigger issue in a branched rule.

Extract from Documentation:

Use to reference the key of the issue that triggers the rule. is used for the {{triggerIssue.key}} {{issue.key}} current issue in the rule’s context.

(Source: Atlassian Support Documentation, "Use smart values in Jira automation")

{{issueKey}} (Option C):

Extract from Documentation:

Smart values require dot notation for field access (e.g., ). is not a {{issue.key}} {{issueKey}} valid smart value, as it does not reference a specific field.

Smart values must reference valid fields using dot notation (e.g., {{issue.key}}, {{issue.summary}}). Single variables like {{issueKey}} are not supported.

(Source: Atlassian Support Documentation, "Use smart values in Jira automation")

{issue.issuekey} (Option D):

Extract from Documentation:

The syntax uses single curly braces and instead of , which is incorrect. Smart issuekey key values require double curly braces ({{}}) and the correct field name ( ).key

Smart values use double curly braces ({{}}) and standard field names (e.g., {{issue.key}}). Incorrect formats like {issue.issuekey} will not work.

(Source: Atlassian Support Documentation, "Use smart values in Jira automation")

issue.key (Option E):

Without curly braces, is treated as plain text, not a smart value. It will not resolve issue.key to the issue key and will appear literally in the email subject.

Extract from Documentation:

Smart values must be enclosed in {{}} to be evaluated. Plain text like issue.key will not resolve to a field value.

(Source: Atlassian Support Documentation, "Use smart values in Jira automation")

Additional Notes:

:

The action in Jira automation allows smart values in the subject and body to Send Email dynamically include issue data.

If the rule involves branching or multiple issues, refers to the current issue in the {{issue.key}} rule’s context, while refers to the triggering issue. For a simple email rule, {{triggerIssue.key}} is typically sufficient. {{issue.key}}

Atlassian Support Documentation:Use smart values in Jira automation

Atlassian Support Documentation:Automate your Jira Cloud instance

Question #:4 - [Workflows and Automation]

An automation rule is configured as shown:

When: Rule is triggered on All comments

If: Initiator is in Developers

Then: Transition the issue to DEVELOPMENT

If: Initiator is in Reviewers

Then: Transition the issue to REVIEWYou are only in the Reviewers project role. What happens when you comment on an issue?

The rule does not execute.

The issue transitions to REVIEW.

The rule executes but does not perform any actions.

The issue transitions to DEVELOPMENT.

Answer: B

Explanation

The automation rule is triggered when any comment is added to an issue and checks the initiator’s project role to determine the action. Since you are only in the project role, commenting on an issue will trigger Reviewers the rule, and the issue will transition to based on the rule’s logic. REVIEW

Explanation of the Correct Answer (Option B):

The rule is triggered by , meaning any comment on an issue activates the rule. All comments

The rule has two conditions:If

If the initiator (the user who commented) is in the project role, the issue Developers transitions to .DEVELOPMENT

If the initiator is in the project role, the issue transitions to Reviewers REVIEW

Since you are only in the project role, the second condition is met when you Reviewers If comment, and the action transitions the issue to Then REVIEW

Exact Extract from Documentation:

Configure automation rules

Automation rules consist of triggers, conditions, and actions.

Trigger: Defines when the rule runs (e.g., Comment Added).

Condition: Checks criteria like user roles (e.g., Initiator is in Reviewers).

Action: Performs tasks like transitioning an issue.Conditions are evaluated sequentially, and the corresponding action is executed if the condition is met. If multiple conditions apply, each matching condition’s action is executed unless restricted by rule logic. :Note The initiator is the user who triggers the rule (e.g., the commenter).(Source: Atlassian Support Documentation, "Automate your Jira Cloud instance")

Why This Fits: As a member of the project role, your comment satisfies the Reviewers If: condition, triggering the action, Initiator is in Reviewers Transition the issue to REVIEW making Option B the correct answer.

Why Other Options Are Incorrect:

The rule does not execute (Option A):

The rule is triggered by , so any comment, including yours, will execute the All comments rule. The issue is not whether the rule executes but what action it performs.

Extract from Documentation:

A trigger activates the rule whenever a comment is added to an issue, regardless of the user’ Comment Added s role.

(Source: Atlassian Support Documentation, "Jira automation triggers")

The rule executes but does not perform any actions (Option C):

The rule executes and performs the action because you Transition the issue to REVIEW are in the project role, which satisfies the second condition. The rule will not Reviewers If skip actions if a condition is met.

Extract from Documentation:

If a condition in an automation rule is met, the associated action is executed unless restricted by additional logic.

(Source: Atlassian Support Documentation, "Automate your Jira Cloud instance")

The issue transitions to DEVELOPMENT (Option D):

The transition is only triggered if the initiator is in the project DEVELOPMENT Developers role. Since you are only in the role, this condition is not met, and the issue will Reviewers not transition to .DEVELOPMENT

Extract from Documentation:

Conditions like check the user’s project role membership. Only the actions for matching Initiator is in [Role] conditions are executed.

(Source: Atlassian Support Documentation, "Jira automation conditions")

Additional Notes:

The rule assumes the and statuses exist in the project’s workflow and DEVELOPMENT REVIEW that transitions to these statuses are valid from the issue’s current status.

If you were in both and roles, both actions could execute sequentially, but Developers Reviewers the question specifies you are only in , so only the transition applies. Reviewers REVIEW :

Atlassian Support Documentation:Automate your Jira Cloud instance

Atlassian Support Documentation:Jira automation triggers

Atlassian Support Documentation:Jira automation conditions

Question #:5 - [System Administration and Administering Jira]

A Jira administrator makes the following changes to User Default Settings:

• Default sharing for filters and dashboards is set to Public.

• Autowatch own issues is set to Yes.

Which two statements are definitely true? (Choose two.)

Only newly created dashboards will reflect the new default setting.

Saved filters using the old default setting will reflect the new default setting.

Only newly created saved filters will reflect the new default setting.

D. All users will become watchers of issues they have created in the past.

Answer: A C

Explanation

The changes to affect the default behavior for new filters, dashboards, and issue User Default Settings watching. The two statements that are definitely true areonly newly created dashboards will reflect the new (Option A) and (Option default setting only newly created saved filters will reflect the new default setting C), as these settings apply to new creations only.

Explanation of the Correct Answers:

Only newly created dashboards will reflect the new default setting (Option A):

Exact Extract from Documentation:

Manage user default settings

Changing the to in User Default Settings

Default sharing for filters and dashboards Public sets the default sharing option for newly created dashboards to . Existing dashboards Public retain their original sharing settings (e.g., Private, Group) and are not affected by the change. Only dashboards created after the setting is updated will default to .Public

Default sharing for filters and dashboards and dashboards.

The setting determines the default sharing option for new filters

To configure: Go to . Settings > System > User default settings Set to , , or another option. : Default sharing Public Private Impact

Only newly created filters and dashboards use the new default setting.

Existing filters and dashboards retain their original sharing settings. : Requires Note Jira administrator permissions.(Source: Atlassian Support Documentation, "Manage user default settings in Jira Cloud")

Why This Fits: The change to sharing applies only to newly created dashboards, Public making Option A definitely true.

Only newly created saved filters will reflect the new default setting (Option C):

Similarly, the setting affects the default sharing option for newly created Default sharing saved filters. Filters created after the change will default to , but existing filters keep Public their original sharing settings (e.g., Private, Group).

Exact Extract from Documentation:

Manage user default settings

Changing the to applies to new filters and dashboards only. Default sharing for filters and dashboards Public

Impact:

Existing saved filters are not updated to the new default sharing setting.

New filters created after the change will default to .Public (Source: Atlassian Support Documentation, "Manage user default settings in Jira Cloud")

Why Other Options Are

Why This Fits: The change to sharing applies only to newly created saved filters, Public making Option C definitely true.

Incorrect

:

Saved filters using the old default setting will reflect the new default setting (Option B):

Extract from Documentation:

Existing saved filters do not automatically update to the new default sharing setting (Public ). They retain their original sharing configuration (e.g., Private, Group) set at creation, so this statement is false.

Existing filters and dashboards are unaffected by changes to the setting. Only new creations Default sharing use the updated default.

(Source: Atlassian Support Documentation, "Manage user default settings in Jira Cloud")

All users will become watchers of issues they have created in the past (Option D):

Setting to enables autowatching for issues created the setting Autowatch own issues Yes after is changed. It does not retroactively add users as watchers to issues they created in the past. For past issues, users must be manually added as watchers or an automation rule must be created, so this statement is not definitely true.

Extract from Documentation:

The setting applies to issues created after the setting is enabled. It does not affect Autowatch own issues previously created issues.

(Source: Atlassian Support Documentation, "Manage user default settings in Jira Cloud")

Additional Notes:

Configuring requires privileges and is done in

User Default Settings Jira administrator Settings > System > User default settings

Users can override the default sharing setting when creating filters or dashboards (e.g., choosing Private instead of Public).

To retroactively apply autowatching to past issues, a bulk operation or automation rule would be needed, but this is not automatic.

Atlassian Support Documentation:Manage user default settings in Jira Cloud

Question #:6 - [Advanced User Features]

You need to find unresolved issues assigned to suspended users. Identify the correct JQL query.

resolution is EMPTY AND assignee in inactiveUsers()

statusCategory != Done AND assignee not in organizationMembers()

resolution = Unresolved AND assignee changed to inactive

statusCategory = Done AND assignee not in activeUsers()

resolution = EMPTY AND assignee not in membersOf("jira-software-users")

Answer: A

Explanation

To find unresolved issues assigned to suspended users in Jira Software Cloud, the JQL query must check for issues with no resolution (unresolved) and an assignee who is inactive (suspended). The correct query is (Option A), as it uses the appropriate field ( resolution is EMPTY AND assignee in inactiveUsers() ) and function ( ) to identify these issues. resolution inactiveUsers()

Explanation of the Correct Answer (Option A):

Unresolved issues: In Jira, an issue is considered unresolved if its field is empty (i.e., resolution not set to Resolved, Done, or similar). The JQL clause identifies unresolved resolution is EMPTY issues.

Suspended users: Suspended users are those whose accounts are inactive (e.g., deactivated or removed from the organization). The function returns all inactive users in the Jira inactiveUsers() instance. The clause filters for issues assigned to these users. assignee in inactiveUsers()

Combined query: returns all unresolved resolution is EMPTY AND assignee in inactiveUsers() issues assigned to inactive users.

Exact Extract from Documentation:

Search for issues using JQL

resolution is EMPTY: Finds issues with no resolution set (unresolved issues).

assignee in inactiveUsers(): Finds issues assigned to users who are inactive (e.g., deactivated or suspended).Example:

resolution is EMPTY AND assignee in inactiveUsers() returns unresolved issues assigned to inactive users. : The function is specific to Jira Cloud and includes Note inactiveUsers() users who are no longer active in the instance.(Source: Atlassian Support Documentation, "Advanced searching - functions reference")

Why This Fits: The query correctly uses for unresolved issues and resolution is EMPTY for suspended users, making Option A the correct answer. inactiveUsers()

Why Other Options Are Incorrect:

statusCategory != Done AND assignee not in organizationMembers() (Option B):

statusCategory != Donechecks the status category (e.g., To Do, In Progress) but is less precise than , as some statuses in non-Done categories may still be

resolution is EMPTY resolved. is incorrect, as assignee not in organizationMembers() organizationMembers() is not a valid JQL function in Jira Cloud, and it would not specifically target inactive users.

Extract from Documentation:

statusCategory != Doneis broader than and may include resolved issues. No resolution is EMPTY function exists in JQL. organizationMembers()

(Source: Atlassian Support Documentation, "Advanced searching - fields reference")

resolution = Unresolved AND assignee changed to inactive (Option C):

resolution = Unresolvedis incorrect, as is not a valid resolution value; use Unresolved instead. is invalid, as resolution is EMPTY assignee changed to inactive changed to is not a supported JQL operator for the field. inactive assignee

Extract from Documentation:

Use for unresolved issues. The operator does not support as a value for resolution is EMPTY changed inactive .assignee

(Source: Atlassian Support Documentation, "Advanced searching - operators reference")

statusCategory = Done AND assignee not in activeUsers() (Option D):

statusCategory = Doneis the opposite of what is needed, as it selects resolved or completed issues, not unresolved ones. might include inactive assignee not in activeUsers() users but is less precise than , and the clause makes the inactiveUsers() statusCategory query incorrect.

Extract from Documentation:

statusCategory = Doneselects issues in completed statuses, not unresolved issues. Use forinactiveUsers() precise inactive user filtering.

(Source: Atlassian Support Documentation, "Advanced searching - fields reference")

resolution = EMPTY AND assignee not in membersOf("jira-software-users") (Option E):

resolution = EMPTYis correct, but is assignee not in membersOf("jira-software-users") incorrect, as is a default group for active users with Jira Software jira-software-users access, not a reliable indicator of suspended users. This would exclude active users in the group, not specifically target inactive ones.

Extract from Documentation:

The function checks group membership, not user activity status. Use to find membersOf() inactiveUsers() suspended or deactivated users.

(Source: Atlassian Support Documentation, "Advanced searching - functions reference")

Additional Notes:

The query can be tested in and saved as a filter if needed. Issues > Search for issues inactiveUsers()is specific to Jira Cloud and includes users who are deactivated or removed from the organization.

Ensure the user running the query has permission for the relevantprojects. Browse Projects

: Atlassian Support Documentation:Advanced searching - functions reference

Atlassian Support Documentation:Advanced searching - fields reference

Atlassian Support Documentation:Advanced searching - operators reference

Atlassian Support Documentation:Search for issues using JQL

Question #:7 - [Issue Types, Fields, Screens]

You are configuring an issue layout in a company-managed project. Which statement is true?

You can reuse fields from a team-managed project.

You can copy a layout to another project using the same screen.

You can move any field to the Hidden fields section.

You can move any field to the Context fields section.

Answer: B

Explanation

In a company-managed project, the determines how fields are displayed in the issue view (e.g., issue layout which fields are visible, hidden, or in the context panel). The true statement is thatyou can copy a layout to (Option B), as Jira allows copying issue layouts to streamline another project using the same screen configuration across projects.

Explanation of the Correct Answer (Option B):

Exact Extract from Documentation:

Configure issue layouts in company-managed projects

The in a company-managed project is configured in issue layout Project settings > Issue layout and is tied to a screen (via the screen scheme). Jira allows copying an issue layout to another project that uses the same screen, ensuring consistent field arrangements across projects.

Issue layouts define which fields are displayed, hidden, or placed in the context panel in the issue view.

To copy a layout:

Go to

. Project settings > Issue layout

Select and choose another project that uses the same screen. : The target Copy layout Note project must use the same screen (via its screen scheme) for the layout to be compatible. (Source: Atlassian Support Documentation, "Configure issue layouts in Jira Cloud")

Why This Fits: Copying an issue layout to another project using the same screen is a supported feature, making Option B the correct answer.

Why Other Options Are Incorrect:

You can reuse fields from a team-managed project (Option A):

Fields in team-managed projects are project-specific and cannot be reused in companymanaged projects. Company-managed projects use global custom fields or system fields, managed in . Fields from team-managed projects are Settings > Issues > Custom fields isolated and not accessible.

Extract from Documentation:

Custom fields in team-managed projects are project-specific and cannot be reused in company-managed projects. Company-managed projects use global custom fields.

(Source: Atlassian Support Documentation, "Manage custom fields in Jira Cloud")

You can move any field to the Hidden fields section (Option C):

Not all fields can be moved to the section. System fields like , Hidden fields Summary Issue , and are required and cannot be hidden. Only non-mandatory fields (e.g., Type Status custom fields, non-required system fields) can be hidden.

Extract from Documentation:

In the issue layout, you can hide non-mandatory fields by moving them to the section. Required Hidden fields fields like Summary, Issue Type, and Status cannot be hidden.

(Source: Atlassian Support Documentation, "Configure issue layouts in Jira Cloud")

You can move any field to the Context fields section (Option D):

The section (right panel in the issue view) has restrictions on which fields

Context fields can be placed there. Fields like , , and certain system fields cannot be Summary Description moved to the context panel, as they are designed for the main issue view. Only eligible fields (e.g., custom fields, Labels, Components) can be moved to the section. Context fields

Extract from Documentation:

Context fields and Description cannot be moved to the context panel.

The section is for fields like Labels, Components, or custom fields. Core fields like Summary

(Source: Atlassian Support Documentation, "Configure issue layouts in Jira Cloud")

Additional Notes:

:

Configuring issue layouts requires privileges for the project ( project admin Project settings > ). Issue layout

Copying layouts is useful for maintaining consistency across projects with similar configurations.

Atlassian Support Documentation:Configure issue layouts in Jira Cloud

Atlassian Support Documentation:Manage custom fields in Jira Cloud

Question #:8 - [Advanced User Features]

Christian has a saved filter showing bugs that have not been updated in the past two weeks. He plans to run a bulk operation to change the priority to Highest on all the issues in the filter. Identify one definite outcome of this action.

The saved filter will display no issues.

Filter subscriptions based on the filter will stop sending emails.

Christian will be added as a watcher on all the edited issues.

D. Email notifications will be sent during the bulk operation.

Answer: A

Explanation

Christian’s saved filter shows bugs that have not been updated in the past two weeks, likely using a JQL query like issuetype = Bug AND updated <= -2w. Running a bulk operation to change the priority to on all Highest issues in the filter will update the issues, affecting their timestamp. The definite outcome is that updated the (Option A), as the issues will no longer meet the filter’s criteria after being saved filter will display no issues updated.

Explanation of the Correct Answer (Option A):

Exact Extract from Documentation:

Bulk change issues

The saved filter likely uses a JQL query such as issuetype = Bug AND updated <= -2w, which returns bugs not updated in the past two weeks (i.e., updated timestamp is older than two weeks). When Christian performs a bulk operation to change the priority to , each issue’s Highest updated timestamp is set to the current time, as any edit (including priority changes) updates this field. After the operation, all issues in the filter will have a recent timestamp (e.g., within the updated last few minutes), causing them to no longer satisfy the updated <= -2w condition. As a result, the filter will return no issues.

Bulk operations (e.g., changing priority) update issue fields and metadata, including the timestamp.updated

Impact on filters:

If a filter uses a condition like updated <= -2w, updating issues will change theirupdated timestamp, potentially excluding them from the filter.To perform a bulk change:

Run a filter in . Issues > Search for issues

Select and choose an action (e.g., Edit Issues). Bulk change

Update fields (e.g., Priority to Highest). : Bulk changes trigger the event, Note Issue Updated updating the field.updated (Source: Atlassian Support Documentation, "Bulk change issues in Jira Cloud")

Why This Fits: The bulk operation updates the timestamp of all issues, causing them to updated no longer meet the filter’s updated <= -2w condition, resulting in the filter displaying no issues, making Option A the definite outcome.

Why Other Options Are Incorrect:

Filter subscriptions based on the filter will stop sending emails (Option B):

Filter subscriptions send emails based on the filter’s results and schedule (e.g., daily, weekly). The bulk operation does not disable the subscription or change its configuration; it only affects the filter’s results. If the filter returns no issues after the operation, the subscription will send an email with no results, but it will not stop sending emails entirely.

Extract

from Documentation:

Filter subscriptions send emails based on the filter’s results and schedule. Empty results do not stop the subscription; they result in an empty email.

(Source: Atlassian Support Documentation, "Manage filters in Jira Cloud")

Christian will be added as a watcher on all the edited issues (Option C):

Extract from Documentation:

Adding a watcher during a bulk operation is not automatic. Users are not added as watchers unless explicitly included in the bulk operation (e.g., via an action, which is Add Watcher not part of changing priority). Christian’s user settings or automation rules could theoretically add him as a watcher, but this is not a definite outcome of the priority change.

Bulk operations do not automatically add the user as a watcher. Use the action in abulk Add Watcher operation to add watchers explicitly.

(Source: Atlassian Support Documentation, "Bulk change issues in Jira Cloud")

Email notifications will be sent during the bulk operation (Option D):

Email notifications for the event (triggered by the priority change) depend Issue Updated on the project’s and the recipients configured for the event (e.g., notification scheme watchers, assignee). Notifications are not guaranteed, as they may be disabled or limited to specific users. Thus, this is not a definite outcome.

Extract from Documentation:

Bulk operations trigger the event, but notifications depend on the notification scheme and may Issue Updated not be sent if not configured.

(Source: Atlassian Support Documentation, "Configure notification schemes")

Additional Notes:

The bulk operation requires Christian to have the permission for the issues in the filter. Edit Issues

The filter’s JQL query (e.g., issuetype = Bug AND updated <= -2w) can be verified inIssues > Manage filters

:

To avoid impacting the filter, Christian could modify the JQL to exclude recently updated issues or create a temporary filter for the bulk operation.

Atlassian Support Documentation:Bulk change issues in Jira Cloud

Atlassian Support Documentation:Manage filters in Jira Cloud

Atlassian Support Documentation:Configure notification schemes

Question #:9 - [Advanced User Features]

You run the JQL query shown:

assignee changed from currentUser() TO EMPTY and resolution changed to EMPTY

Which statement is definitely true?

All returned issues are currently unresolved.

All returned issues are currently unassigned.

All returned issues were assigned to you at some point.

All returned issues are currently not assigned to you.

All returned issues were in Done status at some point.

Answer: C

Explanation

The JQL query assignee changed from currentUser() TO EMPTY and resolution changed to EMPTY filters for issues based on their change history for the and fields. The statement that is definitely assignee resolution true is (Option C), as the query explicitly requires that all returned issues were assigned to you at some point the field changed from the current user to assignee EMPTY

Explanation of the Correct Answer (Option C):

The query consists of two conditions:

assignee changed from currentUser() TO EMPTY: This means the issue’s fieldassignee was changed from the current user (the person running the query) to (EMPTY)unassigned at some point in its history. For this condition to be true, the issue must have been assigned to the current user before being unassigned.

resolution changed to EMPTY: This means the field was changed to resolution EMPTY (unresolved) at some point, typically indicating the issue was reopened (e.g., resolution was cleared).

The condition guarantees that all returned assignee changed from currentUser() TO EMPTY issues were assigned to the current user at some point, as the change history explicitly includes a transition from the current user to unassigned.

Exact Extract from Documentation:

Advanced searching - operators reference

CHANGED

The operator searches for issues where a field’s value changed from one value to another.

assignee changed from currentUser() TO EMPTY: Finds issues where the assignee was changed from the current user to unassigned.

resolution changed to EMPTY: Finds issues where the resolution was cleared (e.g., issue was reopened). : The operator examines the issue’s history, not its current Note CHANGED state.(Source: Atlassian Support Documentation, "Advanced searching - operators reference")

Why This Fits: The query’s conditionassignee changed from currentUser() TO EMPTY ensures that all returned issues were assigned to the current user at somepoint, making Option C definitely true.

Why Other Options Are Incorrect:

All returned issues are currently unresolved (Option A):

The condition means the resolution was set to at resolution changed to EMPTY EMPTY some point in the issue’s history, but the issue could have been resolved again later (e.g., resolution set to Done). The query does not check the current resolution state, so this is not definitely true.

Extract from Documentation:

The operator does not guarantee the current state of a field. Use resolution is EMPTY to check if CHANGED issues are currently unresolved.

(Source: Atlassian Support Documentation, "Advanced searching - operators reference")

All returned issues are currently unassigned (Option B):

The condition means the issue was assignee changed from currentUser() TO EMPTY unassigned at some point, but it could have been reassigned to another user later. The query does not check the current assignee state, so this is not definitely true.

Extract from Documentation:

To check if issues are currently unassigned, use assignee is EMPTY. The operator only checks CHANGED historical changes.

(Source: Atlassian Support Documentation, "Advanced searching - fields reference")

All returned issues are currently not assigned to you (Option D):

Extract from Documentation:

The query does not guarantee that issues are currently not assigned to the current user. After being unassigned ( ), the issue could have been reassigned to the current TO EMPTY user again. The current assignee state is not checked, so this is not definitely true.

The operator does not reflect the current field value. Use assignee != currentUser() to check if CHANGED issues are not assigned to the current user.

(Source: Atlassian Support Documentation, "Advanced searching - operators reference")

All returned issues were in Done status at some point (Option E):

Extract from Documentation:

The condition indicates the resolution was cleared (e.g., resolution changed to EMPTY issue reopened), which often follows a resolved state (e.g., Done). However, the query does not explicitly require that the issue was in a status (or had a resolution set) before the Done change to . For example, an issue could have had a resolution set to another value EMPTY or cleared without being in . Thus, this is not definitely true. Done

The condition indicates a resolution was cleared, but it does not guarantee the resolution changed to EMPTY issue was in a specific status like Done.

(Source: Atlassian Support Documentation, "Advanced searching - fields reference")

Additional Notes:

The query examines historical changes, not current states, so assumptions about currentresolution or values are invalid. assignee

To ensure current states, additional conditions like resolution is EMPTY or assignee is EMPTY would be needed.

The query requires the user to have permission for the relevant projects. Browse Projects

:

Atlassian Support Documentation:Advanced searching - operators reference

Atlassian Support Documentation:Advanced searching - fields reference

Atlassian Support Documentation:Search for issues using JQL

Question #:10 - [Issue Types, Fields, Screens]

Requirements for field behavior in a company-managed project are shown:

Issue Type

Attribute (custom field)

Epic

Hidden Story

Optional

Bug Required

What do you need to configure to meet the requirements?

Field configurations

Screens

Custom field contexts

Screen schemes

Answer: A

Explanation

To meet the requirements for the custom field’s behavior (hidden for Epics, optional for Stories, Attribute required for Bugs) in a company-managed project, you need to configure (Option A). field configurations Field configurations define whether a field is required, optional, or hidden for specific issue types.

Explanation of the Correct Answer (Option A):

Field configurationscontrol the behavior of fields (e.g., required, optional, hidden) for different issue types in a company-managed project. To meet the requirements:

For , set the field to . Epics Attribute Hidden

For , set the field to (not required). Stories Attribute Optional

For , set the field to Bugs Attribute Required

This is achieved by creating multiple field configurations (one for each issue type’s behavior) and associating them with a that maps configurations to issue types. field configuration scheme

Exact Extract from Documentation:

Configure field settings

Field configurations define whether fields are required, optional, or hidden for specific issue types. A field configuration scheme maps field configurations to issue types in a project.

To configure:

Go to . Settings > Issues > Field configurations

Create or edit field configurations (e.g., one for Epics, Stories, Bugs).

For each configuration:

Mark a field as to enforce a value. Required

Mark a field as to remove it from screens. Hidden

Leave a field as (default) if not required. Optional

Create a field configuration scheme ( ) Settings > Issues > Field configuration schemes and map configurations to issue types.

Assign the scheme to the project in . : Hide a field for Project settings > Fields Example Epics, make it optional for Stories, and required for Bugs.(Source: Atlassian Support Documentation, "Configure field settings")

Why This Fits: allow you to set the field as hidden, optional, or Field configurations Attribute required for different issue types, directly meeting the requirements.

Why Other Options Are Incorrect:

Screens (Option B):

Screens define which fields appear during issue operations (e.g., Create, Edit, View). While hiding a field on a screen for Epics could make it appear hidden, screens are not issue typespecific unless combined with a . Screens also cannot enforce or screen scheme required behavior, which is handled by field configurations. optional

Extract from Documentation:

Screens control which fields are displayed but do not manage required or optional behavior. Use field configurations for field behavior.

(Source: Atlassian Support Documentation, "Configure screens in Jira Cloud")

Custom field contexts (Option C):

Custom field contexts define the options and default values for a custom field across projects or issue types. They do not control whether a field is hidden, optional, or required, which is managed by field configurations.

Extract from Documentation:

Custom field contexts set options and defaults for fields, not their visibility or required status. Use field configurations for behavior.

(Source: Atlassian Support Documentation, "Manage custom fields in Jira Cloud")

Screen schemes (Option D):

Extract from Documentation:

Screen schemes map screens to issue operations (e.g., Create, Edit) for issue types. They control which fields appear on screens but do not manage whether fields are required or optional, which is handled by field configurations.

Screen schemes assign screens to issue types but do not control field behavior like required or hidden. Use field configurations for this.

(Source: Atlassian Support Documentation, "Configure screen schemes in Jira Cloud")

Additional Notes:

Steps to configure:

Create three field configurations in : Settings > Issues > Field configurations

Epic: Set to . Attribute Hidden

Story: Set to . Attribute Optional

Bug: Set toAttribute Required

Create a field configuration scheme inSettings > Issues > Field configuration schemes and map each configuration to the respective issue type (Epic, Story, Bug).

Assign the scheme to the project inProject settings > Fields

Configuring field configurations requires privileges. Jira administrator

Ensure the custom field is included on the relevant screens (except for Epics, where it is Attribute hidden) to avoid conflicts.

:

Atlassian Support Documentation:Configure field settings

Atlassian Support Documentation:Configure screens in Jira Cloud

Atlassian Support Documentation:Manage custom fields in Jira Cloud

Atlassian Support Documentation:Configure screen schemes in Jira Cloud

About certsout.com

certsout.com was founded in 2007. We provide latest & high quality IT / Business Certification Training Exam Questions, Study Guides, Practice Tests.

We help you pass any IT / Business Certification Exams with 100% Pass Guaranteed or Full Refund. Especially Cisco, CompTIA, Citrix, EMC, HP, Oracle, VMware, Juniper, Check Point, LPI, Nortel, EXIN and so on.

View list of all certification exams: All vendors

We prepare state-of-the art practice tests for certification exams. You can reach us at any of the email addresses listed below.

Sales: sales@certsout.com

Feedback: feedback@certsout.com

Support: support@certsout.com

Any problems about IT certification or our products, You can write us back and we will get back to you within 24 hours.

Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.