Explanation:

✅ Why this is the recommended approach

When a System API is published to Anypoint Exchange, MuleSoft automatically generates a REST Connect Connector from the RAML/OAS specification. This connector is the recommended and best-practice way for a Process API to invoke a System API.

Using the REST Connect connector provides several advantages aligned with API-led connectivity principles:

- Strong contract enforcement
The connector is generated directly from the API specification, ensuring the Process API always aligns with the defined contract.

- Type safety and discoverability
Operations, request structures, and responses are strongly defined and visible in Studio.

- Loose coupling
The Process API depends on the API contract, not implementation details.

- Easy maintainability
If the System API evolves (new version), a new connector version can be generated and consumed without breaking other APIs.

This approach reflects MuleSoft’s guidance that APIs should be consumed like products, not like raw HTTP endpoints.

❌ Why the other options are incorrect

A. Import OAuth module and manage tokens manually
❌ OAuth handling is not how Process APIs should integrate with System APIs. Authentication is typically abstracted and managed at the policy level or connector configuration—not manually coded.

B. Use HTTP Request Connector directly
❌ While technically possible, this bypasses the API contract, reduces reusability, and increases coupling. MuleSoft discourages this when a reusable API asset exists in Exchange.

D. Manually update the POM file
❌ REST Connect connectors are consumed via Anypoint Exchange dependency management—not manual POM manipulation. This would break standard governance and lifecycle practices.

✅ Summary
The MuleSoft-recommended approach is to consume System APIs using the auto-generated REST Connect connector from Exchange, ensuring governance, reuse, and maintainability.

Explanation:

Why B should be pursued first
The key clue is that the slow response time and >90% CPU usage are reproducible in QA with a single request and no other traffic. That strongly suggests the bottleneck is per-request compute cost (CPU-bound processing) rather than overall throughput capacity.

In other words, one “problematic” request is heavy enough to:

drive CPU very high
take a very long time (p99 > 120s)

If one request can saturate CPU, then scaling the platform (more replicas or more CPU) may help somewhat, but it doesn’t fix the root issue: the request itself is too expensive (big payload, expensive transformation, huge query, large aggregation, inefficient algorithm, etc.).

Splitting the request into smaller ones (or redesigning the consumer interaction pattern) reduces per-request load, often improving latency dramatically and reducing CPU spikes. It’s also the most diagnostic: if splitting fixes it, you’ve confirmed the issue is per-request heaviness.

Why the others are not the first move

A. Increase vCPU resources:
This treats the symptom. It can reduce latency, but if the request is inefficient, you’ll just spend more CPU and still risk timeouts at peak. Optimize the request pattern first.

C. Increase number of replicas:
With two non-clustered replicas, adding replicas mainly helps when you have concurrency/throughput pressure. But the issue happens with no other requests, so extra replicas won’t help that single request.

D. Throttle the client:
Throttling reduces load during bursts, but again the problem is reproducible with one request, so throttling doesn’t address the root cause.
✅ First pursue: B

Explanation:
In MuleSoft’s API-led connectivity model, each API layer has a distinct role:

System APIs
Unlock data from backend systems (ERP, CRM, databases, legacy apps).
Handle authentication and connectivity.
Provide reusable building blocks.

Process APIs
Encapsulate business logic.
Orchestrate calls to multiple System APIs to fulfill a business process.
Automate workflows and ensure consistency across different consumers.
Example: An Order Process API that aggregates customer data from Salesforce and product data from SAP to fulfill an order.

Experience APIs
Tailor data for specific consumers (mobile, web, partner apps).
Handle formatting and presentation.
Example: A Mobile Experience API that delivers lightweight JSON responses optimized for mobile devices.

❌ Why not the other options?
A. Data synchronization of large dumps → That’s more of a batch integration concern, not the default role of a Process API.

B. Direct communication between backend and mobile client → That’s the role of an Experience API, not Process.

D. Secure/manage communication with end-user clients → Again, this is Experience layer responsibility, not Process.

👉 In summary:
The main role of a Process API is to automate business processes by orchestrating and coordinating calls to multiple System APIs.

Explanation:
When an API is protected with a Client ID Enforcement policy using the default configuration, the standard and simplest authentication method is HTTP Basic Authentication.

Default Configuration Mechanism:
Upon contract approval, the consumer receives a unique client_id and client_secret.
To authenticate, the client must include these credentials in the Authorization header of every HTTP request to the API endpoint.
The format is: Authorization: Basic <base64_encode(client_id:client_secret)>
This is the out-of-the-box, default behavior of the Client ID Enforcement policy when no other authentication method (like OAuth 2.0) is specifically configured.

Why the Other Options Are Incorrect:
A. Send the obtained token as a header in every call: This describes the OAuth 2.0 flow, where the client first exchanges client_id/client_secret for an access token. However, the question specifies the default configuration of Client ID Enforcement, which is not OAuth 2.0 by default. OAuth requires explicit policy configuration.
B. Send the client_id and client_secret in the request body: This is not a standard or supported method by the Client ID Enforcement policy. Credentials should be passed in the header, not the body, for authentication.
C. Send the client_id and client_secret as URI parameters: This is insecure and not the default method. Passing credentials in the URL is a security risk (they can be logged in server logs, browser history, etc.) and is not the prescribed way for this policy.

Reference:
MuleSoft Documentation - "Client ID Enforcement Policy": States that for the default "HTTP Basic Authentication Scheme," the client must "send the client ID and client secret in the HTTP Authorization header using the Basic authentication scheme." It explicitly warns against sending them in the URL.
API Consumer Onboarding Guide: The standard instructions for a developer who has received client_id and client_secret are to configure their HTTP client to use Basic Authentication with those credentials.

Explanation:

This aligns with the MuleSoft Center for Enablement (C4E) operating model, which defines clear ownership and focus areas for different teams within the API-led connectivity architecture. The model is designed to promote reuse and enablement.

Correct Ownership Mapping:
App Developers own the Experience Layer APIs:
Who: These are the consumers of the API network (e.g., web/mobile app teams, partner integration teams, internal business unit developers).
Why: They understand the specific needs of the end-user or channel. They own the Experience APIs to tailor data and functionality for their specific applications without needing deep knowledge of backend systems.

LOB (Line of Business) IT owns the Process Layer APIs:
Who: IT teams embedded within business units (e.g., Finance IT, Sales Ops IT).
Why: They understand the business processes, rules, and logic unique to their domain. They own Process APIs to orchestrate System APIs and encode business processes (e.g., "customer onboarding," "loan approval") for reuse across multiple Experience APIs.

Central IT owns the System Layer APIs:
Who: The central integration/platform team (often the C4E core team).
Why: They have expertise in managing core systems of record (ERP, CRM, mainframes, databases) and ensuring security, compliance, and stability. They own System APIs to create reusable, canonical abstractions of these backend systems for the entire organization.

This model creates a virtuous cycle: Central IT provides reusable building blocks (System APIs), LOB IT composes them into business processes (Process APIs), and App Developers easily consume them for their applications (Experience APIs).

Why the Other Options Are Incorrect:
A. Incorrectly assigns System Layer APIs to LOB IT. System APIs require deep knowledge of enterprise systems and a mandate for broad reuse, which is typically held by Central IT. LOB IT is better positioned for the business logic in the Process Layer.
B. This option completely inverts the model. Assigning System APIs to App Developers is wrong—they shouldn't deal with backend complexity. Assigning Experience APIs to Central IT defeats the purpose of enabling business-led development. Assigning Process APIs to LOB IT is the only correct part, but the rest is flipped.

Reference:
MuleSoft C4E Operating Model: Clearly defines the "Three-Layer API Ownership" model:
Central IT / Platform Team: Owns the platform and System APIs.
LOB / Domain Teams: Own Process APIs for their business domain.
App / Solution Teams: Own Experience APIs for their specific solutions.

API Product Mindset: This ownership model treats APIs as products managed by the teams closest to their value proposition and consumers.