AD0-E117 practice question 6 of 15

A client was successfully moved from AEM 6.5 to AEM as a Cloud Service (AEMaaCS) environment. The Content Transfer Tool was used to transfer the…

Full set: 87 questions
A client was successfully moved from AEM 6.5 to AEM as a Cloud Service (AEMaaCS) environment. The Content Transfer Tool was used to transfer the content to the AEMaaCS environment. The developed components render different renditions based on the breakpoint of the pages. The users reported that newly uploaded assets are not rendering or missing. What is the cause of this issue and how can it be resolved?
Answer options
A: The Asset Update workflow is not compatible with AEMaaCS. The solution is to rewrite the workflow to use the new APIs in the AEM SDK.
B: The Asset Update workflow was not migrated properly to the new AEMaaCS instance. The solution is to migrate the /var path and the workflow models using the Content Transfer Tool.
C: The Asset Update workflow was not migrated properly to the new AEMaaCS instance. The solution is to make sure that the workflow is present in the codebase.
D: The Asset Update workflow is not compatible with AEMaaCS. The solution is to use AEM Processing profiles to create the missing renditions. Correct answer
Correct Answer:
D. The Asset Update workflow is not compatible with AEMaaCS. The solution is to use AEM Processing profiles to create the missing renditions.
Explanation

In AEM as a Cloud Service (AEMaaCS), the traditional DAM Update Asset workflow used in AEM 6.x is replaced by a scalable, cloud-native asset processing service. This service is configured using "Processing Profiles" which define the renditions to be generated for uploaded assets. Since the old workflow is not used, any custom renditions required by components must be configured in a Processing Profile and applied to the relevant asset folders. The issue of missing renditions for newly uploaded assets points directly to this architectural change.

Why Incorrect

A. While the workflow is incompatible, rewriting it is not the solution. The correct approach is to use the new cloud-native processing mechanism, not to adapt the old one.
B. Migrating the /var path is not a standard or recommended procedure for this issue, and the problem is not a migration failure but a fundamental platform change.
C. The issue is not that the old workflow is missing from the codebase, but that AEMaaCS intentionally does not use it for asset rendition generation.

References

1. Adobe Experience Manager as a Cloud Service Documentation. (n.d.). Process assets using asset microservices and processing profiles. Adobe Experience League. Retrieved from https://experienceleague.adobe.com/docs/experience-manager-cloud-service/assets/asset-microservices-overview.html (See the "Overview" and "How to apply processing profiles to folders" sections).

2. Adobe Experience Manager as a Cloud Service Documentation. (n.d.). Migrating to AEM as a Cloud Service. Adobe Experience League. Retrieved from https://experienceleague.adobe.com/docs/experience-manager-cloud-service/moving/home.html (This documentation outlines the architectural differences, including the shift from workflows to asset microservices for processing).

Scroll to Top