How the Project Was Created ⚙️

Using Adobe’s official Maven archetype:

mvn -B org.apache.maven.plugins:maven-archetype-plugin:3.3.1:generate \
 -D archetypeGroupId=com.adobe.aem \
 -D archetypeArtifactId=aem-project-archetype \
 -D archetypeVersion=56 \
 -D appTitle="My Site" \
 -D appId="mysite" \
 -D groupId="com.mysite"

Top-Level Project Structure 🏗️

myaemsite/                          ← Root project (Parent POM)
│
├── pom.xml                         ← Parent POM (controls all modules)
│
├── core/                           ← MODULE 1: Java Backend Code
├── ui.apps/                        ← MODULE 2: Components, Dialogs, HTL
├── ui.content/                     ← MODULE 3: Pages, Templates, Content
├── ui.frontend/                    ← MODULE 4: Frontend (CSS, JS, Webpack)
├── ui.apps.structure/              ← MODULE 5: Repository skeleton
├── ui.config/                      ← MODULE 6: OSGi Configurations
├── ui.tests/                       ← MODULE 7: UI Tests
├── it.tests/                       ← MODULE 8: Integration Tests
├── dispatcher/                     ← MODULE 9: Dispatcher Config
└── all/                            ← MODULE 10: Full Package

Module 1: core/ — Java Backend Code ☕

core/
├── pom.xml
└── src/main/java/com/myaemsite/core/
    ├── models/
    ├── servlets/
    ├── services/
    ├── filters/
    ├── listeners/
    └── schedulers/

Role: All Java backend logic.

📦 Compiles into an OSGi bundle (JAR)
📍 Deploys to: /apps/myaemsite/install/

👉 Think: Django backend or Spring Boot services.

Module 2: ui.apps/ — Components & HTL 🧩

ui.apps/src/main/content/jcr_root/apps/myaemsite/
├── components/
├── clientlibs/
└── i18n/

Contains:

• HTL templates

• Author dialogs

• Clientlibs

• Component configs

📍 Deploys to: /apps/myaemsite/

Golden Rule ✨

File system path  =  Repository path

jcr_root/apps/mysite/  →  /apps/mysite/

Module 3: ui.content/ — Pages & Templates 📄

ui.content/src/main/content/jcr_root/
├── content/myaemsite/
└── conf/myaemsite/

Contains:

• Website pages

• Editable templates

• Component policies

📍 Deploys to:

• /content/

• /conf/

Module 4: ui.frontend/ — Modern Frontend 🎨

ui.frontend/
├── package.json
├── webpack configs
└── src/main/webpack/

Uses:

• Webpack

• TypeScript

• SASS

👉 Output goes into ui.apps/clientlibs/

Module 5: ui.apps.structure/ 🏗️

Creates empty folder structure in AEM before other packages install.

Small module, but very important.

Module 6: ui.config/ — OSGi Configs ⚙️

config/
config.author/
config.publish/
config.dev/
config.stage/
config.prod/

Environment-specific configs.

💡 Remember Run Modes from previous chapter.

Testing Modules 🧪

Module 9: Dispatcher 🚀

Production caching & security.

Contains:

• Cache rules

• Filters

• URL rewrites

👉 Not required for local dev.

Module 10: all/ — The Final Package 📦

Combines everything into one deployable package.

myaemsite.all-1.0-SNAPSHOT.zip

This is what gets deployed to AEM.

How Everything Connects 🔗

Developer writes:

• Java → core/

• Components → ui.apps/

• CSS/JS → ui.frontend/

• Configs → ui.config/

• Content → ui.content/

Maven builds → all/ package → Deploy to AEM 🎉

Important Maven Commands 💻

Build & Deploy

Deploy Specific Modules

Frontend Commands 🎨

Run inside ui.frontend/

Useful AEM URLs 🔗

Daily Development Workflow 🧑‍💻

Java change?
→ mvn clean install -PautoInstallBundle -pl core

HTL change?
→ mvn clean install -PautoInstallPackage -pl ui.apps

Everything changed?
→ mvn clean install -PautoInstallSinglePackage

Add -DskipTests for faster builds ⚡

Interview Questions 🎤

Top Questions

What archetype creates AEM projects?
→ com.adobe.aem:aem-project-archetype

What is core module?
→ Java backend (Sling Models, Services, Servlets)

ui.apps vs ui.content?
→ ui.apps = code
→ ui.content = content

What is CRX Package?
→ ZIP file installed via Package Manager.

Things to Remember 🧠

core          → Java backend
ui.apps       → Components & HTL
ui.content    → Pages & Templates
ui.frontend   → CSS & JS
ui.config     → OSGi configs
all           → Everything combined
dispatcher    → Caching & security

Daily Commands

Full deploy:
mvn clean install -PautoInstallSinglePackage

Java only:
mvn clean install -PautoInstallBundle -pl core

Components only:
mvn clean install -PautoInstallPackage -pl ui.apps

What is Maven?

Before understanding the archetype, you need to know Maven.

Maven is a build tool for Java projects.
It does for Java what npm does for Node.js or pip does for Python.

The Heart of Maven → pom.xml

Every AEM project contains a pom.xml (Project Object Model).
This file defines:

• Project name & version

• Dependencies (libraries)

• Build plugins

• Deployment profiles

Think of pom.xml as the brain of the project.

What is an Archetype?

An archetype is a project template generator.

Instead of starting with an empty folder, it creates a ready-made project with best practices.

Every framework has one:

👉 All of them do the same thing: Generate a project structure.

What is AEM Maven Archetype?

The AEM Maven Archetype is Adobe’s official starter template for AEM projects.

The Command — Explained Word by Word

mvn -B org.apache.maven.plugins:maven-archetype-plugin:3.3.1:generate \
  -D archetypeGroupId=com.adobe.aem \
  -D archetypeArtifactId=aem-project-archetype \
  -D archetypeVersion=56 \
  -D appTitle="My Site" \
  -D appId="mysite" \
  -D groupId="com.mysite"

Breakdown

Required Parameters

Optional Parameters (with Defaults)

The Most Important Parameter → appId

This single value controls the entire project naming.

If you set:

appId = myaemsite

It automatically generates:

Repository Paths

/apps/myaemsite/
/content/myaemsite/
/conf/myaemsite/

Java Packages

com.myaemsite.core
com.myaemsite.core.models
com.myaemsite.core.servlets

Maven Packages

myaemsite.ui.apps
myaemsite.ui.content
myaemsite.all

Client Libraries

clientlib-myaemsite-base

👉 One value → controls EVERYTHING.

Before vs After Running the Archetype

Before

D:\AEM\Projects\
(empty)

After

myaemsite/
├── pom.xml
├── core/
├── ui.apps/
├── ui.content/
├── ui.frontend/
├── ui.config/
├── ui.apps.structure/
├── ui.tests/
├── it.tests/
├── dispatcher/
└── all/

10 modules generated in seconds.

What Happens Internally?

1. Maven downloads the archetype template from the internet

2. Reads your parameters (appId, groupId, etc.)

3. Replaces placeholders in template files

4. Generates project folders

5. Runs cleanup scripts

6. Project ready 🎉

Think of it as Mail Merge for code.

Generated Modules Explained

Build Commands After Generation

aemVersion — Cloud vs On-Prem

For local learning:

• AEM SDK → cloud

• AEM 6.5 JAR → 6.5.0

Archetype Version History

👉 Always use the latest version.

Real-World Analogy

Without archetype → build restaurant from scratch 🍽️
With archetype → buy franchise starter kit 🏪

Everything is ready — you just customize your brand.

Common Mistakes to Avoid

Summary

AEM Maven Archetype = Adobe’s official starter kit.

It generates a complete AEM project in seconds.

Command

mvn -B org.apache.maven.plugins:maven-archetype-plugin:3.3.1:generate \
  -D archetypeGroupId=com.adobe.aem \
  -D archetypeArtifactId=aem-project-archetype \
  -D archetypeVersion=56 \
  -D appTitle="My Site" \
  -D appId="mysite" \
  -D groupId="com.mysite"

First command after generation

mvn clean install -PautoInstallSinglePackage

Chapter 5 of AEM Learning Series — How AEM behaves differently across environments without changing code.

🎯 What Are Run Modes?

Run modes allow AEM to behave differently depending on where it is running.

The same codebase runs across:

• Author (content editing)

• Publish (live website)

• Dev (development)

• Stage (testing)

• Prod (production)

Each environment needs different configurations.

Run modes make this possible without changing code.

🧩 Two Categories of Run Modes

1️⃣ Instance Type (Set Once at Startup)

Cannot be changed at runtime.

2️⃣ Environment Run Modes (Custom)

Also set at startup via JVM parameter.

🔧 How to Set Run Modes

Method 1 — JAR Naming

aem-author-p4502.jar
aem-publish-p4503.jar

Method 2 — JVM Parameter

-Dsling.run.modes=author,dev

Method 3 — sling.properties

crx-quickstart/conf/sling.properties
sling.run.modes=author,dev

👉 Multiple run modes can be active together:

author + dev
publish + prod

📁 Run Modes & OSGi Configurations

Inside your project:

osgiconfig/
├── config/                 → All instances
├── config.author/          → Author only
├── config.publish/         → Publish only
├── config.dev/             → Dev only
├── config.stage/           → Stage only
├── config.prod/            → Prod only
├── config.author.dev/      → Author + Dev
└── config.publish.prod/    → Publish + Prod

Priority Rule (Must Remember)

config.publish.prod
      ↓
config.prod
      ↓
config.publish
      ↓
config

👉 More specific folder wins.

🌍 Real-World Examples

Logging

config.dev     → DEBUG
config.prod    → ERROR

Email Service

config.author          → disabled
config.publish.dev     → test SMTP
config.publish.prod    → real SMTP

Analytics Tracking

config.author          → OFF
config.publish.prod    → ON

🔍 How to Check Active Run Modes

Open:

/system/console/status-slingsettings

Example output:

Run Modes = [author, dev, crx3, crx3tar]

🚨 Critical Rules

Always use nosamplecontent in production
Use combined run mode configs for clarity
Check run modes when service works on Author but not Publish
Run modes cannot be changed without restart
Never use samplecontent in production

🧠 Quick Recap

• Run modes = environment-specific behavior

• Types:

  • author / publish (instance)

  • dev / stage / prod (environment)

• Set via:

  • JAR name

  • JVM parameter

  • sling.properties

• Cannot change at runtime

• More specific config folder wins

🎯 Interview Questions — Run Modes (15 Q&A)

Q1. What are run modes?
Environment-based configuration mechanism.

Q2. Types of run modes?
Installation (author/publish) + custom (dev/stage/prod).

Q3. How to set run modes?
JAR name, JVM parameter, sling.properties.

Q4. How do run modes affect configs?
AEM loads matching config folders.

Q5. Run mode priority?
config.publish.prod > config.prod > config.publish > config.

Q6. Change run modes at runtime?
No — restart required.

Q7. Where to check active run modes?
/system/console/status-slingsettings.

Q8. Run modes in AEM Cloud?
author, publish, dev, stage, prod, rde.

Q9. Real-world example?
Different SMTP per environment.

Q10. Multiple run modes active?
Yes.

Q11. Config conflict resolution?
Use combined run mode folder.

Q12. samplecontent run mode?
Installs demo content.

Q13. Why nosamplecontent?
Production best practice.

Q14. Config folder naming?
config.<runmode>.

Q15. Service works on Author not Publish?
Check run modes, replication, permissions, dispatcher.

🎉 Final Summary

Run Modes = environment awareness in AEM.

They allow the same code to behave differently in Dev, Stage, and Production — safely and cleanly.

Chapter 4 of AEM Learning Series — How AEM turns URLs into HTML pages.

⚡ What Sling Does (In One Line)

Apache Sling maps a URL → to a JCR node → then finds the script that renders it.

This is the core engine of request processing in AEM.

🆚 Sling vs Traditional Web Frameworks

Traditional MVC (Django / Express)

URL → Route → Controller → Fetch Data → Template → HTML
Code decides what to render

Apache Sling (AEM)

URL → JCR Node → sling:resourceType → Script → HTML
Content decides what to render

👉 This is called Content-Driven Rendering.

🧩 URL Anatomy in Sling (Must Memorize)

http://localhost:4502/content/mysite/en/home.selector1.selector2.html/suffix?key=value
                     ──────────────────────  ─────────  ─────────  ────  ──────  ─────────
                          RESOURCE PATH       SELECTOR   SELECTOR   EXT   SUFFIX  QUERY

🔄 Sling Request Processing Flow (Must Know)

User requests:

http://localhost:4502/content/mysite/en/home.html

Step-by-step

1️⃣ URL Decomposition

/content/mysite/en/home + .html

2️⃣ Find JCR Node

Sling looks up resource in repository.

3️⃣ Read sling:resourceType

mysite/components/page

4️⃣ Find Rendering Script

/apps/mysite/components/page/page.html

5️⃣ Execute Script

HTL renders HTML.

6️⃣ Return Response

Browser receives page.

🎯 What Are Selectors?

Selectors allow multiple representations of same content.

Same content → different output.

🔎 Sling Script Resolution Order

Example:

resourceType = mysite/components/page
selector = mobile
extension = html

Sling searches in this order:

1. /apps/.../mobile.html
2. /apps/.../page.mobile.html
3. /apps/.../page.html
4. /libs/.../page.html
5. sling:resourceSuperType chain
6. Default servlet

📁 /apps vs /libs (Overlay Mechanism)

When Sling searches for a component:

1️⃣ /apps/mysite/components/page   ← YOUR CODE
2️⃣ /libs/mysite/components/page   ← AEM CORE

👉 /apps overrides /libs.

Never edit /libs.

🧠 Key Sling Concepts

🧑‍💻 Sling Servlets (Two Types)

✅ Resource-Bound Servlet (Recommended)

• Based on resourceType

• Respects permissions

• Follows Sling architecture

❌ Path-Bound Servlet (Avoid)

• Hardcoded path /bin/xyz

• Bypasses permissions

• Security risk

🚨 Critical Rules

Always close ResourceResolver
Always use /apps (not /libs)
Prefer resource-bound servlets
Never leave sessions open

Unclosed ResourceResolver → AEM crash.

🧠 Quick Recap

Sling = URL → JCR Node → resourceType → Script → HTML
Content-driven rendering
Selectors change output
/apps overlays /libs
Always close ResourceResolver

🎯 Interview Questions — Apache Sling (25 Q&A)

🟢 Basics

Q1. What is Apache Sling?
Content-centric web framework mapping URLs to JCR resources.

Q2. Sling request flow?
URL → Resolve resource → resourceType → script → response.

Q3. sling:resourceType?
Component responsible for rendering content.

Q4. URL anatomy?
/path.selector.extension/suffix?params

Q5. Selector?
Changes rendering script.

Q6. Sling Resource?
Abstraction of content node.

Q7. ResourceResolver?
API to access resources.

🔵 Intermediate

Q8. Script resolution?
resourceType → selectors → extension → /apps → /libs.

Q9. Sling vs MVC?
Content-driven vs route-driven.

Q10. Overlay mechanism?
/apps overrides /libs.

Q11. sling:resourceSuperType?
Component inheritance.

Q12. resourceType vs superType?
Direct mapping vs fallback.

Q13. Sling Servlet?
Java request handler.

Q14. Path vs resource servlet?
Resource-bound preferred.

Q15. Resource not found?
sling:nonexisting → 404.

Q16. SlingHttpServletRequest?
Extended request object.

Q17. Resource adaptation?
resource.adaptTo() → Sling Model.

🔴 Advanced

Q18. Script resolution order?
Selector → component → /apps → /libs → superType.

Q19. SlingMainServlet?
Entry point for requests.

Q20. request vs resolver resource?
Current vs any path.

Q21. Sling mappings?
URL rewriting via /etc/map.

Q22. Sling Exporter?
Sling Models → JSON.

Q23. POST handling?
SlingDefaultPostServlet.

Q24. Safe vs AllMethodsServlet?
Read vs read/write.

Q25. Why close ResourceResolver?
Prevent session leaks.

🎉 Final Summary

If JCR stores content and OSGi runs AEM…
👉 Sling is what actually serves pages.

Chapter 3 of AEM Learning Series — Understanding how AEM stores EVERYTHING.

📚 What is JCR?

JCR = Java Content Repository

JCR is a Java specification (JSR-170 & JSR-283) that defines how content should be stored and accessed.

JCR Specification      → Rulebook
Apache Jackrabbit Oak  → Implementation
AEM                    → Uses Oak to store all content

AEM does NOT use MySQL/Postgres like traditional apps.

It uses a hierarchical content repository.

🌲 AEM Does NOT Use Tables — It Uses a Tree

Traditional DB vs JCR

RELATIONAL DATABASE:
Table: employees
id | name  | age
1  | Shubh | 24
2  | Rahul | 28

JCR REPOSITORY:
/
└── content/
    └── mysite/
        └── en/
            └── home (NODE)
                ├── jcr:title = "Home Page" (PROPERTY)
                └── jcr:content (CHILD NODE)

👉 Think of JCR like a file system with superpowers.

🧩 Two Building Blocks of JCR

1️⃣ Node

A Node = Container (folder-like)

• Has name + type (jcr:primaryType)

• Can contain child nodes

• Can contain properties

• Has a unique path

Example path:

/content/mysite/en/home

2️⃣ Property

A Property = Key–Value pair

Supported data types:

🏠 Complete AEM Page Node Structure

/content/mysite/en/about (cq:Page)
└── jcr:content (cq:PageContent)
    ├── jcr:title = "About Us"
    ├── sling:resourceType = "mysite/components/page"
    ├── cq:template = "/conf/.../template"
    └── root/container
        ├── text component
        └── image component

👉 Pages are just nodes in the repository.

🧠 Important Node Types

🏷️ Namespaces in JCR

Fun fact: AEM was originally Day CQ5 → hence cq:.

⭐ Most Important Properties (Memorize!)

👉 Most important property: sling:resourceType

This tells AEM which component renders content.

💾 Storage Backend (Oak)

AEM uses Apache Jackrabbit Oak.

TarMK  → Default, file-based, fast
MongoMK → Clustered Author, MongoDB-backed

Node Store vs Data Store

Locations:

crx-quickstart/repository/segmentstore/
crx-quickstart/repository/datastore/

🔍 Querying JCR

1️⃣ QueryBuilder (Most Used)

path=/content/mysite
type=cq:Page
property=jcr:content/jcr:title
property.value=About Us

Test here:

/libs/cq/search/content/querydebug.html

2️⃣ JCR-SQL2

SELECT * FROM [cq:Page]
WHERE ISDESCENDANTNODE('/content/mysite')

3️⃣ XPath (Legacy)

/jcr:root/content/mysite//element(*, cq:Page)

📂 Important Repository Paths

🚨 Never modify /libs/

🧠 Things to Remember

• JCR = specification, Oak = implementation

• Everything = Nodes + Properties

• sling:resourceType = rendering component

• TarMK = default storage

• QueryBuilder = most common query method

• /apps/ overlays /libs/

• resolver.commit() persists changes

🎯 AEM Interview Questions — JCR (35 Q&A)

🟢 Basics

Q1. What is JCR?
Java Content Repository specification.

Q2. JCR vs Oak?
Spec vs implementation.

Q3. JCR building blocks?
Nodes and Properties.

Q4. JCR vs relational DB?
Tree vs tables.

Q5. JCR vs file system?
Rich metadata + querying.

Q6. Property types?
STRING, DATE, BINARY, PATH, etc.

Q7. Multi-value properties?
Yes (cq:tags).

Q8. Root node?
/

Q9. Node path example?
/content/mysite/en/home

Q10. JCR browser?
CRX DE Lite.

🔵 Node Types

Q11. jcr:primaryType?
Defines node type.

Q12. cq:Page vs cq:PageContent?
Page vs page content.

Q13. nt:unstructured?
Flexible node.

Q14. nt:folder vs sling:Folder?
Basic vs Sling-aware.

Q15. Namespaces?
Prefixes preventing conflicts.

Q16. Why cq: prefix?
Legacy Day CQ.

Q17. jcr:mixinTypes?
Extra node capabilities.

🟣 Structure

Q18. sling:resourceType?
Component renderer.

Q19. sling:resourceSuperType?
Component inheritance.

Q20. jcr:content?
Page content node.

Q21. Page structure?
cq:Page → jcr:content → components.

Q22. Key paths?
/content, /apps, /libs, /conf.

🟠 Storage

Q23. TarMK?
Default storage.

Q24. MongoMK?
Clustered storage.

Q25. Node vs Data Store?
Structure vs binaries.

Q26. Physical storage?
segmentstore + datastore folders.

🔴 Queries

Q27. Query methods?
QueryBuilder, SQL2, XPath.

Q28. QueryBuilder test URL?
querydebug.html.

Q29. SQL2 query example?
Find pages under path.

Q30. Query performance risk?
Traversal without indexes.

⚫ Advanced

Q31. JCR Observation?
Event listeners.

Q32. Versioning?
mix:versionable nodes.

Q33. JCR Session?
Repository connection.

Q34. session.save() vs resolver.commit()?
JCR vs Sling API.

Q35. Modify /libs/?
Never — use overlays.

🎉 Final Summary

Understanding JCR = Understanding how AEM stores content.

AEM is basically:

• Sling → renders

• OSGi → runs

• JCR → stores

Chapter 2 of AEM Learning Series — Understanding the engine that runs AEM.

🚀 What is OSGi?

OSGi = The engine that runs AEM

AEM is not a single huge Java application.
It is made of hundreds of small modules called Bundles.

OSGi is the framework that:

• Loads bundles

• Starts bundles

• Stops bundles

• Connects bundles together

AEM uses the Apache Felix implementation of OSGi.

📱 Smartphone Analogy

Phone OS        → OSGi
Mobile Apps     → Bundles

• Install/uninstall apps without restart
• Apps talk to each other
• OS manages lifecycle

🤯 Why AEM Uses OSGi

Without OSGi (Traditional Java App)

ONE BIG APPLICATION
Change one thing → Redeploy everything
Restart → 15+ min downtime 😬

With OSGi (AEM)

Bundle A (Assets)
Bundle B (Workflow)
Bundle C (Search)
Bundle D (Auth)
Bundle E (Editor)
Your Custom Bundle

👉 Update one bundle → No restart required

This is called Hot Deployment 🔥

🧩 Key OSGi Concepts

1️⃣ Bundle (The Deployment Unit)

A Bundle = JAR file + OSGi metadata

Each bundle contains:

META-INF/MANIFEST.MF

This file tells OSGi:

• Bundle name

• Version

• Exported packages

• Imported packages

• Dependencies

👉 Smallest deployable unit in AEM.

2️⃣ Bundle Lifecycle

INSTALLED → RESOLVED → STARTING → ACTIVE
                                     │
                                     ▼
                                  STOPPING → UNINSTALLED

💡 Most common AEM issue:
Bundle stuck in INSTALLED → Missing dependencies.

3️⃣ OSGi Services (Plug & Socket Model)

Service = Interface + Implementation

Interface  → Socket
Implementation → Plug

Any bundle can request a service, and OSGi injects it automatically.

Example Code

// Interface
public interface GreetingService {
    String getGreeting(String name);
}

// Implementation
@Component(service = GreetingService.class)
public class GreetingServiceImpl implements GreetingService {
    public String getGreeting(String name) {
        return "Hello " + name;
    }
}

// Injecting in Sling Model
@Model(adaptables = Resource.class)
public class HeaderModel {
    @OSGiService
    private GreetingService greetingService;
}

4️⃣ OSGi Configurations (No Hardcoding!)

Instead of hardcoding values:

smtp.gmail.com

Use configuration:

mail.smtp.host = smtp.gmail.com
mail.smtp.port = 587

Different environments can have different configs:

👉 No code changes required.

🔎 Where to See OSGi in AEM

This is called the Felix Web Console.

🧠 OSGi in AEM Architecture

AEM
 └── OSGi (Felix)
      ├── Sling Bundles
      ├── Oak Bundles
      ├── Workflow Bundles
      └── Your Custom Bundles

All communicate via OSGi Service Registry.

📝 Things to Remember

• OSGi = modular runtime used by AEM

• Bundle = deployable JAR

• Service = interface + implementation

• Hot deployment = no restart required

• Felix Console = /system/console

• Bundle not ACTIVE? → Dependency issue

🎯 AEM Interview Questions — OSGi (30 Q&A)

🟢 Section A — Basics

Q1. What is OSGi?
Modular Java framework used by AEM.

Q2. OSGi implementation in AEM?
Apache Felix.

Q3. Why OSGi?
Modularity • Hot deployment • Dependency management.

Q4. What is a Bundle?
JAR with OSGi metadata.

Q5. What is MANIFEST.MF?
Bundle metadata file.

Q6. Felix Web Console?
Admin UI at /system/console.

Q7. Default credentials?
admin/admin (dev only).

Q8. Bundles console URL?
/system/console/bundles

Q9. Configurations console URL?
/system/console/configMgr

Q10. Components console URL?
/system/console/components

🔵 Section B — Lifecycle

Q11. Bundle states?
Installed → Resolved → Active → Stopping → Uninstalled.

Q12. Bundle stuck in INSTALLED?
Missing dependencies.

Q13. Debug steps?
Check bundle → imported packages → install dependency.

Q14. ACTIVE → RESOLVED?
Yes, when stopped or dependency removed.

Q15. Fragment bundle?
Extends another bundle.

🟣 Section C — Services

Q16. OSGi Service?
Java object registered in Service Registry.

Q17. Component vs Service?
Service = component exposed via interface.

Q18. Register service annotation?
@Component(service=MyInterface.class)

Q19. @Reference?
Inject service in OSGi component.

Q20. @Reference vs @OSGiService?
Component vs Sling Model injection.

Q21. Service Registry?
Runtime service lookup system.

Q22. service.ranking?
Priority for multiple implementations.

🟠 Section D — Configuration

Q23. OSGi Config?
Externalized properties.

Q24. Create configs?
Console or repository config files.

Q25. Run-mode configs?
config.author, config.publish.

Q26. Factory config?
Multiple instances of same component.

Q27. PID?
Unique config identifier.

🔴 Section E — Scenarios

Q28. Sling Model not working?
Check bundle, components, Sling Models console.

Q29. DS vs SCR?
DS = modern, SCR = deprecated.

Q30. Two bundles exporting same package?
Yes — version resolution.

🎉 Final Summary

Understanding OSGi = Understanding how AEM actually runs.

Everything you build in AEM becomes an OSGi bundle.

Chapter 1 of AEM Learning Series — Understanding the core architecture used in every production AEM setup.

🌍 The Big Picture

Every production AEM setup runs on a 3-tier architecture.

These 3 layers work together to deliver fast, secure, and scalable websites.

✍️ 1. AUTHOR Instance

What happens on Author?

• Drag & drop page building

• Upload images/videos to DAM

• Preview content before publishing

• Run workflows (review → approve → publish)

• Developers deploy code here first

Think of Author as the content factory 🏭

🌐 2. PUBLISH Instance

What happens on Publish?

• Serves final HTML pages

• Contains only activated content

• No editing interface

• Multiple instances used for scaling

Publishing Flow

⚡ 3. DISPATCHER (Most Important Layer)

How Dispatcher Works

User requests a page
        │
        ▼
Dispatcher checks cache
   ┌────┴────┐
   YES       NO
   │         │
   │         ▼
   │     Ask Publish
   │     Render HTML
   │     Cache result
   ▼
Return page fast 🚀

Dispatcher’s 3 Superpowers

1️⃣ Caching → Stores rendered HTML
2️⃣ Security → Blocks malicious URLs
3️⃣ Load Balancing → Distributes traffic

👉 Dispatcher is NOT part of AEM — it runs on Apache/IIS.

🔄 Real-World Flow Example

Imagine Coca-Cola launches a Summer Sale Page:

1. Author creates page on Author

2. Clicks Publish

3. Content replicates to Publish

4. User visits website

5. Dispatcher checks cache

6. First user → page generated & cached

7. Next 10,000 users → cached version ⚡

This is how AEM handles massive traffic.

🏭 Production Setup (Enterprise Scale)

                         ┌──────────┐
                         │  AUTHOR  │
                         └────┬─────┘
                              │ Replication
           ┌──────────┬──────────┬──────────┐
           ▼          ▼          ▼
      PUBLISH1   PUBLISH2   PUBLISH3
           │          │          │
      DISPATCHER1 DISPATCHER2 DISPATCHER3
                └──────┬──────┘
                       ▼
                 LOAD BALANCER
                       ▼
                    Users

Large enterprises run multiple publish + dispatcher nodes for high availability.

🧾 Key Things to Remember

• Author → Content creation (private)

• Publish → Live website (public)

• Dispatcher → Cache + Security layer

• Content flows Author → Publish

• Users NEVER access Author directly

🎯 AEM Interview Questions (30 Q&A)

🟢 Section A — Basics

Q1. What is AEM?
AEM is an enterprise CMS used to create, manage and deliver digital experiences.

Q2. AEM technology stack?
OSGi • JCR • Sling • HTL • Java

Q3. Three tiers of AEM?
Author • Publish • Dispatcher

Q4. Author instance?
Content creation environment (port 4502).

Q5. Publish instance?
Live website server (port 4503).

Q6. Dispatcher?
Apache module for caching, security, load balancing.

Q7. Default ports?
Author → 4502 | Publish → 4503

Q8. Author users?
Authors, marketers, developers.

Q9. Publish users?
Website visitors.

Q10. AEM language?
Java.

🔵 Section B — Replication

Q11. Replication?
Author → Publish content transfer.

Q12. Activation vs Deactivation?
Publish vs Unpublish.

Q13. Reverse replication?
Publish → Author data flow.

Q14. Replication agent?
Configuration controlling replication.

Q15. Publish → Author publishing?
Not directly (only reverse replication).

🟣 Section C — Dispatcher

Q16. Dispatcher functions?
Caching • Security • Load balancing.

Q17. Where installed?
Apache HTTP / IIS server.

Q18. Cache miss?
Request sent to Publish → cached.

Q19. Cache invalidation?
Flush agent clears cache.

Q20. Personalized content caching?
No — use AJAX/client-side.

🟠 Section D — Production

Q21. Author instances in prod?
Usually 1 (or primary + standby).

Q22. Publish instances?
3–10+ depending on traffic.

Q23. In front of Dispatcher?
Load balancer or CDN.

Q24. Hosting types?
On-Prem • AMS • Cloud Service.

Q25. Full request flow?
Browser → LB → Dispatcher → Publish → Response.

🔴 Section E — Scenarios

Q26. Users see old content?
Check dispatcher/CDN cache or replication.

Q27. Author down — website works?
Yes.

Q28. Publish down — website works?
Cached pages still load.

Q29. Wrong content published?
Republish or deactivate.

Q30. Why Author behind VPN?
Security & protection.

🎉 Summary

If you understand this architecture, you understand the foundation of AEM.

Everything else in AEM builds on this.

A structured path from beginner → industry-ready Adobe Experience Manager Engineer

🌍 What is AEM?

🤔 Why AEM instead of Django / React / Node?

🍽️ The Restaurant Analogy

• Django/React → Hire a chef. Every new dish requires coding.

• AEM → Build a full kitchen. Non-chefs (marketers) can cook using templates.

Developers create the recipes (components/templates).
Authors create the content (pages/assets).

✅ Advantages of AEM

• Drag-and-drop visual authoring

• Enterprise permissions & workflows

• Adobe ecosystem integrations

• Multi-site & multi-language ready

• Built-in Digital Asset Manager

• Content reusability (Fragments)

• Headless + traditional CMS

• Cloud-native option

❌ Disadvantages of AEM

• Extremely expensive 💸

• Steep learning curve

• Heavy & complex

• Java ecosystem dependency

• Vendor lock-in

• Slower development cycle

🎯 When Should You Use AEM?

🗺️ The Complete AEM Roadmap (62 Topics)

Phase 1 — AEM Foundation & Architecture

🎯 Goal: Understand the AEM ecosystem

1. AEM Architecture

   • Author vs Publish instances

   • Dispatcher & replication

   • Production topology

2. OSGi Framework

   • Apache Felix runtime

   • Bundles & lifecycle

   • Service registry

   • Hot deployment

3. JCR Repository

   • Apache Jackrabbit Oak

   • Nodes & properties

   • TarMK vs MongoMK

4. Apache Sling

   • Request processing

   • Script resolution

   • Resource resolution

   • URL anatomy

5. AEM Run Modes

   • author / publish

   • dev / stage / prod

   • Run-mode configurations

Phase 2 — Repository & Node Structure

🎯 Goal: Learn AEM filesystem & CRX

6. CRX DE Lite navigation

7. Repository structure:

   • /content

   • /apps

   • /conf

   • /libs

   • /var

   • /home

   • /oak:index

8. Node types & properties

9. /apps vs /libs overlay concept

Phase 3 — AEM Project Setup (First Hands-On)

🎯 Goal: Create & deploy your first AEM project

10. AEM Maven Archetype

11. Project modules:

• core

• ui.apps

• ui.content

• ui.frontend

• all

12. Build & deploy using Maven

13. Package Manager usage

Phase 4 — Component Development (Core AEM Skill)

🎯 Goal: Become an AEM Component Developer

14. Component structure

15. HTL (Sightly templating)

• data-sly-use

• data-sly-list

• data-sly-test

• data-sly-resource

16. Touch UI dialogs (Granite UI)

17. Sling Models

18. Core Components & proxy pattern

19. Component inheritance

Phase 5 — Templates & Pages

🎯 Goal: How pages are built in AEM

20. Editable templates

21. Page component

22. Template structure

23. Responsive grid & layout container

Phase 6 — Client Libraries (Frontend in AEM)

🎯 Goal: Manage CSS/JS in AEM

24. Client Libraries (clientlibs)

25. Categories, dependencies & embedding

26. ui.frontend + Webpack pipeline

Phase 7 — Authoring Features

🎯 Goal: Features used by content authors

27. Page creation & publishing

28. Content Fragments (Headless CMS)

29. Experience Fragments

30. Digital Asset Management (DAM)

31. Tags & taxonomy

Phase 8 — OSGi Backend Development

🎯 Goal: Become AEM backend developer

32. OSGi services

33. OSGi configurations

34. Sling servlets

35. Schedulers & jobs

36. Event handlers & listeners

37. Sling filters

Phase 9 — Sling Deep Dive

38. ResourceResolver & Service users

39. Sling mappings & vanity URLs

40. Selectors & extensions

41. Sling exporter (.model.json)

Phase 10 — Workflows & Replication

42. Workflows & custom steps

43. Replication & activation

44. Replication agents

Phase 11 — Dispatcher (🔥 Most Important for Interviews)

45. Dispatcher caching basics

46. Dispatcher rules & filters

47. Cache invalidation & flush

Phase 12 — Users & Permissions

48. Users & groups

49. ACL permissions

50. Closed User Groups (CUG)

Phase 13 — APIs & Integrations

51. Sling vs JCR vs WCM APIs

52. Content Services APIs

53. GraphQL API (Headless AEM)

54. Adobe integrations (Analytics, Target, Campaign)

Phase 14 — AEM as a Cloud Service

55. Cloud vs AMS vs On-Premise

56. Cloud Manager CI/CD

57. Rapid Development Environment (RDE)

58. Cloud best practices

Phase 15 — Testing, Performance & Security

59. Unit testing (AEM Mocks)

60. Code quality & BPA

61. Performance & Oak indexes

62. Security (XSS, CSRF, CORS)

🎉 Final Outcome

After completing this roadmap you will be able to:

✅ Build enterprise AEM projects
✅ Develop components & templates
✅ Work with Dispatcher & Cloud Manager
✅ Build headless AEM APIs
✅ Become industry-ready AEM Engineer