サンプル問題 1： Mule applications need to be deployed to CloudHub so they can access on-premises database systems. These systems store sensitive and hence tightly protected data, so are not accessible over the internet. What network architecture supports this requirement?
A: An Anypoint VPC connected to the on-premises network using an IPsec tunnel or AWS DirectConnect, plus matching firewall rules in the VPC and on-premises network
B: Static IP addresses for the Mule applications deployed to the CloudHub Shared Worker Cloud, plus matching firewall rules and IP whitelisting in the on-premises network
C: An Anypoint VPC with one Dedicated Load Balancer fronting each on-premises database system, plus matching IP whitelisting in the load balancer and firewall rules in the VPC and on-premises network
D: Relocation of the database systems to a DMZ in the on-premises network, with Mule applications deployed to the CloudHub Shared Worker Cloud connecting only to the DMZ
正解：A
Explanation: * "Relocation of the database systems to a DMZ in the on-premises network, with Mule applications deployed to the CloudHub Shared Worker Cloud connecting only to the DMZ" is not a feasible option * "Static IP addresses for the Mule applications deployed to the CloudHub Shared Worker Cloud, plus matching firewall rules and IP whitelisting in the on-premises network" - It is risk for sensitive data. - Even if you whitelist the database IP on your app, your app wont be able to connect to the database so this is also not a feasible option * "An Anypoint VPC with one Dedicated Load Balancer fronting each on-premises database system, plus matching IP whitelisting in the load balancer and firewall rules in the VPC and on-premises network" Adding one VPC with a DLB for each backend system also makes no sense, is way too much work. Why would you add a LB for one system. * Correct answer. "An Anypoint VPC connected to the on-premises network using an IPsec tunnel or AWS DirectConnect, plus matching firewall rules in the VPC and on-premises network" IPsec Tunnel You can use an IPsec tunnel with network-to-network configuration to connect your on-premises data centers to your Anypoint VPC. An IPsec VPN tunnel is generally the recommended solution for VPC to on-premises connectivity, as it provides a standardized, secure way to connect. This method also integrates well with existing IT infrastructure such as routers and appliances. Reference: https://docs.mulesoft.com/runtime-manager/vpc-connectivity-methods-concept
サンプル問題 2： An API client is implemented as a Mule application that includes an HTTP Request operation using a default configuration. The HTTP Request operation invokes an external API that follows standard HTTP status code conventions, which causes the HTTP Request operation to return a 4xx status code. What is a possible cause of this status code response?
A: An error occurred inside the external API implementation when processing the HTTP request that was received from the outbound HTTP Request operation of the Mule application
B: The external API reported that the API implementation has moved to a different external endpoint
C: The HTTP response cannot be interpreted by the HTTP Request operation of the Mule application after it was received from the external API
D: The external API reported an error with the HTTP request that was received from the outbound HTTP Request operation of the Mule application
正解：D
Explanation: Correct choice is: "The external API reported an error with the HTTP request that was received from the outbound HTTP Request operation of the Mule application" Understanding HTTP 4XX Client Error Response Codes: A 4XX Error is an error that arises in cases where there is a problem with the user’s request, and not with the server. Such cases usually arise when a user’s access to a webpage is restricted, the user misspells the URL, or when a webpage is nonexistent or removed from the public’s view. In short, it is an error that occurs because of a mismatch between what a user is trying to access, and its availability to the user ― either because the user does not have the right to access it, or because what the user is trying to access simply does not exist. Some of the examples of 4XX errors are 400 Bad Request The server could not understand the request due to invalid syntax. 401 Unauthorized Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response. 403 Forbidden The client does not have access rights to the content; that is, it is unauthorized, so the server is refusing to give the requested resource. Unlike 401, the client's identity is known to the server. 404 Not Found The server can not find the requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 to hide the existence of a resource from an unauthorized client. This response code is probably the most famous one due to its frequent occurrence on the web. 405 Method Not Allowed The request method is known by the server but has been disabled and cannot be used. For example, an API may forbid DELETE-ing a resource. The two mandatory methods, GET and HEAD, must never be disabled and should not return this error code. 406 Not Acceptable This response is sent when the web server, after performing server-driven content negotiation, doesn't find any content that conforms to the criteria given by the user agent. The external API reported that the API implementation has moved to a different external endpoint cannot be the correct answer as in this situation 301 Moved Permanently The URL of the requested resource has been changed permanently. The new URL is given in the response. In Lay man's term the scenario would be: API CLIENT ―> MuleSoft API - HTTP request “Hey, API.. process this” ―> External API API CLIENT <C MuleSoft API - http response "I'm sorry Client.. something is wrong with that request" <C (4XX) External API
サンプル問題 3： An XA transaction Is being configured that involves a JMS connector listening for Incoming JMS messages. What is the meaning of the timeout attribute of the XA transaction, and what happens after the timeout expires?
A: The time that is allowed to pass between committing the transaction and the completion of the Mule flow After the timeout, flow processing triggers an error
B: The time that Is allowed to pass between receiving JMS messages on the same JMS connection After the timeout, a new JMS connection Is established
C: The time that Is allowed to pass without the transaction being ended explicitly After the timeout, the transaction Is forcefully rolled-back
D: The time that Is allowed to pass for state JMS consumer threads to be destroyed After the timeout, a new JMS consumer thread is created
正解：C
Explanation: * Setting a transaction timeout for the Bitronix transaction manager ● Set the transaction timeout either C In wrapper.conf C In CloudHub in the Properties tab of the Mule application deployment ● The default is 60 secs. It is defined as mule.bitronix.transactiontimeout = 120 * This property defines the timeout for each transaction created for this manager. If the transaction has not terminated before the timeout expires it will be automatically rolled back. --------------------------------------------------------------------------------------------------------------------- Additional Info around Transaction Management: Bitronix is available as the XA transaction manager for Mule applications ● To use Bitronix, declare it as a global configuration element in the Mule application <bti:transaction-manager /> ● Each Mule runtime can have only one instance of a Bitronix transaction manager, which is shared by all Mule applications ● For customer-hosted deployments, define the XA transaction manager in a Mule domain C Then share this global element among all Mule applications in the Mule runtime
