Explanation:

The System layer is the part of API-led connectivity that focuses on unlocking access to core systems—including legacy systems, databases, SaaS apps, ERPs/CRMs, and other key data sources—and exposing their capabilities in a consistent, reusable way.

Why the System layer fits
It provides system-of-record access through System APIs that abstract the underlying system’s details (protocols, schemas, credentials, quirks).
It makes backend capabilities reusable so multiple business processes and channels can leverage them without rebuilding point-to-point integrations.
It isolates change: if the legacy system changes, you update the System API rather than breaking many consumers.

Why the other layers don’t
Experience Layer (A): Tailors APIs for specific consumers (mobile, web, partners), focusing on the user/channel experience, not unlocking systems.
Process Layer (B): Orchestrates and applies business logic by combining data from System APIs into a business process, not directly exposing system capabilities.

✅ Final: C. System Layer

Explanation:

This question outlines the standard process for configuring a Custom Domain for CloudHub applications using a Dedicated Load Balancer (DLB). The goal is to have applications accessible via https://api.acmecorp.com.

Step-by-Step Rationale:

1. Configure the DLB with a TLS certificate for api.acmecorp.com: The DLB terminates TLS/SSL traffic. To serve a custom domain (api.acmecorp.com) over HTTPS, you must upload or generate a valid TLS certificate (via Let's Encrypt or your own CA) for that exact domain to the DLB configuration in Runtime Manager. This ensures secure connections.

2. Create a CNAME record from api.acmecorp.com to acme-dlb-prod.lb.anypointdns.net: This is the DNS configuration step. The DLB is accessible via a default MuleSoft-provided domain: .lb.anypointdns.net. To point your custom domain to it, you create a CNAME record (an alias) in your domain's DNS (e.g., at your registrar like GoDaddy or Route 53). This tells the internet that api.acmecorp.com is an alias for the DLB's hostname.

Important Notes:
The DLB name in the CNAME target must be exactly as provisioned (e.g., acme-dlb-prod.lb.anypointdns.net).

Option B correctly uses the anypointdns.net domain, which is the standard domain for CloudHub 2.0 DLBs. (For CloudHub 1.0, the domain was cloudhub.io, but the question refers to "CloudHub 1.0" in a legacy sense; the modern configuration uses anypointdns.net).

Why the Other Options Are Incorrect:

A. ❌ ...create an A record for api.acmecorp.com to the public IP addresses associated with their DLB: While possible, this is not the recommended or standard practice. DLB IP addresses can change (e.g., during maintenance or scaling). The CNAME to the stable hostname is the resilient, MuleSoft-recommended approach, as the hostname will always resolve to the current IPs.

B. ❌ Configure the DLB with a TLS certificate for acme-dlb-prod.lb.anypointdns.net...: The TLS certificate must be for the custom domain the user will access (api.acmecorp.com), not for the internal DLB hostname. A certificate for acme-dlb-prod.lb.anypointdns.net would cause a certificate name mismatch error when users visit api.acmecorp.com.

C. ❌ Configure the DLB with a TLS certificate for api.acmecorp.com and create a CNAME record... to acme-dlb-prod.elb.cloudhub.io: This uses the old cloudhub.io domain pattern, which was for Shared Load Balancer (SLB) configurations in CloudHub 1.0. For a Dedicated Load Balancer (DLB), the correct domain is lb.anypointdns.net. Also, the SLB pattern would be ..elb.cloudhub.io. This option mixes incorrect patterns.

Reference:
MuleSoft Documentation - "Configure a Custom Domain for Dedicated Load Balancers": Explicitly states the steps: 1) Add the custom domain and TLS certificate to the DLB, and 2) Create a CNAME DNS record from your custom domain to the DLB's lb.anypointdns.net hostname.

Explanation:

✅ Why D is correct

According to the HTTP specification (RFC 7231 / RFC 9110):
* GET and HEAD responses are cacheable by default
* OPTIONS responses are also considered safe and may be cached (especially when they describe static capabilities of a resource)

These HTTP methods are:
* Safe → they do not modify server state
* Idempotent → repeated calls produce the same result
* Appropriate for caching when the response allows it

This makes GET, HEAD, and OPTIONS the correct set for safe caching behavior.

❌ Why the other options are incorrect

A. PUT, POST, DELETE
❌ These modify server state and are not safe to cache.

B. GET, HEAD, POST
❌ POST is not safely cacheable unless explicitly defined, and even then it’s rarely done in practice.

C. GET, PUT, OPTIONS
❌ PUT is not safe or cacheable.

🧠 Exam takeaway
Safe + cacheable HTTP methods = GET, HEAD, OPTIONS
These are the only verbs appropriate for caching in a general RESTful context.

Explanation:

This question tests a fundamental principle of design-first API development and the role of the RAML definition as the contract between the API provider and its consumers.

Why A is Correct:
The RAML definition is the API contract. It explicitly defines the structure of request and response messages (schemas), endpoints, parameters, and verbs. Any change to this public interface—such as adding, removing, or renaming fields, changing data types, or adding or removing endpoints or query parameters—must be reflected in an updated RAML definition. Failure to do so breaks the contract, causing consumer applications to fail or behave unexpectedly. The updated RAML should be versioned (following semantic versioning) and published to Exchange.

Why B is Incorrect:
Changing the backend system (from on-premises legacy to cloud SaaS) is an implementation detail that does not necessarily change the public API contract. If the System API is designed correctly with an anti-corruption layer, the public interface (the RAML) can remain completely unchanged while the underlying integration logic is swapped out. This decoupling is a key benefit of the API-led approach.

Why C is Incorrect:
Migrating the Mule runtime version (e.g., from Mule 3 to Mule 4) is a platform upgrade that may require code changes in the implementation, but it should not change the external contract. The goal of such a migration is to maintain functional equivalence. The RAML definition should remain the same unless the migration is also used as an opportunity to intentionally revise the API design.

Why D is Incorrect:
Performance optimizations (e.g., tuning threads, caching, or query optimization) are non-functional improvements that happen within the implementation. They do not alter the request or response structure, endpoints, or behavior as defined in the contract. The API still accepts the same inputs and delivers the same outputs, just faster. The RAML does not need to be updated.

Core Principle: Contract-First Design

The RAML or OAS specification defines the what (the interface).
The API implementation defines the how (the integration logic).
Changes to the what require a contract update. Changes only to the how do not.

Reference:
MuleSoft's design-first methodology emphasizes that the API specification (RAML or OAS) is the single source of truth for the API interface. Any deviation between the implementation and the spec is a bug.

Best practices for API versioning and lifecycle management dictate that changes to message structures necessitate a new API version, which starts with an updated specification.

Explanation:

Why
To be used in Anypoint DataGraph for building a unified schema, an API must be reachable from the DataGraph runtime. In the exhibit:

API #1 and API #2 are deployed in CloudHub inside the Customer VPC. They can be reached through the Dedicated Load Balancer (DLB) that fronts the VPC-hosted CloudHub apps. That means DataGraph can invoke them securely through the VPC/DLB path.

API #3 and API #4 are on Customer Hosted Server 1, which is shown as publicly reachable (traffic can come from the public internet, and the diagram shows connectivity into the CloudHub side via the shared LB path). Because they are reachable over the network from DataGraph, they can be included in the unified schema.

API #5 and API #6 are on Customer Hosted Server 2 (Not public). Since they are explicitly marked not public and the diagram shows no private connectivity path (no VPN/Direct Connect/VPC peering/Anypoint networking link) from CloudHub/DataGraph to that server, DataGraph would not be able to reach those APIs. If an API can’t be reached, it can’t be used as a DataGraph source.

Why the other options are wrong

A (1,3,5) includes API #5, which is not publicly reachable and has no private route shown → not usable.
B (2,4,6) includes API #6, also not reachable → not usable.
C (1,2,5,6) includes API #5 and #6, neither reachable → not usable.

✅ Therefore, the APIs that can be used with DataGraph in this architecture are APIs 1, 2, 3, and 4 → Option D.