Certified-Business-Analyst Practice Test Questions

Explanation:

Salesforce sandboxes have specific storage allocations based on their type. A Developer Pro Sandbox is intended for development and quality assurance tasks by small teams and includes a copy of your production organization's metadata.

Why D is correct:
The standard storage limit for a Developer Pro Sandbox is 1 GB of data storage. This is a key detail to know for environment planning.

Why A, B, and C are incorrect:

A. 300MB: This is too small and does not correspond to any standard sandbox type.
B. 200MB: This is the standard data storage limit for a Developer Sandbox, not a Developer Pro Sandbox.
C. 2GB: This is too large. The next common tier up is a Partial Copy Sandbox, which has 5 GB of data storage.

Key Concept:
This is a test of specific Salesforce Platform knowledge regarding Sandbox Types and Limits. A Business Analyst should be familiar with the different sandbox environments available (Developer, Developer Pro, Partial Copy, Full) and their key characteristics, as this is crucial for planning the development, testing, and release strategy of a project.

Explanation:

For a process about moving orders from the warehouse to the customer, the best subject matter expert is the person who:

- Oversees warehouse operations
- Understands order fulfillment, shipping, and logistics
- Knows where delays, handoffs, and errors currently occur
- Has insight into goals (faster delivery, fewer errors, lower costs) and pain points
That’s the Supply Chain Manager.
They can help the BA:
- Confirm the current fulfillment process (pick, pack, ship, delivery)
- Identify bottlenecks between warehouse, carriers, and customers
- Define what a better future state looks like in the context of Commerce Cloud

Why not A or B?

A. Sales manager:
Focused more on selling and order creation, not the physical movement of goods from warehouse to customer.
Useful for upstream steps, but not the main SME for warehouse-to-customer logistics.
B. Chief financial officer (CFO):
Focused on financial performance, budgeting, and reporting.
May care about costs and margins, but won’t know the operational details of the fulfillment process.

So to deeply understand and improve the warehouse → customer order flow, the BA should work primarily with the Supply Chain Manager → C.

Explanation:

✅ Why A. is correct
In Agile and Salesforce project contexts, Acceptance Criteria and Definition of Done (DoD) serve distinct but complementary purposes, and they are not interchangeable:
🔹 Acceptance Criteria (personal perspective)
- Written per user story
- Expressed from the persona’s point of view
- Define what must be true for the story to be accepted by the product owner or end user
Example: “Given I am a recruiter, when I submit a candidate, I see a confirmation message.”
🔹 Definition of Done (overall perspective)
- Applies across all stories or features
- Represents the team’s shared agreement on what “done” means
- Includes technical and quality standards, such as:
- Code committed and peer-reviewed
- Unit tests passed
- Deployed to staging
- Documentation updated
By using the personal perspective for acceptance criteria and the overall team perspective for DoD, the BA ensures clarity, alignment, and traceability across the Heroku project lifecycle.

❌ Why not the others?

❌ B. Create one consolidated set of documentation as the two terms are synonymous
They are not synonymous. Merging them would blur the line between story-specific validation and team-wide delivery standards, leading to confusion and missed expectations.
❌ C. Include the overall perspective for acceptance criteria and the persona's perspective for definition of done
This reverses the correct alignment. Acceptance criteria must reflect user needs, while DoD reflects team-wide delivery readiness.

📘 Reference
Explore this in the Trailhead module:
📘 Agile Basics for Salesforce

Explanation:

The project requires visibility for a diverse, cross-functional team (BA, Solution Architect, Lead Developer, QA Lead, etc.) and is constantly in motion (Agile lifecycle).

Common Repository: A shared, single source of truth (like Jira, Azure DevOps, Asana, or Salesforce DevOps Center) is the best practice in Agile. It allows all team members to:

- Access the most current version of every user story instantly.
- View the status of a story (e.g., To Do, In Progress, In Review, Done).
- Track the change history (who made what change and when), ensuring transparency and alignment.

Visibility and Collaboration: This approach fosters the necessary collaboration for a cross-functional team by providing immediate and consistent visibility, which is essential for developers, testers, and architects to coordinate their work.

❌ Incorrect Answers and Explanations

B. Allow each team member to merge all user stories at the end of user acceptance testing.
This concept is a conflation of version control (like Git), which is used for code, with requirements management. User stories should be visible and refined continuously, not merged at the end of UAT. This action would prevent developers and QAs from knowing what to build or test throughout the project.
C. Send emails to stakeholders with all of the changes to the user stories
Sending emails for every change is highly inefficient and quickly leads to information overload, causing team members to ignore updates and rely on outdated information. The purpose of a repository is to allow users to pull information as needed, rather than forcing the BA to push every detail, which is neither scalable nor a best practice for managing live requirements.

Explanation:

In Agile projects, visibility and accessibility of user stories are crucial. Simply receiving verbal acceptance and updating a personal spreadsheet does not ensure the development team can track or access the latest status.
Shared repository benefits:
- Centralized location for all user stories.
- Real-time visibility for all team members.
- Version control and audit trail for changes.
Tools commonly used: Jira, Azure DevOps, Rally, or Salesforce Agile Accelerator.
In this scenario, the root problem is that developers cannot confirm which stories are ready because the spreadsheet is not a shared, accessible tool.

❌ Why the Other Options Are Incorrect:

B. The definition of done of the user stories was unclear
The Definition of Done (DoD) specifies when a story is complete (testing, documentation, approvals).
Here, the problem is not about story completion but knowing which stories are ready to start.
Even if the DoD was unclear, developers would still see the stories marked as “Ready for Development” if they were in a shared repository.
C. The user stories were linked to the incorrect business process map
Mislinking might cause context confusion, but it does not prevent developers from seeing which stories are ready.
The core issue is accessibility—the spreadsheet is not shared—so the status update is not visible to the team.

🔍 Reference:
Trailhead: Agile for Business Analysts
BABOK Guide v3: Requirements and user stories should be managed in a shared repository to ensure visibility, traceability, and version control.

Explanation:

At this point, here’s what we know:

The business need is already clear:
- Analyze sales team data in Salesforce.
The blocking problem:
- The data science team has found data quality issues.
As the BA coming in during initial discovery, your first job is to:
- Clarify exactly what’s wrong with the data
- Is it incomplete (missing fields)?
- Inaccurate (wrong values)?
- Inconsistent (different formats, naming, picklist misuse)?
- Duplicated?
- Not timely?
- Document these issues clearly
- Which objects? (Accounts, Opportunities, Contacts, Activities, etc.)
- Which fields?
- How severe?
- How often?
Talking to the data science team first gives you a concrete, fact-based starting point you can then take to sales users, admins, and leadership as you explore root causes and potential fixes (process, validation rules, training, etc.).
That’s exactly what Option C says.

Why not A or B as the first step?

A. Shadow the sales team to observe process for entering data into Accounts and Opportunities.
This is a great next step, but not the first.
You should first know what specific issues to watch for.
Once you understand the data problems, you can shadow with a purpose:
- “I know Stage and Close Date are often wrong; let me see how they’re being entered.”
B. Meet with the executive leadership team to accurately understand the business need.
The high-level business need is already clear: analyze sales data.
The specific problem now is data quality, which the data science team has already flagged.
Going to execs first doesn’t help you understand the actual issues in the data.
So the best first move is to understand and document the data quality issues identified by the data science team, then expand discovery to processes, people, and governance from there → C.

Explanation:

When stakeholders disagree on the specific steps of a current process, it often means there are multiple informal or personal variations in practice. The most effective way to break this deadlock is to shift the focus from the contentious internal steps to the unambiguous, external boundaries of the process.

Why B is correct:
By first agreeing on the inputs (what triggers the process) and the outcomes (what defines its successful completion), the BA establishes a fixed start and end point that everyone can accept. This creates a shared framework. Once the boundaries are set, the team can more objectively work backwards and forwards to map the necessary steps that connect the input to the outcome, reconciling their differences within an agreed-upon scope.

Why A is incorrect:
A RACI chart is used to clarify roles and responsibilities for decision-making and tasks within an already defined process. It is a solution for confusion about who does something, not for resolving disagreement about what the process steps are. You cannot define "who is accountable" for a step until you first agree that the step exists.

Why C is incorrect:
Brainstorming future efficiency is a "future state" activity. The immediate task is to document the "current state." Jumping to solutions and improvements will only further entrench stakeholders in their differing views of the ideal process, making it harder to agree on what is actually happening now. You must agree on the "as-is" before you can design the "to-be."

Key Concept:
This question tests the BA's skill in Facilitation and Conflict Resolution during process analysis. The technique of starting with inputs and outputs is a foundational method for scoping a process and building consensus. It is a core component of techniques like SIPOC (Suppliers, Inputs, Process, Outputs, Customers), which is specifically designed to gain a high-level, agreed-upon understanding of a process before diving into granular, and often disputed, details.

Explanation:

✅ Correct answer: B. Circulate the requirements to stakeholders, incorporate feedback, and obtain sign-off.
To validate that the requirements meet the goal of creating an engaging Experience Cloud site, the BA needs to:
Make sure the requirements:
- Reflect the agreed business goals (engagement, self-service, brand, etc.)
- Cover the needs of key stakeholders and customer personas
- Confirm that all relevant stakeholders agree:
“Yes, this is what we need this site to do.”
“Yes, these requirements support our goal.”
That’s exactly what Option B describes:
Circulate the requirements to stakeholders, incorporate feedback, and obtain sign-off.
This ensures alignment and shared understanding before build begins.

Why not A or C?

A. Survey customers to confirm whether the new site meets their requirements
This is something you’d do after the site (or a prototype/MVP) exists — it’s solution validation, not requirements validation.
At the requirements stage, customers typically don’t see the full site yet.

C. Conduct a whiteboarding session to ensure the requirements are accurate
Whiteboarding is great for exploring and drafting requirements early on.
But the question is about validating that the requirements meet the goal and ensuring alignment.
That requires formal review with stakeholders, feedback, and ultimately sign-off, which is best captured in B.

Reference
Business analysis and Salesforce project best practices (including those reflected in the Salesforce Business Analyst exam guide and the IIBA BABOK) emphasize that after requirements are elicited and documented, the BA should:
- Review requirements with stakeholders,
- Incorporate their feedback, and
- Obtain formal approval/sign-off
to confirm that the requirements correctly reflect business goals and stakeholder needs before moving into design and build.

Explanation:

✅ Why C. is correct
When the executive team shares high-level challenges but lacks detail, the Business Analyst should go directly to the source — the sales team — to:
- Observe real-world workflows and pain points
- Understand how issues like opportunity funnel breakdowns, data hygiene gaps, and forecasting inaccuracies manifest in daily operations
- Capture goals, frustrations, and unmet needs from the user’s perspective
- Build empathy and context for writing accurate, actionable user stories
A ride-along is a powerful discovery technique that grounds the BA’s understanding in actual behavior, not assumptions or secondhand summaries.

❌ Why not the others?

❌ A. Clone the features of the legacy solution within the new Sales Cloud org
This risks replicating broken processes. The goal of a transformational project is to improve, not copy. Without understanding the root causes, cloning features could perpetuate existing issues.

❌ B. Start writing epics and user stories that discuss the challenges mentioned
Writing stories without deep discovery leads to vague or misaligned requirements. The BA needs firsthand insight before translating challenges into backlog items.

📘 Reference
Explore this in the Trailhead module:
📘 Business Process Mapping

Explanation:

When a Business Analyst discovers a related need from another team (Operations) that aligns closely with the current project (Sales Email Integration), the goal is to manage scope efficiently, leverage existing work, and avoid rework or siloed solutions in the future.
C. Include the operations team during discovery. The best approach is to proactively involve the operations team during the initial discovery and requirements gathering phases of the existing sales project. Email integration often involves common underlying architecture, security settings, or configuration points. By including them early, the BA can gather their foundational requirements, identify commonalities, understand potential conflicts, and design a more holistic solution that serves both teams efficiently, even if the operations team's features are implemented in a later phase. This ensures the solution is scalable and avoids costly rework later.

Why other options are incorrect:

A. Proceed with the sales team's project as planned. Proceeding without acknowledging the operations team's needs risks building a siloed solution that does not meet the future needs of the operations team, potentially leading to expensive re-implementation or integration challenges later.
B. Start project work for the operations team. The operations team's need is "in the near future," while the sales team's project is current. Starting a second project immediately adds complexity, divides resources, and might violate project priorities. The efficient path is to incorporate their needs into the initial discovery for a unified approach.