SAP BTP Interview Questions: Destinations, Identity, and On-Premise Connectivity

SAP BTP interview questions about connectivity usually become difficult when several green checks appear to contradict a failed request. A destination exists, a user can sign in, and Cloud Connector reports that the internal host is reachable. None of those observations alone proves that the application selected the right destination, requested an exposed path, or reached the backend as an authorized user.

For a Cloud Foundry application calling an on-premise HTTP service, explain each boundary separately: destination resolution, the connectivity route, and backend identity and access. Start with the actual request and the component that rejected it. Identify the rejecting component before changing credentials; otherwise a routing mistake can remain hidden.

Practice explaining identity boundaries with PracHub's browser authentication and JWT question, then apply the reasoning to the SAP-specific trace below. This is technical preparation, not a prediction of an employer's interview questions.

What does a destination actually provide?

A destination is named connection configuration that an application can resolve to call another system. It describes the target and authentication settings; it is not the business API, an open network tunnel, or a grant of permission to every backend operation. SAP's Destination Service documentation describes configuration discovery and supported authentication flows.

Name the application component that consumes the destination. A configured name does nothing if the application's HTTP client never looks it up. Conversely, a successful lookup can return settings for the wrong service or environment. Ask which runtime, service binding, subaccount, and destination name the failing application actually uses.

Keep this example in the Cloud Foundry cloud-to-on-premise HTTP context. Kyma, ABAP environment, and historical Neo examples can use different consumption mechanisms. A Java snippet from a neighboring environment is not evidence that a Node.js application has configured its proxy correctly.

Why can the right name resolve to the wrong destination?

SAP's Find Destination operation searches the associated service instance first and then the subaccount when no instance destination matches. With the same name in both places, an instance destination can conceal the subaccount value you expected. It should not be generalized into an undocumented rule for every SDK's tenant-selection options.

Consider an original exercise: the subaccount's ERP_APPROVALS destination points to a production approval service, while an instance-level destination with the same name still points to a sandbox. The application is bound to that instance. The sandbox request succeeds, but it returns no matching production approval.

Do not begin by increasing a timeout. Compare the resolved configuration with the expected environment and record the lookup context. A useful explanation is: “The returned data is consistent with the sandbox. I would inspect the instance destination before investigating missing production records.”

For a subscription-based application, also establish which tenant's configuration and credentials are being used. Store a tenant identifier in diagnostic context where appropriate, but never print tokens, client secrets, or full authorization headers. The evidence should identify the boundary without exposing credentials.

Trace a virtual host to the internal service

This fictional configuration describes an intended request, not a complete deployment recipe:

{
  "Name": "ERP_APPROVALS",
  "Type": "HTTP",
  "URL": "http://erp-virtual:443",
  "ProxyType": "OnPremise",
  "Authentication": "PrincipalPropagation"
}

SAP lists OnPremise as the HTTP destination proxy type for reaching systems through Cloud Connector. The application still needs the appropriate connectivity consumption path. An ordinary direct HTTP call to the virtual name does not automatically enter that route.

The original request ledger is deliberately small:

SAP's Cloud Connector access-control instructions distinguish virtual from internal addresses and require explicit resource exposure. The virtual name need not be a resolvable intranet hostname. The internal address must be reachable from the connector.

The cloud-side URL scheme and connector-to-backend protocol are separate settings. In this exercise, the mapping uses HTTPS internally. Read both settings before calling the example an unencrypted backend connection.

What does an exposed path really allow?

The same SAP access-control page specifies exact-path matching or, with “Path and all sub-paths,” string-prefix matching. Do not describe the latter as a path-segment-aware permission rule.

In the exercise, the allowed prefix ends with /. The intended .../ZAPPROVAL_SRV/Approvals request matches it. A sibling named .../ZAPPROVAL_SRV_BACKUP/Approvals does not. Remove the trailing separator from the configured prefix and that similar service name also starts with the configured string. This is a different exposure boundary, not a cosmetic change.

Try four requests on paper: the collection path, a nested item, a similarly named service, and the service root without the final slash. Predict each result from the configured matching option. Then compare your prediction with connector evidence in a permitted test environment.

A failed path test does not justify exposing / with all subpaths. Propose the narrowest intended resource and repeat a negative test against the sibling service. If redirects occur, inspect their target too; the next request may no longer use the original host or allowed path.

How do login and principal propagation differ?

Application login establishes an identity at the cloud application. Principal propagation carries that identity toward another system using the configured trust and mapping chain. The backend still decides whether the resulting principal may perform the requested operation.

SAP's principal-propagation configuration identifies trust, certificate, subject-pattern, and backend setup tasks. Setting one destination property is not the entire configuration. A browser-initiated request can still execute under a technical account. Establish which identity the backend receives.

For the fictional approval service, Ava is permitted to read approvals and Ben is not. Both can log in to the cloud application. If their backend calls execute under one technical account, the test may conceal the very user-specific distinction the design was meant to preserve.

Explain the required behavior before choosing an authentication method: must the backend evaluate the end user's permissions, or is an explicitly authorized technical integration account intended? Do not silently change to Basic authentication or a broad service account to make the demonstration pass.

Which certificate and trust check belongs to which hop?

There are different identities involved in a propagated request. SAP's HTTPS identity-propagation guidance distinguishes the system certificate used for mutual TLS trust from the short-lived certificate representing the user. A successful TLS handshake does not prove that the backend mapped the intended user.

Its trust setup instructions also place user mapping in the target system. In a diagnostic answer, name the identity observed at each hop rather than saying “SSO is broken.”

For example, suppose the connector reaches the backend, but Ava's propagated subject cannot be mapped. That observation points toward the user-mapping or trust configuration under test. If the backend recognizes Ava and explicitly denies the operation, adding a certificate will not grant the missing business permission Practice this question.

Keep TLS verification enabled. Report certificate validity, trust-chain, and principal-mapping evidence without copying private keys or credential material into logs. A recovery proposal should preserve the intended security boundary as well as restore the request.

Diagnose six observations without guessing from a status code

Use these independent fictional observations as follow-up questions. They are not six stages that every failure must pass through.

A 401, 403, or timeout does not identify the failing row without response-origin evidence. A proxy, connector, application router, or backend can produce a response. Preserve the response origin and correlated timestamps. If the evidence cannot identify the rejecting component, say which observation you need next.

SAP's service-instance setup example uses Connectivity, Destination, and Authorization & Trust Management instances. Treat that as a documented scenario, not a guarantee that creating three bindings alone completes an arbitrary application's identity design.

How would you verify a repair?

Repeat the original operation through the application, using the intended environment and user context. A connector availability check exercises a different request from reading an approval collection. In the original case, record the resolved target, exposed path, backend principal, and returned business record together.

Use Ava's allowed read as a positive test and Ben's denied read as a negative test. Also request the similarly named service and confirm it remains inaccessible. If a sandbox shadowing problem was fixed, verify the application now reads production configuration rather than merely accepting the destination editor's new value.

For a write, distinguish receiving an HTTP response from confirming the business outcome. A timeout after submission may leave the outcome unknown Practice this question. Check a business identifier before replaying an approval action; a route repair does not make a duplicate write safe.

Extend the fictional verification record with approval A17. Before the repair, Ava's cloud request selects the sandbox and returns no matching approval. After correcting destination resolution, the same read returns the expected production record. Keep the operation and user unchanged so the comparison isolates the target selection. Then run Ben's denied request through that same corrected destination. If both users now receive A17, the routing correction passed but the intended authorization boundary did not. Record those as separate outcomes rather than closing the incident because the original missing-record symptom disappeared.

These are original diagnostic exercises. They have not been executed against a SAP tenant. To validate the deployment, repeat the tests in the authorized environment and retain redacted component evidence. That final boundary is part of a credible interview answer.

Practice the reasoning behind SAP BTP interview questions

The following verified PracHub records exercise identity, routing, dependencies, and diagnosis. They are adjacent practice, not SAP configuration instructions or promised interview questions.

Start with the authentication explanation. Name the issuer, recipient, and permission decision before returning to ERP_APPROVALS. For SAP BTP interview questions, reconstruct the exact request trace, restore Ava's allowed read, and confirm Ben's denied read remains denied.

Sources and Further Reading

• SAP: Destination Service
• SAP: HTTP destinations
• SAP: Destination consumption and Find Destination
• SAP: Configure Access Control (HTTP)
• SAP: Configuring principal propagation
• SAP: Configure identity propagation for HTTPS
• SAP: Set up trust for principal propagation
• SAP: Create and bind service instances

Sources checked October14,2026. The worked case is an original Cloud Foundry HTTP preparation exercise; deployed settings and connector versions must be checked in the actual environment.