P_BTPA_2511 exam questions

1. Question 1 Regional Transport Authority BTP Data Discovery Advisory

   Single answer

   Case study: Regional Transport Authority BTP Data Discovery Advisory

   Regional Transport Authority BTP Data Discovery AdvisoryBusiness ContextAgency Context

   The Regional Transport Authority is a mid-sized public-sector body that plans and funds passenger transport across a metropolitan region. It has recently begun a data initiative and has engaged an SAP BTP solution architect for an early discovery engagement. The authority runs SAP applications for finance and asset management, alongside several non-SAP operational systems for ticketing and scheduling. Leadership wants to make better funding and service decisions from its own data, but the organization has little prior experience treating data as a shared, reusable asset rather than as system-specific extracts.

   Discovery Conversations

   Across the first discovery workshops, a recurring pattern emerges. Whenever a department needs figures, an analyst asks the finance or asset teams for a fresh extract, and each request is fulfilled as a one-off file shaped to that request. The planning team, the grants team, and the internal audit function each hold their own copy of what is essentially the same ridership-and-cost information, pulled at different times with slightly different filters. Nobody can say confidently which copy is authoritative, and the same monthly figure often appears with small differences in two reports presented to the board.

   Consumption Landscape

   Several downstream uses for the data are already lining up. A public transparency dashboard is planned, a grants-reporting pack must be produced for a national funding body, and the planning team wants to explore analytics on service coverage. Each of these consumers has been scoped, so far, as its own pipeline pulling directly from the source systems. The architect notes that the ridership and subsidy figures at the center of all three uses are the same underlying information, described and secured differently by each team.

   Governance Context

   Because the authority is a public body, some of the data carries residency and disclosure obligations, and passenger-level records are more sensitive than the aggregated figures used for public reporting. The transparency dashboard is intended for open publication, while internal audit needs fuller detail. Today those boundaries are handled informally, decided per extract by whoever prepares the file. There is interest in SAP Business Data Cloud as the direction for the authority's data foundation, though the team is still learning what a governed data foundation would mean for how they work.

   Delivery Pressure

   The grants-reporting deadline is the nearest fixed date, and one manager has suggested simply scripting a direct pull from the finance system into a spreadsheet for that report, to be safe. The planning lead, meanwhile, is keen to start the coverage analytics quickly and has asked whether her team can just take a copy of the raw source tables for now and sort out governance later. Both requests would meet an immediate need, and both would add another uncontrolled copy of the same figures to a landscape that already struggles to reconcile them.

   Advisory Focus

   The sponsor has asked the architect for a clear early recommendation on how the authority should position this shared ridership-and-cost information for the several consumers now emerging, before any of the individual pipelines are built. The engagement is still at discovery, so no target build has been committed; the value of this stage is in setting the right foundation direction rather than in delivering a specific report.

   Your assignment

   You are acting as the SAP BTP solution architect engaged by the Regional Transport Authority for an early data-discovery engagement. The authority is a public-sector body beginning its first structured data initiative. Several consumers of the same ridership-and-cost information are emerging at once, delivery pressure from a grants deadline is present, and the sponsor wants an early recommendation on how to position this shared data before individual pipelines are built. Reason as an advisor applying the Data and Analytics Advisory Methodology at concept level; do not assume a target build has been approved

   1. CHALLENGE 1 — Positioning Shared Transport Data as a Governed Product

   Advise the sponsor on whether the shared ridership-and-cost information should be positioned as a governed, reusable data product or delivered as separate extracts for each consumer.

   Frame the recommendation in terms of reuse across the transparency dashboard, grants pack, and coverage analytics, at a discovery altitude, without committing to specific services or a build design.

   Explain what defining the data once as a product changes for consumers that appear later, including how ownership of that product should be understood.

   Checkpoints

   The recommendation results in one agreed definition of the shared data that all known consumers can reuse.

   The advice remains at discovery altitude and does not depend on a specific build being approved.

   2. CHALLENGE 2 — Reconciling Conflicting Copies of Ridership Figures

   Advise where the divergent board figures should be addressed, distinguishing the visible reporting symptom from its upstream cause.

   Position the fix so that future consumers, and short-term deadline workarounds, do not reintroduce the same divergence.

   Checkpoints

   The same monthly figure resolves identically across reports because it derives from one defined source.

   The chosen action addresses the shared-source cause rather than only the report currently in view.

   3. CHALLENGE 3 — Setting Data Boundaries for Public and Internal Use

   Advise how the authority should handle the difference between openly publishable aggregated data and sensitive passenger-level detail for internal audit, given residency and disclosure obligations.

   Position the boundary decision relative to the grants deadline pressure and the request to defer governance until later.

   Checkpoints

   Open and internal data are separated by a boundary defined on the shared source, not by per-extract filtering.

   The recommendation weighs the nearest deadline against the cost of adding another ungoverned copy.

   CHALLENGE 1 — Positioning Shared Transport Data as a Governed Product

   The transparency dashboard, grants pack, and coverage analytics all rely on the same ridership-and-cost information, and each has been scoped as its own pipeline pulling from the source systems. The sponsor asks how this shared information should be positioned at discovery.

   What is the best advisory recommendation?

   • A

     Let each consumer keep building its own extract now, then merge the separate definitions into one shared definition after all three pipelines are live.

   • B

     Define the shared ridership-and-cost information once as a governed, reusable data product that both the known and future consumers draw from.

   • C

     Give the first consumer to go live ownership of the data, and have the other teams request working copies from that team as they need them.

   • D

     Defer any positioning decision until the target data platform has been selected and its detailed build scope has been formally approved.

   Reveal answer

   Correct answer

   • B

     Define the shared ridership-and-cost information once as a governed, reusable data product that both the known and future consumers draw from.

   Explanation

   Positioning the shared information once as a governed, reusable data product means every consumer reuses one authoritative definition instead of duplicating it. This is the discovery-altitude foundation move, and it is exactly what the Data and Analytics Advisory Methodology structures decisions around — a governed data product for reuse rather than point pulls.

2. Question 2 Regional Transport Authority BTP Data Discovery Advisory

   Single answer

   CHALLENGE 1 — Positioning Shared Transport Data as a Governed Product

   A new consumer — a fare-policy review team — is expected to need the same ridership-and-cost information a few months after the first three consumers are set up.

   How should the discovery recommendation account for consumers that appear later?

   • A

     Position the data as a reusable product now, so that a later consumer draws from the same governed definition without a new extract being built for it.

   • B

     Record the fare-policy team as out of scope for this particular discovery, and let that team commission its own separate pipeline later, when it eventually arrives.

   • C

     Ask each of the current consumers to retain a spare copy of its own extract, so that the fare-policy team can later reuse one of those copies.

   • D

     Wait to define the shared data until the fare-policy requirement is fully confirmed, so that a single definition can cover every consumer at once.

   Reveal answer

   Correct answer

   • A

     Position the data as a reusable product now, so that a later consumer draws from the same governed definition without a new extract being built for it.

   Explanation

   Defining the data once as a reusable product is precisely what lets a later consumer plug into the same governed definition rather than triggering yet another extract. Reuse is the core benefit of positioning data as a product at discovery, and it is what protects the authority as more consumers emerge.

3. Question 3 Meridian Freight Group BTP Architecture Kickoff Alignment

   Single answer

   Case study: Meridian Freight Group BTP Architecture Kickoff Alignment

   Meridian Freight Group BTP Architecture Kickoff AlignmentBusiness Context

   Meridian Freight Group is a mid-sized third-party logistics (3PL) provider that manages warehousing, freight brokerage, and last-mile delivery for retail and industrial clients. The company runs its operations on a mix of an SAP digital core and several client-facing portals, and it has just secured board funding to modernize how it builds, integrates, and extends solutions using SAP Business Technology Platform. Leadership has framed the program as a multi-year transformation rather than a single project, and the opening months are dedicated to establishing how architecture decisions will be made and by whom.

   Program Setup

   To lead the effort, Meridian has assembled a small architecture group. A newly appointed enterprise architect is responsible for the long-range strategy and the portfolio of capabilities the business wants over the next three years. A solution architect has been asked to own the end-to-end blueprint for the first wave of BTP work, translating business goals into a coherent design across the platform's solution areas. Two technical and domain specialists round out the group, focused on hands-on realization within their areas. The roles were announced quickly, and their exact boundaries are still being clarified as the first requests arrive.

   Early Requests

   Within the first few weeks, requests reach the architecture group faster than the operating rhythm can absorb them. A sales leader wants a portal enhancement to promise clients real-time shipment visibility. An operations manager asks for a small automation to route exception alerts. The finance director wants an early view of what the platform will cost once several use cases go live. Each request lands with a different person in the group, and the same question keeps surfacing in stand-ups: which of these decisions belongs to which architect, and who signs off on the shape of the overall design.

   Reference Material Context

   Meridian's SAP account team has pointed the group to SAP's Enterprise Architecture framework tooling, together with SAP Reference Business Architecture and SAP Reference Solution Architecture, as starting points for the design work. Some members of the group are eager to reuse these reference models to shape the target picture, while others feel that consulting them slows down obvious decisions and would rather sketch designs directly from the incoming requests. The tension has not blocked anything yet, but two early designs have already been drawn up without reference to the published models.

   Governance Context

   The program sponsor wants speed but is wary of accumulating design decisions that no one can trace later. She has asked the group to agree on a lightweight way to keep the emerging blueprint aligned before commitments harden. At the same time, the digital core must remain standard so that future upgrades stay low cost, which shapes how enhancements to the client portals may be delivered. The group senses that the choices made in these first weeks — about altitude, ownership, and how reference architecture is used — will set the tone for the entire transformation.

   Looking Ahead

   By the end of the alignment phase, Meridian expects a clear, shared understanding of what each architect decides, how the SAP reference models feed the design, and how the group will keep the blueprint coherent as the first wave of use cases moves forward.

   Your assignment

   You are acting as the solution architect assigned to Meridian Freight Group's first wave of SAP BTP work. The transformation has just kicked off, the architecture roles were announced quickly, and their boundaries are still being clarified as early requests arrive. Your task is to advise the program on how architecture decisions should be owned, how SAP's reference architecture should shape the target design, and how the emerging blueprint should be kept coherent — without slowing the program to a halt. Recommendations should reflect SAP-aligned solution-architecture practice and respect the requirement to keep the digital core standard

   1. CHALLENGE 1 — Clarifying Architect Altitudes and Decision Ownership

   Advise how to route each incoming request to the architect whose altitude owns that class of decision, distinguishing enterprise-level strategy and portfolio direction, first-wave end-to-end blueprint design, and hands-on realization within a domain.

   Recommend how the solution architect should respond when a request implies a strategy or portfolio choice that belongs at the enterprise altitude.

   Position the boundary between owning the end-to-end blueprint and delegating realization detail to the technical and domain specialists.

   Checkpoints

   Each request can be traced to the architect whose altitude legitimately owns the decision, with a stated reason.

   Strategy and portfolio questions are escalated to the enterprise altitude rather than resolved locally.

   The solution architect retains ownership of the coherent blueprint while realization detail is delegated appropriately.

   2. CHALLENGE 2 — Applying SAP Reference Architecture to the Target Design

   Advise how SAP Reference Business Architecture and SAP Reference Solution Architecture, together with the EA framework tooling, should feed the first-wave target design.

   Recommend the sequence for turning an incoming request into a design element that traces back to the reference models rather than only to the request wording.

   Address how to handle designs already drawn up without reference to the published models.

   Checkpoints

   First-wave design elements trace back to the relevant reference business and solution architecture.

   Requests are interpreted through the reference models before a solution shape is committed.

   Designs produced without reference are reconciled against the models before they proceed.

   3. CHALLENGE 3 — Keeping the Blueprint Coherent Through Solution Governance

   Advise on a lightweight design-authority rhythm that reviews emerging designs against blueprint alignment and clean-core discipline before commitments harden.

   Recommend how portal enhancements and automations should be delivered so the digital core remains standard.

   Position how design decisions should be recorded so the blueprint stays traceable as the program scales.

   Checkpoints

   Each first-wave design passes a review confirming blueprint alignment and a standard core.

   Enhancements are delivered without modifying the digital core.

   Design decisions are recorded so they can be traced and reconciled later.

   CHALLENGE 1 — Clarifying Architect Altitudes and Decision Ownership

   The finance director asks the architecture group to decide which capabilities the business should invest in across the next three years so the platform roadmap can be set.

   At which architect altitude does this decision most appropriately sit?

   • A

     The enterprise architect, because long-range capability and portfolio direction is set at the enterprise altitude

   • B

     The solution architect, because the owner of the first-wave blueprint should also decide the multi-year capability portfolio

   • C

     The technical and domain specialists, because they realize capabilities and best understand what the business should invest in

   • D

     Whoever received the request first, because in the kickoff weeks early momentum matters more than sorting out altitude

   Reveal answer

   Correct answer

   • A

     The enterprise architect, because long-range capability and portfolio direction is set at the enterprise altitude

   Explanation

   Deciding which capabilities the business invests in over a multi-year horizon is strategy and portfolio direction, which sits at the enterprise altitude. Routing it there keeps the roadmap coherent and gives the solution architect a stable frame for the first-wave blueprint.

4. Getting the hang of it? 543 more P_BTPA_2511 questions are waiting, each with its answer. Unlock them all

5. Question 4 Meridian Freight Group BTP Architecture Kickoff Alignment

   Single answer

   CHALLENGE 1 — Clarifying Architect Altitudes and Decision Ownership

   A sales leader asks the solution architect to promise clients real-time shipment visibility, which would reshape which capabilities the business commits to over the coming years.

   How should the solution architect handle a request that implies a multi-year capability commitment?

   • A

     Design the visibility capability immediately, since the solution architect owns the first-wave blueprint and can commit the roadmap

   • B

     Escalate the portfolio implication to the enterprise altitude before shaping any blueprint element around it

   • C

     Ask the technical specialists to build a prototype right away so the promise can be made to the client quickly

   • D

     Decline to act until the sales leader formally documents the request through the program office and its intake process

   Reveal answer

   Correct answer

   • B

     Escalate the portfolio implication to the enterprise altitude before shaping any blueprint element around it

   Explanation

   The request carries a portfolio implication that belongs at the enterprise altitude; the solution architect should surface that implication upward before shaping the blueprint, so the first-wave design rests on a direction the enterprise altitude has confirmed rather than an unowned commitment.

6. Question 5 Global Manufacturer BTP Integration Architecture Review

   Single answer

   Case study: Global Manufacturer BTP Integration Architecture Review

   Global Manufacturer BTP Integration Architecture ReviewBusiness Context

   Meridian Actuation Group is a global discrete manufacturer of precision motion and actuation components, running eleven plants across three regions and selling into automotive, aerospace, and industrial-automation customers. The group has spent two years consolidating a fragmented application estate onto a cloud ERP for finance, order management, and planning, while several plants still run older on-premise systems for shop-floor execution and quality that will not be retired for years. A newly appointed solution architect has been asked to bring the target integration and data architecture to the group's design authority for review before any build work is approved.

   System Landscape

   The landscape the architect inherits is deliberately mixed. The cloud ERP is the new system of record for commercial processes, but master data for materials and suppliers still originates in two regional on-premise systems, and shop-floor and quality data lives close to the machines. Beyond the group's own estate sit external parties: a third-party logistics provider that moves finished goods between plants and distribution centres, and a third-party quality-management partner that several plants rely on for inspection results. Nothing about the estate is greenfield, and the architect is expected to design across SAP and non-SAP systems rather than assume everything will eventually converge onto one stack.

   Programme Objectives

   The board wants three outcomes from the platform programme: current, reliable operational integration between the ERP and the plants and partners; a governed data foundation that later feeds analytics and AI-assisted decision support for planning and quality; and a way to extend the standard processes for the group's specific needs without compromising the ability to take regular upgrades. The sponsor has framed the review as a single approval gate — the blueprint is either coherent enough to build against, or it goes back for rework — and has asked the architect to show how the integration, data, and AI ambitions relate rather than presenting them as separate initiatives.

   Schedule Tension

   The programme is also under visible time pressure. A competitor's supply-chain disruption has opened a commercial window, and the sponsor has told the steering committee that the first plants must be live within two rollout waves. Two build teams have already started sketching interfaces and extensions and have asked the design authority to let them proceed on their own choices and align to the reference architecture afterwards, arguing that the review gates are the main thing slowing the schedule. The architect has to weigh that pressure against the group's stated intent to keep the landscape governable as it scales.

   Integration Observations

   Early interface sketches show a wide spread of needs. One flow carries order and shipment events from the ERP to the logistics provider at high volume and is sensitive to delay; another is a scheduled, heavy synchronisation of material master data between the ERP and an on-premise system; a third is a low-latency notification stream from shop-floor systems. Several build teams have, independently, drawn point-to-point interfaces from the same on-premise plant system to their own cloud consumers. One team has proposed exposing ERP service endpoints straight to the logistics provider to shave a network hop off the high-volume flow, noting the provider sits outside the corporate network boundary.

   Partner Connectivity Context

   The external partners bring their own constraints. The quality-management partner exchanges data only through a file-based mechanism over a specific protocol, while the group's internal flows are message-based. One workstream has suggested simply requiring the partner to adopt the internal interface so the group maintains a single standard, though the partner is an independent company the group does not control. The logistics interface, meanwhile, is the one the sponsor watches most closely, because late or stale shipment status directly affects customer promises.

   Data and Analytics Context

   The data ambition is where the layers begin to interlock. The planned analytics and AI use cases — planning support and quality prediction — depend on data that is current and whose origin can be traced. A workstream keen to show early progress has proposed standing up the reporting layer quickly by copying operational tables from several plant systems into a new store on a nightly job. The shipment data that feeds the logistics interface is also earmarked to feed analytics, from a single shared refresh, even though the operational and reporting consumers do not need the same currency.

   Intelligence Ambition

   On top of that data ambition sits the group's interest in AI-assisted decision support. A stakeholder has asked the architect to add AI capabilities as a standalone layer directly on the existing plant reporting extracts, so value can be demonstrated before the foundation work is complete. Others in the review have noted that the credibility of any planning or quality prediction will rest on how trustworthy the data beneath it is, which brings the conversation back to the foundation the group has not yet built.

   Commercial and Governance Context

   Finally, the architect must set how the group estimates and governs platform consumption across a phased, multi-plant rollout, and how the account model is structured. One proposal would provision full projected steady-state capacity for every service everywhere immediately so nothing is ever throttled, and put every plant's build, test, and production workloads into a single shared subaccount to keep setup and entitlements simple. The design authority has asked the architect to reconcile all of this — the integration styles, the partner boundaries, the data foundation, the AI positioning, the cost model, and the account structure — into one blueprint it can either approve for build or send back.

   Your Assignment

   You are engaged as the SAP BTP solution architect for Meridian Actuation Group. The group's design authority is holding an architecture review of your proposed integration and data blueprint before build work is approved. Your task is to reason as the advisory architect: for each area under review, recommend the solution direction that a certified solution architect would defend to the design authority, weighing the group's mixed SAP and non-SAP landscape, its external partners, its data and AI ambitions, its cost and governance posture, and the delivery pressure the sponsor has set. You are not configuring a system; you are positioning architecture decisions and justifying trade-offs to stakeholders. Several proposals put to you by build teams are plausible on their face but conflict with reference-architecture, clean-core, connectivity, data-governance, or cost discipline — your recommendations must show why

   1. CHALLENGE 1 — Classifying Integration Needs and Styles Before Selecting Technology

   • Recommend how the group should decide which integration approach fits each of its many flows, given proposals to standardise on one pattern for speed versus classifying each flow first.

   • Position the integration styles for flows with conflicting characteristics — a low-latency event stream versus a scheduled, high-volume synchronisation — and justify why a single interface style is or is not appropriate.

   • Respond to a portfolio-level strategy question about a single hybrid integration platform versus a best-of-breed per-domain mix at the altitude at which it is asked.

   CHECKPOINTS

   • The recommendation drives technology selection from a classified integration need, not from team familiarity or a one-pattern template.

   • Flows with different latency and volume profiles are assigned different styles where their characteristics require it.

   • A strategy-level question receives a strategy-level answer aligned to the platform's stated integration direction, not a single interface's detail.

   2. CHALLENGE 2 — Mediating Cross-Boundary and Cross-Consumer Connectivity

   • Recommend how to position connectivity for a high-volume flow to an external partner that sits outside the corporate network boundary, given a proposal to expose back-end endpoints directly to remove a hop.

   • Recommend how to keep the landscape governable when several teams are drawing point-to-point interfaces from the same shared on-premise system to their own consumers.

   • Recommend how to reconcile a partner that supports only a file-based, protocol-specific exchange with the group's message-based internal flows.

   CHECKPOINTS

   • Cross-boundary exchanges are mediated through the platform with a secure connectivity mechanism rather than exposing back-ends directly or sharing back-end credentials.

   • Shared, multi-consumer systems are served through a governed, reusable mediation pattern rather than proliferating bespoke interfaces.

   • Protocol and style mismatches with external partners are absorbed at the platform boundary rather than forced onto an uncontrollable third party or propagated inward.

   3. CHALLENGE 3 — Grounding Data, Analytics, and AI on a Governed Foundation

   • Recommend how to source the analytics and AI use cases, given a proposal to copy operational tables nightly into a new store to start reporting quickly.

   • Diagnose the likely root cause when a healthy logistics interface with a responding partner endpoint nonetheless returns stale shipment status, and recommend what to confirm first.

   • Recommend how to position AI capabilities relative to the data foundation, and how to make a data product feeding both an operational interface and analytics dependable for both consumers.

   • Characterise how the integration, data-foundation, and AI layers relate when the blueprint is put forward for approval.

   CHECKPOINTS

   • The data foundation is governed, with defined data products, ownership, and freshness, rather than built on ad hoc copies or standalone extracts.

   • The staleness is traced to the second-order scheduled-refresh lag behind the visible symptom, not to the healthy interface or the responding partner.

   • AI capabilities are positioned on the governed foundation and within the platform's AI services, and freshness is designed per consumer.

   • The layers are presented as an interdependent chain whose approval and sequencing respect the dependency.

   4. CHALLENGE 4 — Positioning Extensions Within Clean-Core Discipline

   • Recommend the extension positioning for two needs together — validation logic close to a standard process, and a separately lifecycle-managed capability consumed by several plants and an external partner — given a proposal to build both as one side-by-side extension.

   • Weigh a performance-and-speed argument for embedding transformation and enrichment logic directly into the cloud ERP as modifications against clean-core and integration governance.

   CHECKPOINTS

   • Each need is placed on the extensibility spectrum by its proximity and lifecycle, not forced to a single end for convenience.

   • The digital core is kept standard and upgrade-safe; transformation and enrichment stay in the integration layer rather than as core modifications.

   5. CHALLENGE 5 — Sustaining Reference-Architecture Governance Through Delivery

   • Recommend how to weigh delivery velocity against reference-architecture alignment when build teams ask to proceed on their own choices and align afterwards.

   • Recommend how the group should estimate and govern platform consumption across a phased, multi-plant rollout, given a proposal to provision full steady-state capacity everywhere immediately.

   • Recommend how to structure the account model, given a proposal to place all plants and lifecycle stages in a single shared subaccount.

   • Recommend the governance mechanism that sustains integration-architecture alignment as multiple teams deliver across rollout waves.

   CHECKPOINTS

   • Alignment is confirmed before build through the review gate rather than reconciled after go-live.

   • Cost estimation is treated as an architecture input that shapes account model, service selection, and phasing, and consumption is right-sized per phase.

   • The account model uses the platform's isolation boundaries deliberately, by environment, region, project, or line of business.

   • Alignment is sustained by an active design-authority function reviewing each wave at defined checkpoints, not a one-time document, an end-of-programme audit, or field-level micro-approval.

   CHALLENGE 1 — Classifying Integration Needs and Styles Before Selecting Technology

   The design authority is reviewing how the manufacturer will decide which platform-mediated integration approach fits each of the dozens of flows between its cloud ERP, on-premise systems, and third-party logistics and quality partners. One workstream lead proposes standardising on a single integration pattern for everything to accelerate build, while the reference-architecture team argues each flow should be classified before a pattern is chosen.

   Which recommendation best reflects the platform's integration advisory approach the architect is expected to apply?

   • A

     Classify each integration need by style and domain first, define the target blueprint per style, and let the classified need drive the mediation pattern and technology for each flow.

   • B

     Standardise on one integration pattern across every flow so build teams reuse a single template and shorten delivery, absorbing any occasional misfit as a routine maintenance cost later.

   • C

     Let each build team adopt whichever integration technology it already knows for its own flow, then reconcile the divergent choices later once the interfaces are running in the landscape.

   • D

     Defer all integration pattern decisions until the data and analytics layer is finalised, on the basis that integration is downstream of the data model in effectively every case here.

   Reveal answer

   Correct answer

   • A

     Classify each integration need by style and domain first, define the target blueprint per style, and let the classified need drive the mediation pattern and technology for each flow.

   Explanation

   The platform's integration advisory methodology exists to make technology selection repeatable and governed: classify the need into styles and domains, blueprint the target per style, then let the classification drive the pattern. This keeps a heterogeneous flow set coherent rather than pattern-forced or team-improvised.

7. Question 6 Global Manufacturer BTP Integration Architecture Review

   Single answer

   CHALLENGE 1 — Classifying Integration Needs and Styles Before Selecting Technology

   Two of the flows the manufacturer must support behave very differently: one is a low-latency, event-driven notification stream from shop-floor systems, and the other is a scheduled, high-volume master-data synchronisation between the cloud ERP and an on-premise system. A workstream proposes handling both with the same request-response interface style for uniformity.

   What should the architect recommend when positioning the styles for these two flows?

   • A

     Use the very same request-response interface style for both of these flows so that the operations team has just a single interface style to monitor, support, and reason about consistently right across the whole landscape.

   • B

     Distinguish the flows by integration style — an event or messaging style for the low-latency notifications and a scheduled batch data-movement style for the high-volume synchronisation — not one shared interface.

   • C

     Handle both flows as real-time event streams, since making the master-data synchronisation event-driven as well will keep the two connected plants perfectly current with each other at all times.

   • D

     Handle both flows as scheduled batch jobs to simplify error handling and retries, accepting that the shop-floor notifications will then arrive only at the next scheduled batch window each time.

   Reveal answer

   Correct answer

   • B

     Distinguish the flows by integration style — an event or messaging style for the low-latency notifications and a scheduled batch data-movement style for the high-volume synchronisation — not one shared interface.

   Explanation

   The two flows have fundamentally different coupling and volume characteristics, and the advisory method classifies them into different styles for that reason. Matching style to need avoids starving the event flow of timeliness or overwhelming the batch flow's channel.

8. Question 7 Classifying integrations and opening partner connectivity on a first platform

   Single answer

   Case study: Classifying integrations and opening partner connectivity on a first platform

   Classifying integrations and opening partner connectivity on a first platformBusiness Context

   Marisol Seafreight Alliance coordinates ocean freight bookings across a group of regional carriers, passing manifests, status updates, and settlement files between them. As volumes rise, its hand-built connections strain, so it turns to SAP BTP to organise integration and, later, analytics. Leadership wants integrations chosen deliberately by need rather than by whoever wires them, and wants carrier partners reached safely without exposing core systems. The board approved a first platform step and asked you, as solution architect, to bring order to how systems and partners connect.

   Current Landscape

   Bookings and settlement run on SAP S/4HANA, while partner carriers run their own varied systems. Integration today is a scatter of point-to-point scripts built ad hoc over years, each understood by one person. Some partners receive nightly file drops; others want near-real-time status. Access to systems is loosely controlled, with a few broadly privileged logins shared across teams. Reporting is manual, and there is no shared, trusted view of movements across the alliance.

   Platform Onboarding

   The initiative begins by classifying the interfaces before choosing any technology, then mediating them centrally rather than point-to-point. A first workstream stands up managed connectivity so carrier partners are reached at the network edge with proper authentication. A second tightens access so each team holds only the rights its work needs. A third prepares a governed data foundation so a later self-service reporting layer rests on trusted numbers rather than scattered copies.

   Governance Context

   Security wants partner connections brokered and monitored, never direct paths into core systems. The administrator wants the shared privileged logins replaced with least-privilege roles that can be audited. Finance wants one trusted view of movements before analysts are turned loose on self-service reports, fearing a proliferation of conflicting spreadsheets. These concerns converge on one demand: integration and access must be classified, brokered, least-privilege, and grounded, not merely wired quickly to move today's files.

   Delivery Pressure

   A major carrier onboarding is due next quarter, and executives want live status flowing quickly. The temptation is to standardise every interface on one file transfer, let the new partner reach a core system directly, and reuse a shared admin login to save setup time. Each shortcut trades a quick connection for lasting fragility or exposure. You are asked to keep the onboarding moving while ensuring these first integration decisions do not harden into an unmanageable tangle.

   Foundation Expectations

   Whatever ships first must not constrain later growth. More carriers, more interface styles, and self-service analytics are all foreseen. The way interfaces are classified, the way partners are brokered at the edge, the way access is scoped, and the way data is governed must all let the alliance grow by addition rather than rework. Trust in the numbers and control over the connections must be structural, so the platform can extend confidently rather than accumulate fragile links.

   Your Assignment

   You are acting as the solution architect engaged by Marisol Seafreight Alliance to bring order to integration and partner connectivity on its first SAP BTP footprint. Across four linked challenges you will classify interfaces by style before selecting a technology, reach carrier partners safely across the network edge, scope each team's access to least privilege, and establish one trusted data view before opening self-service reporting. Each choice shapes the next, so weigh the pressure to wire connections quickly against the governed, extensible foundation the alliance must preserve

   1. CHALLENGE 1 — Sorting Interfaces By Style Before Picking A Technology

   • Apply the Integration Solution Advisory Methodology to classify each interface by style, such as process, data, real-time event, or bulk transfer.

   • Map each classified interface to a fitting pattern and capability rather than forcing all onto one technology.

   • Record the classification so later interfaces are matched consistently, not wired ad hoc.

   CHECKPOINTS

   • Each interface carries a declared integration style before a technology is chosen.

   • A real-time need and a bulk transfer are not forced onto the same pattern.

   2. CHALLENGE 2 — Reaching Partner Systems Across The Network Edge Safely

   • Publish and consume partner interfaces through managed API connectivity at the network edge, not direct system access.

   • Authenticate each partner individually and apply throttling and monitoring to the exposed interfaces.

   • Validate and transform inbound partner data at the edge rather than letting it reach core systems raw.

   CHECKPOINTS

   • No partner holds a direct connection into a core system or database.

   • Each partner authenticates with its own credentials and its traffic is logged.

   3. CHALLENGE 3 — Giving Each Team Only The Access Its Work Requires

   • Define role collections that grant only the rights each team's work requires within its subaccounts.

   • Replace shared privileged logins with individually assigned, least-privilege roles.

   • Separate developer and operator duties rather than granting blanket administration.

   CHECKPOINTS

   • No shared, broadly privileged login remains in everyday use.

   • Each action can be traced to an individual with an appropriate role.

   4. CHALLENGE 4 — Building One Trusted View Before Opening Self-Service Reports

   • Establish a governed data foundation, such as on SAP Business Data Cloud, with agreed definitions before opening self-service.

   • Point reporting at that single foundation rather than letting analysts extract private copies.

   • Define shared semantics so a term means the same thing in every report.

   CHECKPOINTS

   • Self-service reports read from one governed foundation, not scattered extracts.

   • A common metric returns the same value across different reports.

   CHALLENGE 3 — Giving Each Team Only The Access Its Work Requires

   Several teams will use the platform. To move fast, an administrator suggests everyone share one broadly privileged login for now.

   How should access for the teams be granted?

   • A

     Let all teams share one broadly privileged login for now to avoid the setup of individual roles, planning to tighten access at some later, unspecified point once things settle.

   • B

     Give every user full administrator rights so no one is ever blocked waiting for access, treating unrestricted permission as the simplest way to keep everyone productive.

   • C

     Grant each team a least-privilege role collection scoped to its subaccounts, so people hold only the rights their work needs.

   • D

     Assign roles only to the leads of each team and have everyone else work through them, funnelling all platform actions through a handful of privileged individuals.

   Reveal answer

   Correct answer

   • C

     Grant each team a least-privilege role collection scoped to its subaccounts, so people hold only the rights their work needs.

   Explanation

   Scoped, least-privilege roles limit what each team can reach and make actions attributable. It contains mistakes and misuse without slowing legitimate work.

9. Question 8 Classifying integrations and opening partner connectivity on a first platform

   Single answer

   CHALLENGE 3 — Giving Each Team Only The Access Its Work Requires

   Developers and operators need different things: developers build extensions, operators run and monitor them. A single "platform admin" role is proposed for both.

   How should developer and operator access be arranged?

   • A

     Give both developers and operators one shared "platform admin" role covering everything, so nobody is ever blocked by a missing permission while the work is underway.

   • B

     Separate developer and operator duties into distinct role collections, so each group has the rights for its own tasks and no more.

   • C

     Grant developers full production control as well so they can operate what they build, merging build and run permissions permanently for everyone on the team.

   • D

     Give operators developer rights too so they can fix code directly in production when something breaks, keeping build and run permissions identical across both roles.

   Reveal answer

   Correct answer

   • B

     Separate developer and operator duties into distinct role collections, so each group has the rights for its own tasks and no more.

   Explanation

   Separating duties gives developers build rights and operators run-and-monitor rights without overlap, containing risk. It also makes activity in each area clearly attributable.

10. Question 9 A side-by-side extension and governed automation on SAP BTP

    Single answer

    Case study: A side-by-side extension and governed automation on SAP BTP

    A side-by-side extension and governed automation on SAP BTPBusiness Context

    Iquitos Glassworks Cooperative is a member-owned maker of hand-blown and moulded glass, selling homeware and laboratory vessels to regional buyers. Rising order volumes strain its manual quality-certificate and member-billing steps, and members want a shared app to track kiln batches from melt to dispatch. The cooperative already runs SAP S/4HANA for finance and production, but wants new custom features without disturbing that core. It turns to SAP BTP to build a governed extension and automate paperwork, keeping the standard system clean, upgrade-ready, and affordable for a small cooperative budget.

    Current Landscape

    Today the cooperative operates one SAP S/4HANA tenant for finance, inventory, and production planning, with a handful of spreadsheets bridging the gaps. A previous consultant added custom fields and a few modifications directly inside the core, which now complicate every upgrade window. There is no cloud platform, no shared development environment, and no formal way to reuse work between the two staff who write scripts. Quality certificates are typed by hand, and member billing is reconciled monthly in a spreadsheet. Everyone agrees the current pattern will not scale as membership and export orders grow.

    Platform Onboarding

    To begin, the cooperative sets up a single global account on SAP BTP and splits work across a few subaccounts for development, testing, and production. Entitlements and quotas are assigned deliberately so a small team cannot overspend. Two workstreams start in parallel: one to build the kiln-batch and certificate app, and one to automate the monthly billing reconciliation. Developers explore SAP Business Application Studio for pro-code work and SAP Build for low-code delivery. The architect is asked to choose runtimes, programming models, and extension patterns before any real code or automation is committed.

    Governance Context

    Finance is cautious: SAP BTP bills by consumption, so uncontrolled services could surprise a cooperative that watches every sol. Security wants member and pricing data protected, connections authenticated, and no direct database access from new apps. Compliance insists the S/4HANA core stay standard, because audited financial processes must survive each upgrade untouched. The board also worries about key-person risk, since only two people currently write automation and nothing is documented or shared. Any recommendation must therefore fit a modest budget, use released and secured interfaces, and leave a governed trail that new members can maintain later.

    Delivery Pressure

    The board wants a working kiln-batch app and automated billing before the next export season, roughly four months away. Under that pressure, shortcuts look tempting. One developer suggests simply adding more custom code inside S/4HANA again, because it feels faster than learning a new platform. Another wants each workstream to build its own billing bot quickly, copying steps between them rather than agreeing on shared pieces. A third proposes exposing the database directly so the app can read data without waiting for interface work. Each shortcut trades a quick win for a lasting maintenance and upgrade problem.

    Foundation Expectations

    Whatever gets built now must protect the cooperative's future. The S/4HANA core has to remain standard and upgrade-safe, so extensions belong beside it, not inside it. Integration must run over released, authenticated interfaces and events, never brittle direct links. Automation should be reusable and centrally governed, so knowledge is not trapped with two people. Low-code and pro-code work must follow the same clean-core rules, and costs must stay predictable and small. The result should be an extension that new members can understand, extend, and afford long after this first delivery season ends.

    Your Assignment

    You are acting as the solution architect engaged by Iquitos Glassworks Cooperative to shape its first build on SAP BTP. Across four connected challenges you will make the foundational choices for a single extension and its automation. First you will pick a runtime and programming model that match a small team's skills and the app's needs. Then you will keep that extension side-by-side and upgrade-safe, connecting to S/4HANA only through released, loosely coupled interfaces. Next you will make the billing automation reusable rather than duplicated, under real governance. Finally you will position low-code delivery so citizen developers stay within clean-core limits. Every decision must respect the cooperative's budget, security, and long-term maintainability

    1. CHALLENGE 1 — Selecting A Runtime And Programming Model For The Extension

    • Compare the Cloud Foundry and Kyma runtimes against the team's operating skills, not just their features.

    • Match the programming model to existing developer languages: the cloud application programming model for javascript or java, ABAP Cloud for ABAP staff.

    • Choose developer extensibility only when the app needs custom data and logic beyond simple in-app configuration.

    CHECKPOINTS

    • The chosen runtime can be operated and paid for by a small cooperative team.

    • The programming model reuses skills the developers already have, avoiding a steep learning curve.

    2. CHALLENGE 2 — Keeping The Extension Side-By-Side And Upgrade-Safe

    • Connect to S/4HANA only through released, whitelisted apis exposed as destinations, never through direct database access.

    • Prefer events for status updates so the extension and core stay loosely coupled and can change independently.

    • Keep all custom data and logic on BTP, leaving the core standard and free of new tables or fields.

    CHECKPOINTS

    • No connection depends on unreleased apis or direct database reads that an upgrade could break.

    • The core carries no new custom tables or fields added for this extension.

    3. CHALLENGE 3 — Reusing Automation Without Ungoverned Duplication

    • Build the billing reconciliation once in SAP Build Process Automation and publish its reusable actions to a shared library.

    • Let other teams consume the published, versioned automation rather than copying its steps into new bots.

    • Set governance: naming, ownership, permissions, and a lifecycle so no ungoverned duplicate can quietly appear.

    CHECKPOINTS

    • One governed, versioned billing automation exists and is reused, not several near-identical copies.

    • Every automation has a named owner and follows the agreed naming and lifecycle rules.

    4. CHALLENGE 4 — Positioning Low-Code Delivery Within Clean-Core Limits

    • Use low-code for simpler apps and workflows suited to citizen developers, not for complex custom logic.

    • Require every low-code app to reach S/4HANA through the same released apis pro-code uses.

    • Route low-code delivery through the same governance and review, so clean core is never bypassed.

    CHECKPOINTS

    • Low-code apps consume only released, authenticated interfaces, never direct core or database access.

    • Every low-code app passes the same clean-core review as a pro-code extension before release.

    CHALLENGE 1 — Selecting A Runtime And Programming Model For The Extension

    Having settled on a managed runtime, the architect turns to the programming model. The two developers know javascript and a little java, but no ABAP. They need a guided way to define data models and consume released S/4HANA apis.

    Which programming model best matches these developers for building the side-by-side extension?

    • A

      ABAP Cloud, because it is the modern, upgrade-safe way to write extensions and the team can simply learn ABAP as they go.

    • B

      Hand-written custom code with no framework, wiring database calls and endpoints manually so the team keeps total freedom over every line.

    • C

      The cloud application programming model, since it guides javascript and java developers through data models, services, and released-api access without requiring ABAP.

    • D

      A pure low-code approach for the whole extension, dragging blocks so the developers never write code for the custom kiln batch data model. It was put forward as the simplest way to keep moving quickly.

    Reveal answer

    Correct answer

    • C

      The cloud application programming model, since it guides javascript and java developers through data models, services, and released-api access without requiring ABAP.

    Explanation

    This model builds directly on the languages the team already knows and provides a structured path to services and released apis. It shortens onboarding, reduces mistakes, and fits the budget, making it the natural choice for these developers.

11. Question 10 A side-by-side extension and governed automation on SAP BTP

    Single answer

    CHALLENGE 1 — Selecting A Runtime And Programming Model For The Extension

    The kiln-batch app needs its own data model, custom screens, and processing logic that go well beyond adjusting a few fields on a standard S/4HANA screen. The architect must choose an extensibility style before building begins.

    Which extensibility style fits an app that needs custom data, screens, and logic?

    • A

      Developer-led side-by-side extensibility, building the app on BTP with its own data model and logic, decoupled from the S/4HANA core.

    • B

      Key-user in-app extensibility, adding custom fields and simple logic directly on the standard screens through the built-in configuration tools.

    • C

      Classic on-stack modification, coding the new logic and tables inside the S/4HANA core so everything sits in one familiar system.

    • D

      A split design putting the data in the core and the screens on BTP, tightly linked so both must change together.

    Reveal answer

    Correct answer

    • A

      Developer-led side-by-side extensibility, building the app on BTP with its own data model and logic, decoupled from the S/4HANA core.

    Explanation

    Because the requirements exceed simple in-app configuration, a developer-built side-by-side app is the right pattern. It gives full control over data and logic while keeping everything off the core, so upgrades stay safe and the design can grow.

12. Question 11 Locked Unlock to see this question
13. Question 12 Locked Unlock to see this question

Back to the P_BTPA_2511 exam page