AEM Assets Developer Professional common mistakes
AEM Assets Developer Professional · Understand the traps and how to avoid them.
Treating the asset binary store (data store / file data store) and the node store (JCR) as a single system when reasoning about storage, backups, and garbage collection.
Candidates learn 'assets live in /content/dam' from the UI and assume the binary is stored in the repository tree, so they mis-answer questions about where renditions or originals physically reside and how consistency is maintained.
What to do instead
Internalize the two-store model: the JCR holds asset nodes and metadata; binaries go to the configured data store (segment/tar or file), referenced by the node. Learn that consistency between stores is maintained by the asset ingestion/GC workflows and that orphaned binaries are cleaned by data store garbage collection, not by deleting nodes alone.
Confusing the asset processing workflow (DAM Update Asset) with the ingestion workflow and expecting metadata extraction to happen in the wrong model.
The default DAM Update Asset model is a long chain of steps, and candidates memorize the name without understanding which steps run where (metadata extraction, rendition generation, sub-asset creation, and post-processing).
What to do instead
Map the pipeline: ingestion (upload/import) triggers the DAM Update Asset workflow, whose steps include metadata extraction (XMP/EXIF), thumbnail/web renditions, and sub-asset extraction; understand that processing profiles can override default renditions per folder and that the workflow can be customized with process steps.
Assuming a single metadata schema applies globally and writing answers that ignore per-folder metadata schemas and their precedence.
The default metadata schema is what candidates see first, so they forget that folder-level schemas can be applied and that the effective form depends on the asset's folder location.
What to do instead
Learn that metadata schemas are applied to folders (and thus to their assets), that the default schema applies when none is set, and that the editor form is driven by the resolved schema for that asset. Be able to explain how to make a custom field appear for a specific folder's assets.
Mixing up XMP metadata embedded in the binary with metadata stored as JCR properties, and expecting edits in the UI to rewrite the original file.
The metadata editor looks like it edits the file, but AEM writes most edits to JCR properties on the asset node; XMP extraction reads embedded metadata into the repository.
What to do instead
Distinguish extraction (read XMP/EXIF from the binary into JCR properties) from editing (writes JCR properties, optionally synced back via XMP writeback when configured). Know that namespaces and property mapping are configured, and that the original binary is not necessarily modified on every metadata edit.
Answering search questions as if only full-text indexing exists, ignoring metadata predicates and the query builder property/range predicates used for asset search.
Candidates interact with the OmniSearch UI and assume search is a black box, so they cannot reason about filtering by metadata fields, dates, or MIME type.
What to do instead
Learn the query builder predicates (type, path, property, daterange, fulltext) and how asset search combines full-text with metadata filters. Understand that custom metadata fields must be indexed to be searchable and that saved searches/smart collections are built from these queries.
Treating collections as folders and assuming moving an asset between folders changes its collection membership or that deleting a collection deletes the assets.
Collections look like folders in the UI, but they are separate node structures that reference assets, not contain them.
What to do instead
Explain that collections hold references to assets (assets remain in their folder path), that an asset can belong to many collections, and that deleting a collection removes the references, not the assets. Distinguish static collections from smart collections (query-driven).
Forgetting that renditions and delivery URLs depend on processing profiles and the Dynamic Media/Scene7 configuration, and answering delivery questions assuming originals are served.
The UI shows thumbnails, so candidates assume the same image is delivered; they overlook that web renditions, smart crops, and dynamic renditions are generated or served on demand.
What to do instead
Learn the difference between static renditions generated at ingestion (processing profile) and dynamic delivery (Dynamic Media image serving with URL modifiers). Know that delivery URLs may point to the Dynamic Media/CDN host, not the AEM publish instance, and that publish replication is required for assets to be available.
Assuming assets are immediately available on publish after upload without considering replication and the author/publish topology.
Candidates test on author and forget that delivery requires activation (replication) and that binaries must be replicated to the publish data store.
What to do instead
Describe the activation flow: assets are replicated from author to publish (including binaries), delivery reads from publish/CDN, and deactivation removes them. Understand that workflows run on author and that publish serves the processed renditions.
Believing the default DAM Update Asset workflow runs on every asset regardless of configuration, and being unable to explain how to skip or customize processing.
Candidates learn the default behavior but not the launcher/processing-profile controls, so they cannot answer questions about excluding assets or applying different renditions per folder.
What to do instead
Learn workflow launchers (which trigger DAM Update Asset based on path/type), processing profiles applied to folders to control renditions, and how to customize the workflow model. Be able to state how to prevent processing for a given folder or asset type.
Confusing the roles of the asset microservices/processing (e.g., metadata extraction, rendition generation) with the AEM application tier and assuming all processing happens in the author JVM.
Older documentation and UI behavior suggest in-process processing, but modern AEM can offload asset processing to microservices, changing where renditions are generated.
What to do instead
Understand that asset processing can be delegated to Asset Compute/microservices (configured via processing profiles), while the author instance orchestrates and stores results. Know that custom processing can be implemented as Asset Compute workers and that the default in-process workflow remains an option.