Free AD0-E712 Practice Test

To use the "Login as Customer" feature in Adobe Commerce, two primary conditions must be met. First, the feature must be globally enabled in the administrative configuration settings under Stores > Configuration > Customers > Login as Customer. This activates the functionality for the entire instance. Second, the specific administrator who needs to use the feature must have the necessary permissions. This is configured by editing the administrator's user role and explicitly granting access to the "Login as Customer" resource within the role's resource tree. Both the global setting and the role-specific permission are required for the feature to be accessible and usable by an admin.

C. Ensure the feature is enabled for the customer on whose behalf admin will log in This is incorrect. The "Login as Customer" functionality is an administrative tool and does not require any specific setting or opt-in on the individual customer's account.
D. Ensure that the customer clicks Allow Remote Assistance in a browser modal that appears after the admin sends a login request. This is incorrect. The feature allows an admin to directly impersonate a customer without any real-time interaction or approval from the customer. The process does not involve a request/approval flow.

1. Adobe Commerce User Guide, Login as Customer.

Reference for A: Under the section "Step 1: Enable Login as Customer," the guide states: "On the Admin sidebar, go to Stores > Settings > Configuration. In the left panel, expand Customers and choose Login as Customer. Set Enable Login as Customer to Yes."

Reference for B: Under the section "Step 2: Configure user role permissions," the guide instructs: "On the Admin sidebar, go to System > Permissions > User Roles. ... In the left panel, click Role Resources. ... To grant access to only login as customer, navigate to Customers > Actions > Login as Customer and select the checkbox." This confirms that the admin's role must be granted specific permission.

The Adobe Commerce scope hierarchy is designed for this exact scenario. A single Website is sufficient as the core business, customer data, and base currency can be shared. Under this website, a single Store is used to manage a single product catalog. The requirement for two languages, English and Spanish, is handled by creating two Store Views. Each store view is configured for a specific language. The currency configuration allows setting multiple "Allowed Currencies" (US Dollars and Mexican Pesos) at the Website scope, which makes a currency switcher available on the frontend for both store views, allowing customers to switch currencies independently of the selected language.

B. 1 Website, 1 Store, 4 Store Views: This is inefficient. It would imply creating a separate store view for each language-currency pair, which prevents the independent switching of currency as required by the prompt.
C. 2 Websites, 2 Stores, 4 Store Views: This is an unnecessarily complex structure. Multiple websites are only needed for fundamentally separate businesses, domains, or customer bases, which is not described in the scenario.

1. Adobe Commerce Developer Documentation, "Websites, stores, and views".

Section: "Store views"

Quote/Paraphrase: The documentation explicitly states, "Store views are generally used to handle different languages on your storefront." This supports using two store views for the two required languages. It also clarifies that all store views under a single store share the same catalog.

Reference: Adobe Commerce Developer Documentation > Get Started > Basic Concepts > Websites, stores, and views.

2. Adobe Commerce User Guide, "Currency".

Section: "Currency Configuration"

Quote/Paraphrase: The guide explains that "Allowed Currencies" are set at the Website scope. This means a single website can be configured to support both USD and MXN. The customer can then choose which of the allowed currencies to use for shopping, independent of the store view (language) they are using.

Reference: Adobe Commerce User Guide > Stores > Configuration > General > Currency Setup.

3. Adobe Commerce User Guide, "Stores".

Section: "Store Scopes"

Quote/Paraphrase: This section details the hierarchical nature of Website > Store > Store View. It clarifies that a single website is the minimum top-level entity and that a store is primarily for defining a product catalog structure (root category), which is singular in this scenario.

Reference: Adobe Commerce User Guide > Stores > All Stores.

In the Adobe Commerce order management workflow, a credit memo is the specific document used to process a refund for an order that has been invoiced. Creating a credit memo reverses the charge recorded by the invoice and allows the Business Practitioner to return funds to the customer. This can be for a full or partial refund and can be processed online through the payment gateway or recorded as an offline refund.

A. Cancel the order. An order can typically only be canceled before an invoice is generated and payment is captured. Canceling is not the correct procedure for refunding a completed financial transaction.
C. Create a return for the order. Creating a return (RMA) manages the logistics of a customer returning physical goods. While it often precedes a refund, it does not execute the financial transaction of returning money. ---

1. Adobe Commerce User Guide, "Credit Memos": "A credit memo is a document that shows the amount that is due the customer for a full or partial refund... You can print a credit memo for an order that has been invoiced." This document outlines the entire procedure, starting from an invoiced order.

Source: Adobe Experience League, Commerce User Guide, Sales, Credit Memos.

2. Adobe Commerce User Guide, "Order Workflow": The standard order workflow diagram and description illustrate that after an order is invoiced, the path to a refund is through the creation of a credit memo, which then sets the order status to Closed.

Source: Adobe Experience League, Commerce User Guide, Sales, Order Workflow.

3. Adobe Commerce User Guide, "Cancel an Order": This section explicitly states the limitations of canceling an order. "An order that has been invoiced and shipped cannot be canceled. Instead, you must create a credit memo to refund the transaction."

Source: Adobe Experience League, Commerce User Guide, Sales, Orders, Processing Orders, Step 6: Cancel an Order.

The General Data Protection Regulation (GDPR) establishes strict rules for obtaining consent. Consent must be demonstrable, meaning the data controller (the merchant) must be able to prove that valid consent was obtained. This requires keeping detailed records of who consented, when, how, and to what specific processing they agreed. Furthermore, consent must be freely given and specific. This means it cannot be bundled with other, non-essential items like general terms and conditions. Forcing a user to accept marketing to use a service is not considered freely given consent.

A. Opt-in boxes must be pre-ticked. This is explicitly forbidden by GDPR. Consent requires a clear, affirmative action; pre-ticked boxes rely on inaction and are not valid forms of consent.
D. Multiple marketing consents must be done with a single opt-in. This is incorrect. GDPR requires consent to be specific and granular. If there are different types of marketing (e.g., email, SMS), separate consent should be obtained for each.

1. Official Vendor Documentation (Adobe):

Adobe Commerce User Guide, "General Data Protection Regulation". This document outlines key GDPR principles for merchants. It states, "You must keep records of consent," which supports option B. It also specifies, "Consent should be unbundled from other terms and conditions," directly supporting option C. The guide further clarifies that "Implicit consent is no longer adequate" and "pre-checked opt-in boxes are invalid," which refutes option A.

Reference: Adobe Experience League. (n.d.). General Data Protection Regulation. Adobe Commerce User Guide. Retrieved from https://experienceleague.adobe.com/docs/commerce-admin/stores-sales/site-privacy/privacy-gdpr.html?lang=en

2. Official Legal Text (European Union):

Regulation (EU) 2016/679 (General Data Protection Regulation), Article 7, "Conditions for consent".

Paragraph 1 states: "the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data." This is the legal basis for option B.

Paragraph 2 states: "If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters..." This is the legal basis for option C.

Reference: Official Journal of the European Union. (2016, April 27). Regulation (EU) 2016/679 of the European Parliament and of the Council. L 119/1. Article 7, Paragraphs 1 & 2.

In Adobe Commerce, Layered Navigation allows customers to filter products based on specific attributes. For an attribute to be used as a filter, its "Catalog Input Type for Store Owner" must be one that provides a discrete set of options or a numerical range. The Dropdown and Price input types are natively designed for this purpose. Dropdown provides a predefined list of values (e.g., colors), while Price is a special attribute type that enables filtering by price ranges or a slider, both of which are core functionalities of layered navigation.

B. Date: The Date input type is not natively supported for use in layered navigation filters. Filtering by specific dates or date ranges typically requires customization or third-party extensions.
D. Text Field: A Text Field allows for free-form, unique text entries for each product, which is unsuitable for creating a consolidated list of filter options required by layered navigation.

1. Adobe Commerce User Guide, Product Attributes: In the section detailing Storefront Properties for an attribute, the guide specifies the requirements for layered navigation. It states, "To use an attribute in layered navigation, it must have a Catalog Input Type of Dropdown, Multiple Select, or Price."

Source: Adobe Commerce User Guide > Catalog > Catalog Management > Product Attributes > Storefront Properties section.

2. Adobe Commerce Developer Documentation, Product attributes: The developer documentation confirms the technical requirements for filterable attributes. An attribute can be set as filterable (isfilterable = 1) only if its frontend input type (frontendinput) is select (Dropdown), multiselect, or price.

Source: Adobe Commerce Developer Documentation > Development > PHTML, JS, and XML > Add product attributes > Attribute properties.

Cross-selling is a sales technique used to encourage a customer to purchase products that are complementary to an item they have already decided to buy. In the given scenario, a laptop case is a complementary and related product to a laptop. Suggesting this additional, related item at the point of sale is a direct application of the cross-selling principle. Adobe Commerce facilitates this by allowing merchants to configure cross-sell products that appear on the shopping cart page, prompting customers to add related items before checkout.

B. This describes an omnichannel fulfillment strategy known as "Buy Online, Pick up In-Store" (BOPIS), not a sales technique like cross-selling.
C. This is an example of upselling, which involves persuading a customer to purchase a more expensive or premium version of the same product.

1. Adobe Commerce Documentation, User Guide: Product Relationships.

Section: Cross-sell Products

Content: "Cross-sell items are products that are offered on the shopping cart page as a last-minute purchase before the checkout process begins. They are typically accessories for an item that the customer has already added to the cart." This directly supports the example of selling a laptop case (accessory) with a laptop. The documentation also explicitly defines up-sell items, confirming option C is incorrect.

2. Adobe Commerce Documentation, User Guide: Upsell, Cross-Sell, and Related Products.

Section: Cross-Sells

Content: "Cross-sell products appear on the shopping cart page, just before the customer begins checkout. Products that are commonly purchased together are good candidates for cross-sells." This reinforces that cross-selling involves offering complementary items at the cart stage.

Adobe Commerce includes a native "Order Archive" feature designed specifically for this purpose. It allows a Business Practitioner to clean up the primary Orders grid by moving orders that are in a final state (e.g., Complete, Canceled, Closed) into a separate archive. This improves the performance and manageability of the main grid. Archived orders are not deleted and can be easily viewed, searched, and retrieved from the archive for future reference or action, such as printing an invoice.

A. It requires custom code or a third-party module This is incorrect because order archiving is a native feature within Adobe Commerce, eliminating the need for custom development or external modules for this core functionality.
B. Change the order status to Archived This is incorrect as "Archived" is not a standard order status in the order processing workflow. Archiving is a separate action performed on an order, not a change of its status. ---

1. Adobe Experience League. (n.d.). Order Archive. Adobe Commerce User Guide.

Section: Order Archive

Content: This official documentation explicitly states, "The Order Archive feature gives you the ability to clean up your Orders grid by archiving orders... Archived orders can be viewed at any time, and can be retrieved from the archive if you need to print, or create a shipment or credit memo." This directly supports option C and refutes option A.

2. Adobe Experience League. (n.d.). Order Status. Adobe Commerce User Guide.

Section: Order status and workflow

Content: This page details the default order statuses (e.g., Pending, Processing, Complete, Canceled, Closed). It does not list "Archived" as a configurable status, confirming that archiving is a separate action, which makes option B incorrect.

The Adobe Commerce architecture uses a hierarchy of Website, Store, and Store View. To meet the merchant's requirements, a single website is sufficient as payment and shipping methods are shared and can be configured at this level. The need for two different category structures mandates the creation of two separate stores, as each store is assigned its own unique root category. Finally, each store requires at least one store view to be visible on the frontend. This configuration represents the most efficient and minimal setup.

A. Two websites, two stores, two store views: This is incorrect because creating two websites is unnecessary. Since payment and shipping methods are the same, they can be managed under a single website, making this option not the minimum required setup.
C. One website, one store, two store views: This is incorrect because all store views within a single store must share the same root category. This configuration cannot support the requirement for two different category structures.

1. Adobe Commerce Developer Guide, Fundamentals, Basic concepts: "A website is the top-level container for sites, shipping methods, payment methods, and more... A store is a child of a website. Products and Categories are managed on the store level. A store has a single root category." This confirms that payment/shipping methods are managed at the website level, while the root category (which defines the category structure) is set at the store level.

Source: Adobe Commerce Developer Guide > Fundamentals > Basic concepts > Websites, stores, and store views.

2. Adobe Commerce User Guide, Stores, All Stores: The process for creating a new store explicitly requires the selection of a "Root Category". This demonstrates that to have a different category structure, a new store must be created. Conversely, settings for payment and shipping methods are typically configured at the website scope, allowing them to be shared by all stores within that website.

Source: Adobe Commerce User Guide > Stores > Settings > All Stores > Create Store.

3. Adobe Commerce User Guide, Scope: "The scope setting determines the level of the configuration hierarchy where a setting applies... Website [scope]... includes all settings that apply to the base currency, taxation, and payment and shipping methods." This directly states that payment and shipping methods are a website-level configuration, reinforcing that only one website is needed.

Source: Adobe Commerce User Guide > Getting Started > Basic Configuration > Scope.

Magento Open Source provides a native data import feature accessible via System > Data Transfer > Import. This tool allows for the bulk import of specific data entities from a CSV file. Among the available "Entity Type" options are "Products" and "Customer Addresses". The "Products" import process supports numerous attributes, including description and shortdescription. The "Customer Addresses" entity type is specifically designed to bulk import multiple address records and associate them with existing customer accounts. Categories, however, are not a supported entity type for the native import functionality.

A. Category images: The native import tool in Magento Open Source does not have an entity type for "Categories," making it impossible to import category data, including images, in bulk.
B. Category descriptions: As with category images, category descriptions cannot be imported using the native bulk import feature because "Categories" is not a supported entity type.

1. Adobe Commerce User Guide - Import: This official guide details the native import process. The "Entity Type" section explicitly lists the available entities for import, which include "Products" and "Customer Addresses," but not "Categories."

Source: Adobe Experience League, Adobe Commerce User Guide.

Section: System > Data Transfer > Import > Import Settings > Entity Type. (Refer to the dropdown list of available entities in the documentation).

2. Adobe Commerce User Guide - Product CSV Data Structure: This document outlines the columns available in a product import CSV file, explicitly showing fields like description and shortdescription, confirming that product descriptions can be imported.

Source: Adobe Experience League, Adobe Commerce User Guide.

Section: Data Transfer > Import > Product CSV Data Structure.

3. Adobe Commerce User Guide - Customer and Address CSV Data Structure: This documentation details the structure for importing customer and address data, confirming that "Customer Addresses" is a distinct, importable entity.

Source: Adobe Experience League, Adobe Commerce User Guide.

Section: Data Transfer > Import > Customer and Address CSV Data Structure.

The Zero Subtotal Checkout payment method is specifically designed for situations where the customer's grand total is exactly zero. This scenario occurs when the total cost of all items in the cart, including any applicable shipping fees and taxes, is completely covered by a discount, coupon code, gift card, or store credit. When the balance due is zero, this method allows the customer to complete the checkout process without entering traditional payment information, as no payment is required.

A. If the discount does not cover the full value of the products, the grand total will be greater than zero, requiring a standard payment method.
B. If a shipping charge remains after the discount, the grand total is not zero, and the customer must use a different payment method to pay for shipping.

1. Adobe Commerce Documentation, Payment Methods, Zero Subtotal Checkout: "The Zero Subtotal Checkout payment method is available only when the grand total of an order is zero. An order with a zero grand total can occur when a discount is applied that is equal to the grand total... When the grand total of an order is zero, the Zero Subtotal Checkout method becomes the only payment method available during checkout." (Adobe Experience League, User Guide, "Payment Methods", Section: "Zero Subtotal Checkout").