I85PREP
⌘ K
MGWC study materials
MGWC study resources

MGWC practice questions

One question at a time. Build your MGWC understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Describe and document integration architecture

In an integration architecture document, which artifact defines the contract for messages exchanged between two systems, including field names, data types, and cardinality?

  1. The service level agreement
  2. The capacity forecast
  3. The deployment topology diagram
  4. The message schema or interface definition Correct answer.

Explanation

A message schema or interface definition is the formal contract that fixes field names, data types, and cardinality so both producer and consumer build against the same structure. Topology, SLA, and capacity artifacts describe placement, commitments, and sizing rather than payload structure.

Question 2Describe and document integration architecture

An architect is documenting how an order event flows from a commerce platform through a message broker to a fulfillment service. Which view is the most appropriate place to record the routing and sequencing of that flow?

  1. The data retention schedule
  2. The access control matrix
  3. The physical network diagram
  4. The integration flow or interaction model view Correct answer.

Explanation

The integration flow or interaction model view captures which participants exchange which messages, in what order, and through which channels. Physical network, retention, and access control artifacts describe infrastructure, lifecycle, and permissions rather than interaction sequencing.

Question 3Describe and document integration architecture

What is the primary purpose of documenting an integration architecture at all?

  1. To eliminate the need for interface versioning
  2. To replace the need for testing environments
  3. To satisfy licensing requirements of middleware vendors
  4. To give stakeholders a shared, reviewable description of how systems connect and exchange data Correct answer.

Explanation

Integration architecture documentation exists so architects, developers, and operations staff share one reviewable description of connections, data flows, and constraints. It supports decisions and change impact analysis; it does not remove testing, licensing, or versioning obligations.

Question 4Describe and document integration architecture

Which term describes a documented, reusable pattern for connecting systems, such as publish-subscribe or request-reply, that an architect selects and records for a given integration?

  1. Change advisory board
  2. Integration pattern Correct answer.
  3. Data steward
  4. Deployment slot

Explanation

An integration pattern is a named, reusable solution shape such as publish-subscribe, request-reply, or file transfer that the architect selects and records. Deployment slots, data stewards, and change boards are unrelated operational or governance roles and mechanisms.

Question 5Describe and document integration architecture

When documenting an interface, why should the architect record both the syntactic contract and the semantic meaning of each field?

  1. Because syntactic contracts cannot be versioned
  2. Because matching data types alone does not prevent misinterpretation of values such as status codes or units Correct answer.
  3. Because semantics are only needed for graphical user interfaces
  4. Because semantic documentation replaces the need for message schemas

Explanation

Two systems can agree on a field's type and still disagree on what a value means, for example whether status 2 means shipped or cancelled, or whether an amount is in cents or units. Recording semantics alongside syntax prevents these integration defects.

Question 6Describe and document integration architecture

A team must document a batch integration that transfers a nightly extract file to a data warehouse. Which set of attributes is most relevant to record for that transfer?

  1. File naming convention, schedule, format, and delivery mechanism Correct answer.
  2. Incident severity matrix
  3. Team roster, office location, and holiday calendar
  4. Source code repository branch strategy

Explanation

For a file-based batch integration the essential documented attributes are the naming convention, the transfer schedule, the file format, and the delivery mechanism such as SFTP or object storage. The other options concern staffing, source control, or incident handling rather than the transfer contract.

Question 7Describe and document integration architecture

What distinguishes an application programming interface from a simple file drop as an integration style in architecture documentation?

  1. An API cannot be documented in an architecture repository
  2. An API exposes callable operations with defined request and response contracts, while a file drop exchanges whole documents on a schedule Correct answer.
  3. A file drop always provides stronger transactional guarantees
  4. An API requires no error handling documentation

Explanation

An API exposes discrete callable operations with defined request and response contracts, typically synchronous, whereas a file drop transfers whole documents on a schedule. Both styles must be documented, and neither inherently guarantees stronger transactional behavior.

Question 8Describe and document integration architecture

Which statement best describes the role of a canonical data model in integration architecture documentation?

  1. It provides a shared, system-neutral representation that maps to each participating system's local format Correct answer.
  2. It replaces the need for transformation logic
  3. It stores the production database for every integrated system
  4. It is a security policy governing message encryption

Explanation

A canonical data model is a system-neutral representation to which each participant's local format is mapped, reducing point-to-point transformations. It is a design artifact, not a database, transformation substitute, or security policy.

Question 9Describe and document integration architecture

An architect documents a synchronous request-reply integration between a portal and a pricing service. The pricing service occasionally takes longer than the portal's timeout. Which documentation gap most directly causes operational confusion during such delays?

  1. The deployment diagram omits the data center floor plan
  2. The interface description omits timeout values, retry behavior, and the expected response when the call exceeds the limit Correct answer.
  3. The glossary omits the names of the executive sponsors
  4. The capacity plan omits marketing campaign dates

Explanation

For synchronous integrations, documenting timeouts, retry policy, and the defined fallback response is essential because these determine observable behavior under latency. Floor plans, sponsor names, and campaign dates do not explain what happens when a call exceeds its limit.

Question 10Describe and document integration architecture

A messaging integration uses at-least-once delivery. Which behavior must the architecture documentation explicitly state so that consumers are built correctly?

  1. The broker guarantees ordering across all topics
  2. Consumers must be idempotent because duplicate messages can be delivered Correct answer.
  3. Consumers may assume each message arrives exactly once
  4. Producers must disable acknowledgements

Explanation

At-least-once delivery permits duplicates, so the documented contract must require consumers to process messages idempotently. It cannot promise exactly-once arrival, and it says nothing about disabling acknowledgements or global ordering guarantees.

Question 11Describe and document integration architecture

When documenting error handling for an integration, which element makes the contract testable by both producer and consumer teams?

  1. A reference to the vendor's general support portal
  2. A catalog of defined error codes with the conditions that trigger each one Correct answer.
  3. A statement that errors will be handled appropriately
  4. A note that the integration is business critical

Explanation

A catalog of specific error codes tied to triggering conditions gives both teams a concrete, verifiable contract they can test against. Vague assurances, vendor portals, and criticality labels provide no testable behavior.

Question 12Describe and document integration architecture

An architect must record how a legacy mainframe system participates in a modern event-driven landscape without changing the mainframe. Which documentation approach best captures the adaptation?

  1. Document the mainframe only in the disaster recovery plan
  2. Document an adapter or anti-corruption layer that translates between mainframe formats and the event contract Correct answer.
  3. Omit the mainframe from the integration view
  4. Document the mainframe as fully event-native

Explanation

An adapter or anti-corruption layer isolates the legacy system, translating its formats and protocols into the modern event contract while protecting both sides from change. Describing the mainframe as event-native, omitting it, or hiding it in a DR plan misrepresents the architecture.

Question 13Describe and document integration architecture

Which documentation element most clearly communicates ownership and accountability for a published interface?

  1. The named owning team and contact route recorded against the interface entry Correct answer.
  2. The physical server hostname
  3. The programming language used to build the interface
  4. The average message size

Explanation

Recording the owning team and a contact route establishes who is accountable for the interface and how to reach them. Language, hostname, and message size are technical attributes that do not assign responsibility.

Question 14Describe and document integration architecture

A team documents an integration using a sequence diagram plus a field-level schema. Which additional artifact best closes the gap for operations staff who must diagnose failures at runtime?

  1. A list of past project managers
  2. A mapping of correlation identifiers and log points across the participating systems Correct answer.
  3. A glossary of executive titles
  4. A marketing brochure describing the integration

Explanation

Operations staff need to trace a single transaction across systems, which requires knowing the correlation identifiers and where each system logs them. Design diagrams and schemas explain structure but not runtime traceability; the other options are irrelevant.

Question 15Describe and document integration architecture

In documenting a publish-subscribe integration, why must the architect record both the topic structure and the subscriber inventory?

  1. Because topic structure governs routing while the subscriber inventory reveals who depends on each message and what impact a change would have Correct answer.
  2. Because topic structure is only relevant to producers
  3. Because subscribers must approve the topic naming convention before publication
  4. Because the subscriber inventory replaces the need for message schemas

Explanation

Topic structure determines how messages are routed, and the subscriber inventory identifies every dependent consumer so change impact can be assessed. Approval workflow, producer-only relevance, and schema replacement are not reasons for recording both.

Question 16Describe and document integration architecture

An integration document specifies that a customer record is mastered in the CRM system and propagated to billing and support. Which architectural concept is being documented?

  1. Load balancing strategy
  2. Network segmentation
  3. System of record and data ownership Correct answer.
  4. Encryption key rotation

Explanation

Naming the CRM as the authoritative source and describing downstream propagation documents the system of record and data ownership for that entity. Load balancing, segmentation, and key rotation are infrastructure and security concerns unrelated to data authority.

Question 17Describe and document integration architecture

Which practice best keeps integration architecture documentation trustworthy over time?

  1. Restricting documentation access to a single author
  2. Replacing the documentation with meeting minutes
  3. Treating the documentation as a versioned artifact updated through the same change process as the interfaces it describes Correct answer.
  4. Publishing the documentation once at project close and archiving it

Explanation

Versioning the documentation and tying updates to the interface change process keeps it aligned with reality. One-time publication, single-author restriction, and substituting meeting minutes all cause drift and loss of trust.

Question 18Describe and document integration architecture

A document shows an integration labeled as fire-and-forget. What must the architect clarify so consumers are not misled about reliability?

  1. Whether the servers are virtual or physical
  2. Whether the middleware vendor is certified
  3. Whether failures are retried, dead-lettered, or silently dropped Correct answer.
  4. Whether the payload uses XML or JSON

Explanation

Fire-and-forget describes the caller not waiting for a response, but it says nothing about what happens to failed messages, so the documentation must state retry, dead-letter, or drop behavior. Payload format, vendor certification, and host type do not address reliability expectations.

Question 19Describe and document integration architecture

Which element of an integration architecture document most directly supports impact analysis when a shared service changes its response format?

  1. A list of firewall rules
  2. A traceable inventory linking each interface to its consumers Correct answer.
  3. A staffing plan for the operations team
  4. A summary of past outage durations

Explanation

Impact analysis requires knowing which consumers depend on a given interface, which a traceable interface-to-consumer inventory provides. Firewall rules, staffing plans, and outage summaries do not identify affected dependents.

Question 20Describe and document integration architecture

An architect is reconciling two documents: one shows a nightly batch feed between inventory and finance, the other shows a real-time API for the same data. What is the most rigorous way to resolve the discrepancy before publication?

  1. Verify the actual runtime behavior and authoritative source with the owning teams, then correct and version the affected document Correct answer.
  2. Delete the older document without investigation
  3. Merge the two descriptions into a single hybrid statement
  4. Publish both documents unchanged so readers can choose

Explanation

Conflicting descriptions must be resolved against observed runtime behavior and the owning teams' authority, after which the corrected document is versioned. Publishing contradictions, deleting evidence, or inventing a hybrid all degrade trust and accuracy.

Question 21Describe and document integration architecture

A document describes an integration as exactly-once without stating the mechanism. Why is this a documentation defect in a distributed architecture?

  1. Exactly-once end-to-end delivery requires specific mechanisms such as idempotent consumers or transactional outbox, and omitting them hides real failure modes Correct answer.
  2. Because exactly-once delivery is trivially achieved by any message broker
  3. Because the term exactly-once refers only to file transfers
  4. Because documenting mechanisms is the vendor's responsibility, not the architect's

Explanation

End-to-end exactly-once behavior is not free; it depends on mechanisms such as idempotent processing, deduplication, or a transactional outbox, and the documentation must state which are used. Without that, readers cannot assess duplicate or loss risk, and no broker makes it trivial.

Question 22Describe and document integration architecture

Two teams each document the same interface with different field cardinalities, one allowing many line items and one allowing a single line item. Which action best restores a single defensible contract?

  1. Average the two cardinalities into a compromise value
  2. Keep both versions and let runtime validation decide
  3. Remove cardinality from both documents
  4. Convene both owning teams to agree the authoritative cardinality, record the rationale, and republish one versioned contract Correct answer.

Explanation

Conflicting contracts are resolved by the owning teams agreeing on authoritative semantics, capturing the rationale, and publishing one versioned contract all parties build against. Averaging, deferring to runtime, or deleting the constraint leaves consumers exposed to incompatible assumptions.

Question 23Describe and document integration architecture

A document lists an integration as asynchronous but the sequence diagram shows the caller blocking until a response returns. Which interpretation should the architect apply when correcting the record?

  1. Both descriptions can be correct if the payload is small
  2. The label takes precedence because labels are authoritative over diagrams
  3. The diagram should be deleted because diagrams are illustrative only
  4. The diagram reflects synchronous behavior, so the label is wrong and the reliability and timeout documentation must follow the synchronous contract Correct answer.

Explanation

Observed blocking behavior defines a synchronous interaction, so the label is the error and the surrounding timeout, retry, and failure documentation must match synchronous semantics. Labels do not override evidence, payload size is irrelevant, and deleting the diagram removes valid evidence.

Question 24Describe and document integration architecture

An architect must document a cross-domain integration where each domain owns its data and no shared database is permitted. Which documentation decision best preserves that constraint for future reviewers?

  1. Leave the constraint implicit in team habits
  2. Describe the shared database schema as the integration contract
  3. Record the constraint as an explicit architectural decision with rationale, and describe each interface as a published contract rather than a shared store Correct answer.
  4. Document only the current point-to-point connections without the rationale

Explanation

Making the no-shared-database constraint an explicit, rationale-bearing architectural decision preserves intent for future reviewers, and describing interfaces as published contracts reinforces domain ownership. Documenting a shared schema, leaving the rule implicit, or omitting rationale all invite later violations.

Question 25Describe and document integration architecture

A document claims a message channel is ordered, but the design uses multiple competing consumers on a partitioned topic. What must the architect verify and record?

  1. That partitioning should be removed to guarantee order
  2. That ordering is guaranteed only within a partition key, and state the key and its consumer concurrency assumptions Correct answer.
  3. That ordering is unnecessary once consumers are idempotent
  4. That ordering holds globally across all partitions and consumers

Explanation

With partitioned topics and competing consumers, ordering typically holds only within a partition, so the documentation must state the partition key and the concurrency assumptions consumers rely on. Global ordering, idempotency as a substitute, and removing partitioning are incorrect or impractical claims.

Question 26Describe and document integration architecture

When documenting an integration architecture, which artifact defines the agreed technical contract between a service provider and its consumers, including operations, message formats, and protocol bindings?

  1. A project schedule showing delivery milestones for the integration build
  2. A capacity plan projecting infrastructure growth over three years
  3. An interface specification or service contract attached to the integration record Correct answer.
  4. A stakeholder register listing business sponsors of each system

Explanation

The interface specification is the artifact that fixes what is exchanged, in what format, and over which protocol, so producer and consumer can build and test against the same definition. Schedules, capacity plans, and stakeholder registers support delivery and governance but do not define the technical contract.

Question 27Describe and document integration architecture

An architect is documenting a cross-domain integration where each domain owns its data and no shared database is permitted. Which documentation approach best captures the required decoupling?

  1. Record the shared database schema both domains will read and write directly
  2. Describe each domain's published interface and the events exchanged, with no direct data-store access shown Correct answer.
  3. Document a single global entity model that all domains must adopt unchanged
  4. State that the domains will synchronize by nightly full-table replication of each other's stores

Explanation

When domain ownership is a constraint, the documentation should show communication only through published interfaces and events, which preserves autonomy and prevents hidden coupling. Showing shared or replicated stores would contradict the stated architectural rule and mislead implementers.

Question 28Describe and document integration architecture

An integration record describes a channel as strictly ordered, but the design uses multiple competing consumers on a partitioned topic. What must the architect document to make the ordering claim defensible?

  1. That ordering holds because each consumer applies idempotent writes to its own store
  2. That ordering is guaranteed globally because the broker persists every message to disk
  3. That ordering is irrelevant once consumers acknowledge messages individually
  4. That ordering is preserved only within a partition key, and consumers of the same key must not process concurrently Correct answer.

Explanation

With competing consumers on a partitioned topic, ordering can only be asserted per partition or key, and only if messages sharing a key are processed serially. The documentation must state the keying rule and the concurrency constraint, otherwise the global ordering claim is false.

Question 29Describe and document integration architecture

A document labels an integration as fire-and-forget, yet the flow requires the sender to know whether the receiver accepted the request before continuing. Which correction makes the documentation accurate?

  1. Reclassify the interaction as request-reply or asynchronous with acknowledgement, and show the response path Correct answer.
  2. Keep the label and specify a longer timeout on the sender side
  3. Keep the label and add a note that failures are logged by the receiver
  4. Reclassify the interaction as batch and move it to a nightly schedule

Explanation

Fire-and-forget means the sender does not wait for or depend on any response, so an interaction that requires confirmation is request-reply or at minimum asynchronous with acknowledgement. The documentation must show the response or acknowledgement path so consumers understand the dependency.

Question 30Describe and document integration architecture

Two integration documents describe the same interface with conflicting field cardinalities: one allows many line items per order, the other allows exactly one. What is the most rigorous way to resolve and record the discrepancy in the architecture documentation?

  1. Trace the cardinality to the authoritative schema and business rule, record the decision and its rationale, and correct both documents to a single version Correct answer.
  2. Adopt the more permissive cardinality in both documents to avoid rejecting valid messages
  3. Remove the cardinality from both documents and let runtime validation decide
  4. Keep both versions and note that implementers should follow whichever matches their system

Explanation

Conflicting contracts must be resolved against the authoritative source and business rule, then recorded with the decision rationale so the documentation has one defensible version. Simply picking the looser option or leaving ambiguity pushes the conflict into production behavior.

Question 31Design integration solutions using MuleSoft's approach and tooling

In Anypoint Platform, which component is the central repository for reusable APIs, fragments, and their versioned assets that can be shared across projects?

  1. Anypoint Monitoring
  2. Anypoint Exchange Correct answer.
  3. Runtime Manager
  4. API Manager

Explanation

Anypoint Exchange is the catalog where teams publish and discover reusable assets such as REST APIs, fragments, connectors, and templates. Publishing to Exchange enables dependency-based reuse across design projects.

Question 32Design integration solutions using MuleSoft's approach and tooling

Which API-led connectivity layer is intended to expose data from a single system of record with minimal transformation so it can be reused by many consumers?

  1. System API Correct answer.
  2. Experience API
  3. Process API
  4. BFF API

Explanation

System APIs sit closest to systems of record and provide a stable, reusable abstraction over a specific backend. They isolate consumers from backend protocol and data-model details while doing minimal orchestration.

Question 33Design integration solutions using MuleSoft's approach and tooling

A team wants to define a REST API contract in code before implementation so that mocking and documentation are generated automatically. Which MuleSoft approach fits best?

  1. Configure an HTTP Listener in a new Mule application and enable the Mocking service
  2. Design the API in API Designer using RAML or OAS and publish it to Exchange Correct answer.
  3. Build the flows first in Anypoint Studio and export the project as a JAR
  4. Create a private Maven repository and upload the compiled application

Explanation

Design-first means authoring a specification (RAML or OAS) in API Designer, which supports mocking and auto-generated documentation once published to Exchange. The contract then drives implementation and consumer contracts.

Question 34Design integration solutions using MuleSoft's approach and tooling

Which Anypoint Platform capability lets multiple implementation instances of the same API share a single contract and consumer registration?

  1. Individual client certificates per application
  2. API autodiscovery linked to an API instance in API Manager Correct answer.
  3. Runtime Manager alert policies
  4. A separate HTTP Listener per deployment

Explanation

API autodiscovery associates a deployed application with an API instance in API Manager, so policies and client contracts apply across all instances of that API. This centralizes governance instead of duplicating configuration per deployment.

Question 35Design integration solutions using MuleSoft's approach and tooling

A designer needs to reuse common error-handling traits and data types across several RAML specifications. What is the recommended MuleSoft mechanism?

  1. Store shared definitions in a JSON schema served over HTTP
  2. Convert every specification to OAS before sharing
  3. Copy the definitions into each specification manually
  4. Publish a RAML fragment to Exchange and include it via !include Correct answer.

Explanation

RAML fragments are reusable specification parts published to Exchange and pulled in with !include, keeping definitions consistent across APIs. Manual copying causes drift and defeats design-time reuse.

Question 36Design integration solutions using MuleSoft's approach and tooling

Which MuleSoft tooling is used to visually model and simulate an integration flow, including mocking API responses, before writing implementation code?

  1. Anypoint Monitoring dashboards
  2. Anypoint CLI
  3. Anypoint Studio with the APIkit mocking capability Correct answer.
  4. Anypoint Flow Designer

Explanation

Anypoint Studio supports APIkit-based generation and mocking from a published specification, letting developers simulate endpoints before implementation. This validates the contract early against consumer expectations.

Question 37Design integration solutions using MuleSoft's approach and tooling

An architect wants to apply cross-cutting concerns such as rate limiting and OAuth 2.0 token enforcement consistently to an API without changing its implementation code. Which approach should be used?

  1. Attach policies to the API instance in API Manager Correct answer.
  2. Encode the checks in the RAML specification only
  3. Configure global elements in each Mule project
  4. Add custom validation logic in every flow

Explanation

API Manager policies enforce concerns like rate limiting and OAuth enforcement at the gateway layer, independent of implementation code. This keeps governance consistent and avoids duplicating logic across flows.

Question 38Design integration solutions using MuleSoft's approach and tooling

Which statement best describes the role of a Process API in an API-led architecture?

  1. It exposes a single backend system with minimal transformation
  2. It formats responses for a specific mobile channel
  3. It stores API specifications for reuse
  4. It aggregates and orchestrates multiple System APIs to implement business logic Correct answer.

Explanation

Process APIs combine and orchestrate multiple System APIs to implement business processes, decoupling channels from backend composition. They centralize reusable business logic rather than channel-specific formatting.

Question 39Design integration solutions using MuleSoft's approach and tooling

A team wants to generate APIkit scaffolding from a RAML specification inside Anypoint Studio. What must be true for generation to succeed?

  1. The specification must use OAS 3.0 instead of RAML
  2. The application must be deployed to CloudHub first
  3. The project must already contain an HTTP Listener on port 8081
  4. The RAML must be published to Exchange and referenced by a Maven dependency Correct answer.

Explanation

APIkit scaffolding in Studio pulls the specification from Exchange through a Maven dependency, so the RAML must be published there first. Generation then creates flows and routers aligned to the contract.

Question 40Design integration solutions using MuleSoft's approach and tooling

Which Anypoint Platform feature provides a unified catalog of APIs with lifecycle states such as Design, Published, and Deprecated for governance?

  1. Anypoint Exchange with API lifecycle states Correct answer.
  2. Runtime Manager applications
  3. Anypoint Monitoring alerts
  4. API Manager instances

Explanation

Exchange tracks API assets and their lifecycle states, giving teams visibility into maturity and governance. This supports reuse decisions and deprecation planning across the organization.

Question 41Design integration solutions using MuleSoft's approach and tooling

A designer must document pagination, filtering, and standard error responses consistently across many APIs. Which design practice best supports this?

  1. Hardcode query parameters in each endpoint
  2. Define reusable traits and resource types in a shared RAML library Correct answer.
  3. Document these only in the implementation code
  4. Rely on consumers to infer pagination behavior

Explanation

Traits and resource types capture cross-cutting patterns like pagination and error handling once, then apply them across resources and APIs. This produces consistent, self-documenting contracts.

Question 42Design integration solutions using MuleSoft's approach and tooling

Which MuleSoft capability enables a designer to create a mock endpoint from a published specification so front-end teams can develop in parallel?

  1. Exchange mocking service Correct answer.
  2. Anypoint Monitoring log points
  3. Runtime Manager deployment targets
  4. API Manager policy templates

Explanation

Exchange's mocking service generates live mock endpoints directly from a published specification, allowing parallel front-end and back-end development. It validates that the contract supports consumer needs before implementation.

Question 43Design integration solutions using MuleSoft's approach and tooling

An organization wants to standardize how all teams implement error responses across APIs. Which combination best supports this goal?

  1. Ad hoc logging in each flow
  2. Policies that suppress all error responses
  3. Unique error formats per team to maximize flexibility
  4. A shared RAML fragment for error schemas plus a reusable error-handling flow in a common library Correct answer.

Explanation

Publishing a shared error-schema fragment and a reusable error-handling flow creates a consistent contract and implementation pattern. Reuse through Exchange keeps teams aligned without duplicating logic.

Question 44Design integration solutions using MuleSoft's approach and tooling

Which Anypoint Platform component is used to define and manage client applications and their access contracts to an API?

  1. Anypoint Exchange
  2. Anypoint Studio
  3. Runtime Manager
  4. API Manager with contract management Correct answer.

Explanation

API Manager handles client application registration and contract approval for API instances, controlling who can consume an API. This ties consumer access to governance policies.

Question 45Design integration solutions using MuleSoft's approach and tooling

A design team wants to enforce that all new APIs follow organizational naming and documentation standards before implementation begins. Which practice best achieves this?

  1. Require developers to memorize the standards
  2. Let each team choose its own conventions
  3. Publish design guidelines and validate specifications during design review in Exchange Correct answer.
  4. Apply standards only after deployment

Explanation

Publishing guidelines and reviewing specifications in Exchange before implementation catches deviations early, when changes are cheap. This embeds governance into the design phase rather than after deployment.

Question 46Design integration solutions using MuleSoft's approach and tooling

Which statement accurately distinguishes an Experience API from a Process API?

  1. Experience APIs store specifications, while Process APIs deploy applications
  2. Experience APIs expose one system of record, while Process APIs expose none
  3. Experience APIs enforce policies, while Process APIs manage contracts
  4. Experience APIs tailor data for a channel, while Process APIs orchestrate backend systems Correct answer.

Explanation

Experience APIs shape responses for specific channels or audiences, whereas Process APIs combine multiple systems to implement business logic. Keeping these concerns separate improves reuse and maintainability.

Question 47Design integration solutions using MuleSoft's approach and tooling

A team needs to expose a legacy SOAP service as a modern REST API for reuse. Which MuleSoft design approach is most appropriate?

  1. Build a separate custom integration per consumer
  2. Create a System API that wraps the SOAP service and exposes a REST contract Correct answer.
  3. Document the SOAP service in Exchange without an API layer
  4. Expose the raw SOAP WSDL directly to all consumers

Explanation

A System API abstracts the legacy SOAP service behind a stable REST contract, isolating consumers from legacy protocols. This enables reuse and protects consumers from backend changes.

Question 48Design integration solutions using MuleSoft's approach and tooling

Which MuleSoft feature allows a designer to specify reusable security schemes such as OAuth 2.0 in a RAML specification?

  1. Object Store configuration
  2. securitySchemes declared in the RAML and applied at the API level Correct answer.
  3. HTTP Listener configuration
  4. Global error handler

Explanation

RAML securitySchemes define authentication mechanisms like OAuth 2.0, which are then applied at the API or method level. This documents security expectations in the contract for consumers and tooling.

Question 49Design integration solutions using MuleSoft's approach and tooling

An architect wants to ensure that changes to a shared RAML fragment do not silently break dependent APIs. Which practice best mitigates this risk?

  1. Copy fragments into each project to avoid dependencies
  2. Allow fragments to change without versioning
  3. Disable validation in API Designer
  4. Version the fragment and review dependent APIs before promoting new versions Correct answer.

Explanation

Versioning fragments and reviewing dependents before promotion prevents unintended breaking changes across APIs. This maintains contract stability for consumers relying on shared definitions.

Question 50Design integration solutions using MuleSoft's approach and tooling

Which Anypoint Platform capability supports automated testing of an API specification against its implementation during CI?

  1. Exchange search
  2. Runtime Manager alerting
  3. Anypoint Monitoring dashboards
  4. MUnit with APIkit-based contract tests Correct answer.

Explanation

MUnit tests, combined with APIkit-generated flows, can validate that implementations conform to the contract within CI pipelines. This catches contract drift before deployment.