Adobe AD0-E718 Adobe Commerce Architect Master Exam Practice Test

Page: 1 / 14
Total 50 questions
Question 1

An Architect is investigating a merchant's Adobe Commerce production environment where all customer session data is randomly being lost. Customer session data has been configured to be persisted using Redis, as are all caches (except full page cache, which is handled via Varnish).

After an initial review, the Architect is able to replicate the loss of customer session data by flushing the Magento cache storage, either via the Adobe Commerce Admin Panel or running bin/iuagento cache: flush on the command line. Refreshing all the caches in the Adobe Commerce Admin Panel or running bin/magento cache: clean on the command line does not cause session data to be lost.

What should be the next step?



Answer : C

Checking app/etc/env.php and making sure that the Redis configuration for caches and session data use different database numbers is the next step. This is because using the same database number for both caches and session data can cause session data to be lost when flushing the cache storage. By using different database numbers, the session data can be isolated from the cache data and avoid being overwritten.See Use Redis for session storage in the Adobe Commerce Help Center1. Reference: https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/cache/redis/redis-session.html?lang=en1


Question 2

An Adobe Commerce Architect is setting up a Development environment for an on-premises project that will be used for developers to specifically test functionality, not performance, before being passed to the Testing team.

The Magento application must run with the following requirements:

1. Errors should be logged and hidden from the user

2. Cache mode can only be changed from Command Line

3. Static files should be created dynamically and then cached

Which Application Mode is required to achieve this?



Answer : C

Developer Mode is the mode best suited to achieve the requirements set out by the Adobe Commerce Architect. In Developer Mode, errors are logged and hidden from the user, and the cache mode can only be changed from the command line. Additionally, static files are created dynamically and then cached, which is the desired behavior for this project.

Developer Mode is required to achieve the requirements. This is because developer mode enables the following features: Errors are logged and hidden from the user; cache mode can only be changed from command line; static files are created dynamically and then cached.See Application modes in the Adobe Commerce Help Center1. Reference: https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/setup/application-modes.html?lang=en1


Question 3

An Adobe Commerce Architect is supporting deployment and building tools for on-premises Adobe Commerce projects. The tool is executing build scripts on a centralized server and using an SSH connection to deploy to project servers.

A client reports that users cannot work with Admin Panel because the site breaks every time they change interface locale.

Considering maintainability, which solution should the Architect implement?



Answer : B

The 'setup:static-content:deploy' command allows you to generate static view files for specific locales. If you do not specify any locales, the command uses the default locale that is set in the configuration. To avoid breaking the site when changing interface locale in the Admin Panel, you need to generate static view files for all the locales that you want to use. You can do this by adjusting the tool's build script and adding the locales as arguments to the 'setup:static-content:deploy' command. For example:

bin/magento setup:static-content:deploy en_US fr_FR de_DE

This will generate static view files for English, French, and German locales. Reference: https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/setup/static-view.html?lang=en#generate-static-view-files


Question 4

An Architect is configuring the preload.keys for Redis on an Adobe Commerce on-premise instance.

The Architect discovers that the following cache keys are loaded on each frontend request: eav_entity_types,

GLOBAL_PLUGIN_LIST, DB_IS_UP_TO_DATE , SYSTEM_DEFAULT.

* The id_prefix of the frontend =>page_cache is set to 061_.

* The id_prefix of frontend => default: is not set.

* The Architect has enabled and configured Redis L2 caching.

How should the preload.keys be configured?

A)

B)

C)

D)



Answer : A

The preload.keys should be configured as shown in option A. This will allow Redis to preload the cache keys that are loaded on every page request, such as eav_entity_types, GLOBAL_PLUGIN_LIST, DB_IS_UP_TO_DATE , SYSTEM_DEFAULT. The keys should include the database prefix (061_) and the :hash suffix for L2 caching. The :hash suffix tells Redis to load only the hashes from Redis and the data from local storage. This will reduce the pressure on Redis and improve the performance of Magento.


Question 5

An Adobe Commerce Architect needs to ensure zero downtime during the deployment process of Adobe Commerce on-premises. Which two steps should the Architect follow? (Choose two.)



Answer : A, E

To ensure zero downtime during the deployment process of Magento 2 on-premises, the Architect should follow two steps:

Run bin/magento setup:upgrade --keep-generated to upgrade database. This will skip the regeneration of static content and code files during the upgrade process, which can take a long time and cause downtime. The static content and code files should be generated separately before or after the upgrade process.

Enable config flag under deployment/blue_green/enabled. This will enable the blue-green deployment strategy, which creates a copy of the current production environment (blue) and deploys the new code to it (green). Then, it switches the traffic from the blue environment to the green environment without any downtime. This option can be enabled by adding a line like deployment/blue_green/enabled: true to the .magento.env.yaml file.


Question 6

An existing Adobe Commerce website is moving to a headless implementation.

The existing website features an "All Brands" page, as well as individual pages for each brand. All brand-related pages are cached in Varnish using tags in the same manner as products and categories.

Two new GraphQL queries have been created to make this information available to the frontend for the new headless implementation:

During testing, the queries sometimes return out-of-date information.

How should this problem be solved while maintaining performance?



Answer : C

This option would allow caching GraphQL query results using Varnish or Fastly with proper invalidation and differentiation mechanisms.

To solve the problem of out-of-date information in GraphQL queries, the Architect should specify a @cache (cacheIdentity: path\T\identityClass) directive for each GraphQL query, corresponding to a class that adds cache tags for relevant brands and associated products. This will allow Varnish to invalidate the cache for these queries when the brand or product data changes. Option A is incorrect because it will make the queries cacheable without any cache tags, which will not solve the problem. Option B is incorrect because it will disable caching for these queries entirely, which will degrade performance. Reference: https://devdocs.magento.com/guides/v2.4/graphql/caching.html


Question 7

An Adobe Commerce store owner sets up a custom customer attribute "my.attribute" (type int).

An Architect needs to display customer-specific content on the home page to Customers with "my.attribute" greater than 3. The website is running Full Page Cache.

Using best practices, which two steps should the Architect take to implement these requirements? (Choose two.)



Answer : A, C

To display customer-specific content on the home page to Customers with ''my.attribute'' greater than 3, you need to use the following steps:

Use customer-data JS library to retrieve ''my.attribute'' value. The customer-data JS library allows you to access the customer data stored in the local storage of the browser. You can use the get() method to get the value of ''my.attribute'' for the current customer.

Add a new context value of ''my.attribute'' to Magento\Framework\App\Http\Context. The HTTP context is a mechanism that allows you to vary the cache of a page based on some parameters. By adding a new context value of ''my.attribute'', you can cache separate versions of the home page for customers with different values of ''my.attribute''.

Add a custom block and a phtml template with the content to the cms_index_index.xml layout. This step will create a block that will display the customer-specific content on the home page. You can use the phtml template to check the value of ''my.attribute'' and render the content accordingly.


: https://devdocs.magento.com/guides/v2.3/extension-dev-guide/cache/page-caching/public-content.html : https://devdocs.magento.com/guides/v2.3/howdoi/checkout/checkout_customize.html

Page:    1 / 14   
Total 50 questions