C_CPI Integration Suite Development Practice Question
An integration developer is creating an integration flow that must call an external SOAP service. The service requires WS-Security with a username token and timestamp. The developer wants to avoid hardcoding credentials in the integration flow. Which approach should be used?
⚠ Common exam trap
The trap here is thinking that any method of inserting credentials works, but hardcoding or scripting bypasses secure storage and rotation, and OAuth does not satisfy WS-Security requirements.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure the SOAP receiver adapter with WS-Security and use a 'User Credentials' artifact referenced via a Security Material alias.
The SOAP receiver adapter supports WS-Security with username token and timestamp. To avoid hardcoding credentials, use a Security Material artifact such as 'User Credentials' and reference it via an alias. This keeps credentials secure and manageable. Embedding credentials manually, using OAuth, or scripting the header are either insecure or not aligned with WS-Security requirements.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure the SOAP receiver adapter with WS-Security and use a 'User Credentials' artifact referenced via a Security Material alias.
Why this is correct
SAP Cloud Integration provides Security Material artifacts such as 'User Credentials' that can be referenced by an alias. The SOAP receiver adapter supports WS-Security configurations, including username token and timestamp, and can use these aliases. This avoids hardcoding credentials and allows secure management and rotation of credentials in the tenant.
- ✗
Store the credentials in a message mapping and use a Groovy script to insert them into the SOAP envelope.
Why it's wrong here
Storing credentials in a message mapping or script again hardcodes them in the integration flow, which is insecure. It also requires custom development to generate the WS-Security header, increasing complexity and risk of errors. The built-in WS-Security support in the SOAP receiver adapter is the correct, secure approach.
- ✗
Use OAuth 2.0 client credentials and pass the token in the SOAP header.
Why it's wrong here
The external SOAP service requires WS-Security with a username token and timestamp, not OAuth 2.0. OAuth tokens are a different authentication mechanism and would not satisfy the service's security policy. The SOAP receiver adapter's WS-Security settings are designed for exactly this scenario, so OAuth is not appropriate here.
- ✗
Embed the username and password directly in the SOAP header using a Content Modifier step.
Why it's wrong here
Embedding credentials directly in the SOAP header via a Content Modifier would hardcode them in the integration flow, which is insecure and violates the requirement to avoid hardcoding. It also bypasses the secure credential storage and rotation features of the tenant. Additionally, generating a proper WS-Security header manually is error-prone.
About these practice questions
Courseiva writes every C_CPI question from scratch — 218 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official SAP exam blueprint
This C_CPI practice question is part of Courseiva's free SAP certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the C_CPI exam.