Free Salesforce Platform Development Lifecycle and Deployment Architect Practice Test Questions

Explanation

The correct answer is D. The CTO needs ongoing, real-time visibility into the work of multiple offshore agile teams. A virtual Kanban board tool (such as Jira, Trello, Azure DevOps Boards, or similar) provides a continuously updated, visual view of work items as they move through stages (backlog, in progress, review, done). This gives the CTO the ability to follow and measure progress at any time, without depending on scheduled communications. It also supports agile best practices, metrics (cycle time, throughput, WIP), and scaling across distributed teams. It is the most transparent, scalable, and low-friction solution for this scenario.

Why the Other Options Are Incorrect

A. Request the offshore teams to send daily emails to the CTO with the progress of the teams.
– Daily emails are manual, unstructured, and hard to aggregate or compare across multiple teams. They create email overload for the CTO, provide only a snapshot at a point in time, and are not real-time or measurable. They also do not integrate with agile metrics or workflows, so they fail to deliver the level of transparency and measurement the CTO needs.

B. Schedule a daily stand-up meeting with representatives of all offshore teams to share the progress of the teams.
– Daily stand-ups with representatives from all offshore teams would be time-consuming, difficult to coordinate across time zones, and would scale poorly as the number of teams grows. It also provides only verbal, ephemeral updates, not a persistent, measurable record of progress. While daily stand-ups are useful within a team, using them as the CTO's primary transparency mechanism is inefficient and not scalable.

C. Ask the offshore teams to add their progress and status in a shared spreadsheet.
– A shared spreadsheet is a static, manually updated artifact that quickly becomes stale and error-prone. It lacks the visual workflow, real-time updates, and agile metrics that a Kanban tool provides, and it does not scale well for multiple teams. It offers only a weak approximation of transparency compared to a purpose-built Kanban board.

Reference

Salesforce Architect documentation on Agile Delivery and Distributed Team Governance; Salesforce recommended practices for scaling agile with virtual boards and work management tools; industry agile frameworks (Scrum, Kanban) guidance on transparency and visualization of work.

Explanation

The correct answer is A. UC's existing multi-org strategy exists specifically because its BUs share global customers and need real-time integration with a customer 360-degree view org. The new BU, however, does not share customers with the other BUs and needs flexibility in its business processes. Since the key driver for integration (shared customers) is absent, there is no need to build custom integrations or connect to the customer 360-degree view org. A new stand-alone Salesforce org gives the new BU maximum flexibility to define its own processes without the architectural overhead, governance complexity, and cost of cross-org integration. This aligns the org strategy with the actual business need.

Why the Other Options Are Incorrect

B. Deploy the new BU in customer 360-degree view org, and read and write customer information from it without need of custom integration.
– The customer 360-degree view org exists to consolidate shared customers across the four integrated BUs. Since the new BU does not share customers, there is no reason to place it in this org. Doing so would mix unrelated business processes into the master data org, complicating governance, sharing, and release management, and it does not match the BU's independence requirement.

C. Use the same Salesforce org of another BU that shares geographical localization with the new BU.
– Sharing a region is not a valid reason to share an org. The existing BU orgs were designed around shared customers and cross-BU processes, not geography. Co-locating the new BU in another BU's org would force a shared process model (since orgs impose a single set of processes, sharing rules, and metadata), which directly conflicts with the new BU's need for process flexibility. It would also create coupling with an unrelated BU.

D. Use a new Salesforce org for the new BU, and customize integration so that it reads and writes customer information from the customer data org.
– While this does create a separate org (good for flexibility), it adds unnecessary custom integration. Since the new BU does not share customers, there is no business value in reading/writing customer data with the customer 360-degree view org. This adds cost, complexity, latency, and maintenance overhead for no benefit, so it is not the recommended strategy.

Reference

Salesforce Architect documentation on Multi-Org Strategy and Org Strategy Decision Frameworks; Salesforce Well-Architected Framework (Integration and Operational Excellence); Salesforce recommended practices for choosing org strategy based on shared data, process alignment, and business unit independence.