AEM Assets Fundamentals and Architecture
AEM Assets is built on the JCR repository (Oak) and served through Sling, so every asset is a node with a jcr:primaryType of dam:Asset. The critical structural fact: an asset node contains a jcr:content child, which contains a metadata node and a renditions node. The binary itself lives under jcr:content/renditions/original as a nt:file/nt:resource pair. Questions love to test whether you know that metadata and the original binary are siblings of each other, not nested.
Understand the Dynamic Media vs. standard Assets split. Standard Assets generates static renditions at ingestion time using workflows; Dynamic Media (Scene7) generates renditions on demand from a single master via URL modifiers. Also know Asset Microservices (the cloud-native processing pipeline) versus the on-premise Workflow-based processing - in AEM as a Cloud Service, asset processing is handled by microservices, not by the DAM Update Asset workflow model that on-prem uses.
Traps to watch: (1) confusing dam:Asset with dam:AssetContent; (2) assuming workflows run in Cloud Service the same way as on-prem; (3) thinking the original rendition can be regenerated - it cannot, it is the source of truth. A useful rule of thumb: if a question asks where a piece of data physically lives, trace the path asset → jcr:content → {metadata | renditions} before answering.