Certified-Business-Analyst Practice Test Questions

C.   Use a version control repository

Explanation:

The file name UserStories_v37_final_final_final.docx is a classic sign of manual version tracking, which leads to confusion, duplication, and loss of traceability.

The best practice the Business Analyst (BA) should train the employee on is to use a version control repository (such as Git, SharePoint, Confluence, or a dedicated requirements management tool). This ensures:

Single source of truth — everyone works from the same document.
Automatic version tracking — no need for manual filenames.
Collaboration and auditability — changes are logged, reviewed, and reversible.

Why not the other options?

A. Use standard naming conventions
While standard file naming conventions (like including version numbers or dates) can help keep files organized, they are still a manual and error-prone approach to version control.

Here’s why it’s not ideal in this situation:

• It depends on user discipline — everyone must remember to name files correctly and upload them in the right order.
• It doesn’t prevent duplication — multiple team members can still create “final” versions at the same time.
• It lacks automatic version history — you can’t easily see who changed what or revert to an older version.
• It doesn’t support collaboration — real-time co-editing, change tracking, and merging updates are missing.

✅ When it helps: Naming conventions are useful when storing static files (like signed contracts or exported reports).
❌ When it fails: For living documents such as user stories, which evolve frequently and are updated by multiple contributors.

B. Use acceptance criteria to define success
This concept is completely unrelated to the version control issue described in the question.

Acceptance criteria define how to verify that a user story or requirement has been successfully implemented — e.g., “Given, When, Then” conditions.
They are part of requirements definition and validation, not documentation management or version control.

Teaching the new employee about acceptance criteria would improve requirement quality, but it wouldn’t solve the problem of file version chaos (e.g., final_final_v37.docx).

✅ When it helps: During requirement gathering, refinement, or testing.
❌ When it fails: For managing or organizing project documentation files.

C. Use a version control repository — Why it’s the best answer
A version control system (like Git, Confluence, SharePoint, or Jira attachments) automatically tracks changes, stores historical versions, and allows collaborative editing.

It eliminates the need for manually naming files with version numbers.
Everyone accesses the same “single source of truth” for user stories and documentation.
You can easily see change history, restore previous versions, and avoid duplication or overwrites.

✅ When it helps: Always — for managing evolving project documentation, code, or user stories.
❌ When it fails: Only if the team doesn’t maintain proper permissions or branching practices (rare in documentation workflows).

Reference:
Salesforce Business Analyst Best Practices: “Maintain documentation in a central, version-controlled repository to ensure consistency and traceability.”

Agile / BA Standards (BABOK): “Version control ensures that requirements and documentation remain consistent, traceable, and auditable across changes.”

Summary:
👉 The BA should train the employee to use a version control system — this eliminates the need for messy file naming like “final_final_final” and promotes professional collaboration and traceability.

A.   Gather requirements from end users

Explanation:

When users report an issue after a new Salesforce implementation, the first step for a Business Analyst (BA) is to understand the problem clearly — not to assume the cause or jump to a solution.
By gathering requirements or feedback from end users, the BA can:
Identify what exactly isn’t working or meeting expectations.
Distinguish between a true defect (bug) and a gap in requirements or user misunderstanding.
Collect evidence (screenshots, steps to reproduce, expected vs. actual results) that helps the development and support teams address the issue accurately.
This diagnostic step ensures that any follow-up action (like training or bug fixing) is based on facts, not assumptions.

Why not the other options?
B. Provide additional end user training:
This may be needed later, but it’s premature before knowing the root cause. The issue might be technical, not user error. Providing training first could waste time and resources.

C. Create a high priority bug for a quick fix:
Creating a bug immediately assumes the problem is a system defect, which might not be true. It could be a configuration gap, missing requirement, or even user confusion. Always validate the issue first before escalating.

Reference:
Salesforce Trailhead — Business Analyst Best Practices: “When an issue arises, first analyze and validate user feedback to identify the root cause before recommending a solution.”
BABOK (Business Analysis Body of Knowledge): The first step in issue resolution is elicitation and investigation to ensure the problem is correctly understood.

A.   Change Set Development, Org Development, Package Development

Explanation:

Salesforce officially supports three primary development models as part of its Application Lifecycle Management (ALM) framework. These models dictate how changes are developed, tracked, and deployed between environments (like from a sandbox to production).

Change Set Development: This is a declarative, out-of-the-box model where administrators and developers assemble sets of components (like custom objects, fields, Apex classes) into a "change set" and send them from one sandbox to another or to production. It is simple but can be error-prone for complex projects.

Org Development (also known as Org-Based Development): This model involves making changes directly in a sandbox or developer org and using change sets or other tools for deployment. It's often used for small, quick fixes or in organizations with simple processes. It's characterized by a lack of robust source control integration.

Package Development: This is the modern, recommended model for any significant development. It involves grouping metadata into a "package" (either unmanaged or managed). This model is closely integrated with source control systems and DevOps tools like Salesforce DX (SFDX), providing the highest level of control, repeatability, and team collaboration.

Why B is incorrect: "Rapid Application Development" is a general software development methodology, not a specific Salesforce-supported development model for ALM.

Why C is incorrect: While "Salesforce DX" is the core toolkit that supports the modern Package Development model, and "Flow Builder" is a tool for declarative development, they are not themselves the top-level development models. This option mixes tools with methodologies.

Reference/Key Concept:
This question tests your knowledge of Application Lifecycle Management (ALM) and Development Models on the Salesforce platform. Understanding the differences between Change Set, Org-Based, and Package Development is crucial for a Business Analyst to effectively collaborate with development teams and understand the project's governance and deployment strategy.

C.   Prioritize user stories for the new enhancements for the initial sprints of the project to accommodate business stakeholder requests. Complete existing user stories in the final sprint of the project.

Explanation:

NTO is starting a new phase of work on the Experience Site, with:
Existing backlog items from the previous project, and
New feature requests from business stakeholders.

The BA’s job is to manage scope and priorities so the team can deliver the highest value within the fixed timeline and capacity.

The best approach is to:
Combine the existing backlog items and the new user stories into one product backlog.
Reprioritize everything together based on:
Business value
Dependencies
Risk / effort
MVP/roadmap alignment

For each sprint:
Pull in only what fits team capacity.
If new, higher-priority work is added, push out an equivalent amount of lower-priority work back into the backlog to keep the scope realistic.

That’s exactly what Option B describes, and it reflects solid agile/backlog management.

Why not A or C?
A. Include everything and hire more developers to avoid delays
This assumes you can simply add people to solve a prioritization problem.
It ignores the classic reality that adding people late often increases complexity and coordination overhead (Brooks’ Law).
It’s not an efficient or realistic first move for a BA; the BA should focus on prioritization and scope, not staffing up to avoid making trade-offs.

C. Do new enhancements first, then old backlog items in the final sprint
This assumes all new items are more important than existing backlog items, which may not be true.
Some older backlog items might be critical or tightly related to compliance, stability, or core flows.
Also risky to pack all leftover work into the final sprint, which can create:
Bottlenecks
Increased risk of rollover
Lower quality due to time pressure

This approach doesn’t properly respect value-based prioritization.

Reference
Agile and Scrum best practices recommend:
Maintaining a single, ordered product backlog for all work.
Regular backlog refinement and reprioritization based on business value and team capacity.
When new high-priority work enters the plan, an equivalent amount of lower-priority work is removed or deferred to keep scope manageable.

These principles align directly with Option B, making it the most efficient and realistic way for the BA to manage the new project timeline.

B.   Use performance analyzer to view the assessment

Explanation:

Before jumping into analysis or solutions, the Business Analyst (BA) must first validate and clearly understand the problem.
By confirming the steps to reproduce the issue, the BA ensures:
The issue is consistent and reproducible (not device- or user-specific).
They understand which specific record pages and actions cause slow performance.
The BA can gather enough context (e.g., object type, device, mobile network, Salesforce app version) to provide accurate information for troubleshooting.

This foundational diagnostic step is critical before using tools like the Performance Analyzer or recommending layout changes.

Why not the other options?
A. Create a new page layout for the phone:
❌ This assumes the issue is caused by layout complexity without verifying the cause. Creating new layouts prematurely can waste effort and doesn’t confirm the true source of slowness.

B. Use performance analyzer to view the assessment:
❌ This is a valuable step, but only after confirming and reproducing the issue. The analyzer should be used on a page where the issue is confirmed, ensuring accurate measurement and valid results.

Reference:
Salesforce Help: “Before using performance analysis tools, confirm that the issue can be consistently reproduced, and gather detailed reproduction steps.”

Salesforce Trailhead – Troubleshoot and Improve Performance:
“Reproduce and document the issue before performing detailed performance analysis.”

Summary:
👉 The first step for the BA is to confirm the steps to reproduce the issue — this ensures the problem is real, consistent, and well-documented before applying diagnostic tools or proposing fixes.

B.   Choose subject matter experts as testers and prepare a sandbox with quality test data, test cases, and scripts that match real-world scenarios.

Explanation:

During User Acceptance Testing (UAT), the Business Analyst’s goal is to validate that the solution:
Meets business requirements
Works as expected in real-world scenarios
Is usable and valuable to end users

Option B is the most effective approach because it ensures:
Subject Matter Experts (SMEs) — typically sales reps or managers — test the flow from a user perspective
The sandbox is populated with representative test data, mimicking actual Opportunity and Order Line Item records
Test cases and scripts are aligned with the original user story and acceptance criteria

This approach provides authentic feedback, uncovers edge cases, and builds stakeholder confidence before deployment.

❌ Why not the others?
A. Draft a list of test cases and use “Run flow as another user”:
This is a developer/admin-level debugging tool, not a UAT strategy.
It’s useful for troubleshooting, but doesn’t validate business value or usability.

C. Collaborate with admin and power user to test scalability and maintainability:
Important for technical validation, but not sufficient for user acceptance.
UAT should focus on business functionality, not just system performance.

🔗 Reference
Explore this in the Trailhead module:
📘 User Acceptance Testing

A.   A sales manager wants to be notified when a contract has been submitted with a discount greater than 20% so the manager can approve or decline a discounted price.

Explanation:

Why A is the best acceptance criteria
From the scenario:
Stakeholder needs an approval process on contract submissions.
Sales managers want to see all contracts when the discount is > 20%.
They will decline any contracts with a discount > 25%, but still want visibility into those.
So the key behavioral requirement is:
“When a contract is submitted and its discount is greater than 20%, sales managers must be able to review and decide (approve/decline).”

Option A captures exactly that:
It’s written from the user’s perspective (“A sales manager wants…”).
It describes the trigger condition: discount > 20%.
It describes the expected outcome: they can approve or decline the discounted price.
The fact that managers will always decline >25% can be dealt with by policy or an additional rule, but the core acceptance criteria for the approval process is that all contracts over 20% reach them for review.

Why not B?
B. Users in a sales manager role should have access to a button on contracts to click to approve or decline a contract with a discounted price of 20% or more.
Problems:
It focuses on a UI detail (button) instead of business behavior.
It doesn’t ensure managers are prompted/notified when the discount is >20%; it just says they have a button.
Acceptance criteria should focus on conditions and outcomes, not specific UI mechanics.

Why not C?
C. A sales manager wants to be able to approve contracts with a large discount and they need a validation rule related to contract discounts greater than 25%.
Issues:
Talks about a validation rule for >25%, but
Doesn’t ensure visibility/approval for discounts >20%.
Conflates approval process (workflow) with validation rules (blocking saves).
It doesn’t clearly describe what should happen when discount is between 20% and 25%, which is explicitly important in the scenario.

So C only partially covers the business logic and skips the main approval behavior for the 20–25% range.

📚 Reference
Salesforce and business analysis best practices recommend writing acceptance criteria that clearly define:
The trigger/condition (e.g., “discount > 20%”)
The user role (e.g., “sales manager”)
The expected outcome (e.g., “can review and approve/decline”)

This aligns with standard user story & acceptance criteria patterns frequently used with Salesforce approval processes and documented in Agile/BA guidance (e.g., “As a , when , I need to so that ”).

B.   Power users and top sales earners

Explanation:

When facing organizational resistance (the incoming sales team's reluctance to change), securing alignment and driving adoption requires authority and influence.

Executive Sponsors: These individuals provide the mandate and strategic direction for the merger and the associated technology change. Their support signals that the initiative is a company priority and is non-negotiable, overcoming organizational inertia and resistance. They provide the necessary funding and resources.

Sales Leadership (Managers/Directors): Sales leadership provides the direct influence and accountability over the reluctant sales team. They translate the strategic mandate into operational expectations, reinforce the new processes, and ensure that the team's performance goals are tied to the new system's adoption. Without leadership buy-in, adoption will fail.

❌ Incorrect Answers and Explanations
A. System admin and project manager
Explanation: The System Admin and Project Manager are crucial for execution and delivery (how the work gets done and managed), but they lack the organizational authority to force reluctant end-users to change their entire process or overcome cultural resistance stemming from a merger.

B. Power users and top sales earners
Explanation: Power users and top sales earners are valuable for grassroots adoption (demonstrating the value of the new system and helping with training). However, their influence is typically peer-to-peer. They can show how to use the new system, but they lack the official authority to counter the overarching reluctance or resistance that comes from a major merger and process shift.

📌 References
Salesforce Trailhead: The BA role involves understanding the need for strong sponsorship for change management initiatives.

Module: Salesforce Business Analyst Quick Look (Emphasizes that Executive Sponsors are critical for overcoming resistance and driving adoption).

IIBA BABOK Guide (Business Analysis Body of Knowledge): Chapter 4: Elicitation and Collaboration and Chapter 5: Strategy Analysis. Identifying and securing support from high-authority, high-influence stakeholders (Executive Sponsors and Key Managers) is a mandatory step for any initiative involving significant organizational change and conflict resolution.

A.   Journey Map

Explanation:

UC wants to limit the number of interactions a customer has during the lifecycle and the project leader wants the BA to visually illustrate the lifecycle from the customer’s perspective.
That is exactly what a Journey Map is for:
It shows the end-to-end customer lifecycle (e.g., issue reported → case created → updates → resolution → follow-up).
It includes touchpoints/interactions (calls, chats, emails, portal visits, etc.).
It helps identify where there are too many interactions, friction, or delays.
Perfect for deciding where to streamline and reduce unnecessary contacts.

So the best document for this request is A. Journey Map.

Why not B or C?
B. Heat Map
A heat map is more about highlighting areas with high volume, risk, or impact (e.g., lots of issues in one region or step).
It doesn’t inherently show the sequence of customer interactions across the lifecycle.

C. Process Map
A process map shows internal steps and flows (who does what, in what order, in which system).
It’s more system/operations-focused than customer-experience-focused.
Helpful, but the question emphasizes customer interactions and visually illustrating the customer case lifecycle from their point of view, which is better captured in a journey map.

📚 Reference
Salesforce and CX/BA best practices describe a Customer Journey Map as a tool that:
Visualizes the customer’s end-to-end experience across channels and interactions.
Helps identify pain points, redundant touchpoints, and opportunities to reduce effort and improve satisfaction.

This is widely recommended when organizations want to analyze and improve the customer experience across Service Cloud and Experience Cloud touchpoints, especially when the goal is to limit or optimize customer interactions during a lifecycle.

A.   Make the template user-friendly and accessible only by members of the account team.

Explanation:

A well-documented requirement should be clear, concise, and ideally, testable. The stakeholder's request has two parts:
The template must be user-friendly.
The template must be accessible only by members of the account team.

A. Make the template user-friendly and accessible only by members of the account team. This option is the only one that fully captures both parts of the stakeholder's request. It directly combines the non-functional requirement ("user-friendly") with the functional security requirement ("accessible only by members of the account team").

Why other options are incorrect
B. The sales manager can make the template user-friendly. This option misattributes the responsibility. The sales manager is the stakeholder stating the need, not the person responsible for making the template user-friendly. The business analyst and development team would be responsible for designing and building a user-friendly solution.

C. Accessible by members of the account team. This option only captures one part of the requirement (accessibility) and omits the other equally important part ("user-friendly"). A complete requirement must include all key components of the stakeholder's request.