AEM Sites Fundamentals and Architecture
AEM Sites is built on a Java content repository (JCR) exposed through Apache Sling and rendered by HTL/Sightly. Every piece of content is a node addressed by path, with a jcr:primaryType such as cq:Page or nt:unstructured. A page node contains a jcr:content child that holds properties and a root paragraph system. Understanding this tree is the foundation for nearly every question on the exam.
Key architectural layers to know: the repository (Oak, with segment or document storage), Sling (resource resolution, scripting, and the resource-to-servlet mapping), OSGi (the component and service runtime where bundles register services), and Granite/Adobe Experience Manager UI (the authoring shell and its client libraries). Dispatcher sits in front of publish, caching and filtering requests. Author, publish, and dispatcher form the standard topology; content flows author → publish via replication agents.
Common traps: confusing templates (which define structure) with components (which render content); assuming author edits appear on publish without replication; and mixing up Sling resolution (URL → resource → script) with dispatcher caching (URL → cached response). Another frequent trap is treating /content (mutable content) and /apps (code) as interchangeable - they are not, and /libs should never be edited directly.
Rule of thumb: if a question asks where something lives, think in paths (/content/<site>, /conf/<site>, /apps, /libs, /etc). If it asks how a page renders, trace Sling: resource type → component → HTL script. Editable templates store their structure under /conf, not /apps, which is a favorite distractor.