P_BTPA sample questions & answers

Dún Laoghaire MedTech, an Irish medical-device manufacturer, is designing a BTP integration between its shop-floor quality system and a cloud SAP application that records device-batch release. During peak production runs the shop-floor system emits release events in short, dense bursts, and the cloud application occasionally applies back-pressure or briefly rejects calls under load. A first prototype used a synchronous request-and-wait call from the shop floor to the platform: when the cloud side slowed, shop-floor operators saw the interface freeze, some events were retried by hand, and a few batch-release records appeared twice. The architect must recommend how the platform mediates this flow so no release event is lost during a burst and duplicate release records cannot be created, while keeping the shop-floor system decoupled from the cloud application's momentary availability. Auditors require that every device batch is released exactly once and that a burst never blocks the production line. The design must remain aligned to the integration advisory methodology and fit the platform's integration tooling without custom point-to-point coupling.

Which integration design best satisfies the reliability and decoupling requirements for the bursty release flow?

Andes Roast Collective, a Colombian specialty-coffee retailer, extends a standard SAP cloud application on BTP to add a custom loyalty calculation. The delivery team, under time pressure, built the side-by-side extension so that it reads and writes several internal database fields of the standard application directly, because those fields were reachable and convenient during the sprint. The extension works today. The architect knows the SAP application is a continuously delivered cloud service that receives regular updates, and reviews show that some of the internal fields the extension depends on are not part of any published, stable interface. Leadership wants the loyalty feature to keep the digital core standard and to survive the vendor's ongoing update cycle without emergency rework each time the application changes. The architect must recommend how the extension should obtain and write the data it needs so the core stays clean and the extension stays lifecycle-safe across updates, without abandoning the side-by-side approach that already isolates the custom logic.

What should the architect recommend to make the extension resilient to the application's ongoing update cycle while preserving clean core?

Savanna Micro-Credit, a Kenyan consumer-lending fintech, wants to use a BTP AI capability to draft the written adverse-action reason a loan officer gives an applicant who is declined. A pilot fed the applicant file to a generative model, which produced fluent explanations — but in review some drafts cited factors that were not in the applicant's data and occasionally contradicted the actual decline reason, and regulators require every stated reason to be accurate and traceable to real decision inputs. The lending decision itself is made by a separate, deterministic scoring service, not by the generative model. The architect must recommend how to position the AI capability so its drafts are reliable enough for a regulated communication: the wording may be generated, but every reason stated must be grounded in the applicant's real decision factors, verifiable, and never invented. Speed and officer productivity matter, but a wrong or fabricated reason to a declined borrower is a compliance breach the business cannot accept.

How should the architect position the generative AI capability so the adverse-action drafts meet the accuracy and traceability requirement?

Mekong Learn, a Vietnamese online-education provider, is finalizing the cost estimation for a new BTP-hosted exam-proctoring workload. Its demand profile is highly spiky: the platform is nearly idle for most of each term, then runs at very high volume for a few concentrated exam windows, after which usage drops back to near zero. During early estimation the team compared two commercial shapes for the same platform capability: a committed-capacity arrangement sized for the exam-window peak, and an elastic consumption arrangement that scales with actual use. A junior analyst recommended committing to peak capacity for the year to guarantee headroom during exams. The architect must recommend the commercial model that fits this bursty, low-baseline, high-peak demand profile at the lowest sustainable cost while still guaranteeing capacity during the exam windows, and must treat cost estimation as an architecture input that shapes the account and consumption design, not as a late procurement step.

Which commercial-model recommendation best fits the workload's demand profile and cost objective?

Zuiderbrouw Brewers, a Belgian craft-brewery group, runs analytics on BTP for several brands. Finance, supply-chain, and marketing teams each built their own dashboards, and each computes "net revenue" and "active customer" with slightly different logic — different discount treatments, different return handling, different activity windows. In a leadership review the same metric names showed conflicting numbers from different teams, and no one could say which figure was authoritative. The underlying source data is consistent and reasonably fresh; the divergence comes from each team encoding its own metric logic in its own reports. The architect must recommend how to design the analytics architecture so that shared business metrics carry one agreed definition consumed consistently across teams, while teams still build their own dashboards on top. The recommendation must apply the data-and-analytics advisory approach — organizing around governed, reusable definitions rather than duplicated per-report logic — and must resolve the conflicting-numbers problem at its source.

What analytics-architecture recommendation best resolves the conflicting-metric problem across the teams?

Southern Cross Growers, a New Zealand agricultural cooperative, automates a supplier-onboarding step on BTP. An early bot was built to drive the supplier portal through its on-screen fields — clicking buttons and reading labels — because it was quick to record. After a routine portal update relabelled and re-laid-out several fields, the automation began failing silently: it entered data into the wrong fields for weeks before anyone noticed, corrupting some supplier master records. The portal also exposes a stable, released application interface for the same onboarding action. The architect must recommend how the automation should interact with the target system so it is resilient to portal cosmetic changes and does not silently corrupt data when the interface layout shifts, while keeping the onboarding step automated. The team argues the screen-driven bot is easier to maintain; the architect must weigh maintainability against reliability and clean, contract-based interaction with the target application.

Which automation-design recommendation best makes the onboarding step resilient to portal changes?