Preparing for Adobe Experience Manager (AEM) interviews requires comprehensive knowledge spanning architecture, development practices, and real-world implementation strategies. AEM interview questions range from fundamental concepts to complex architectural decisions, reflecting the platform’s sophisticated capabilities and enterprise-scale deployments.

Understanding AEM interview questions and formulating strong responses demonstrates not just theoretical knowledge but practical expertise in building robust content management solutions. This guide explores the most critical AEM interview questions across all experience levels, from entry-level developers to senior architects, providing detailed answers and contextual insights that showcase deep platform understanding.

Whether you’re pursuing your first AEM developer role or advancing to architectural positions, mastering these AEM interview questions prepares you for technical discussions, problem-solving scenarios, and demonstrating the expertise organizations seek in Adobe Experience Manager professionals.

Fundamental AEM Interview Questions

These foundational AEM interview questions assess basic understanding of the platform’s core concepts and architecture.

What is Adobe Experience Manager (AEM)?

Adobe Experience Manager (AEM) is a comprehensive content management solution for building websites, mobile applications, and forms. AEM is part of Adobe Experience Cloud and provides tools for managing digital experiences across multiple channels. The platform combines web content management (WCM), digital asset management (DAM), and forms management into a unified solution.

AEM is built on Apache Sling, Apache Felix OSGi container, and Apache Jackrabbit Oak (JCR repository). This architecture provides flexibility, scalability, and modularity essential for enterprise content management. Organizations use AEM to create, manage, and deliver personalized digital experiences at scale, integrating with other Adobe products like Analytics, Target, and Campaign for comprehensive marketing capabilities.

What are the key components of AEM architecture?

AEM architecture consists of several fundamental layers working together:

JCR Repository (Apache Jackrabbit Oak): The content repository stores all content, assets, user data, and configuration. Oak provides the JCR (Java Content Repository) implementation with features like indexing, versioning, and access control. The repository uses a tree structure where nodes contain properties and child nodes.

Apache Sling: A web framework that maps HTTP requests to content resources in the JCR repository. Sling uses RESTful principles, treating URLs as resource paths. It handles request processing, script resolution, and resource adaptation, providing the foundation for AEM’s web layer.

OSGi Container (Apache Felix): Provides modularity through bundles—JAR files containing Java classes, resources, and metadata. OSGi enables dynamic module management, allowing bundles to be installed, updated, or removed without restarting the entire application. This architecture supports loose coupling and high cohesion.

Granite Platform: Adobe’s core platform providing foundational services including authentication, authorization, workflow engine, replication framework, and other infrastructure services. Granite wraps Apache technologies with Adobe-specific enhancements.

Touch UI and Classic UI: User interfaces for content authoring, asset management, and administration. Touch UI represents the modern, responsive interface optimized for tablets and touch devices, while Classic UI provided the traditional desktop interface (now deprecated).

What is the difference between AEM Author and Publish instances?

AEM deployments typically use separate Author and Publish instances serving distinct purposes:

Author Instance: The content creation and management environment where content authors, editors, and administrators work. Authors create pages, upload assets, configure components, and manage workflows. The Author instance includes the complete AEM interface with editing capabilities, workflow tools, and administrative consoles. This instance is typically secured behind firewalls, accessible only to internal users.

Publish Instance: The production environment serving content to end users. Publish instances contain activated (published) content that has been approved and replicated from Author. These instances are optimized for performance and scalability, typically running in load-balanced configurations. Publish instances have minimal administrative interfaces and focus solely on content delivery.

Key Differences:

• Purpose: Author for creation/management, Publish for delivery
• Access: Author restricted to internal users, Publish accessible to public
• Performance: Author optimized for functionality, Publish optimized for speed and scale
• Configuration: Author includes editing tools, Publish streamlined for delivery
• Security: Author highly secured, Publish hardened for public exposure

Dispatcher: Often sits in front of Publish instances, providing caching, load balancing, and security filtering. The Dispatcher cache serves static content efficiently, reducing load on Publish instances.

Explain the concept of Sling and its role in AEM

Apache Sling forms the web application framework underlying AEM, providing the mechanism for request processing and content delivery. Understanding Sling is crucial for AEM development, as it governs how URLs map to content and how requests are handled.

Core Sling Concepts:

Resource Resolution: Sling decomposes URLs into resource paths and selectors/extensions. For example, /content/site/page.html resolves to the page resource with HTML rendering. The URL structure maps directly to the JCR repository path, making the content tree accessible via HTTP.

Script Resolution: Once Sling identifies a resource, it searches for scripts to render it based on resource type, selectors, extension, and HTTP method. The search follows a specific priority order, checking multiple locations before selecting the most specific script. This mechanism allows developers to override default rendering or provide specialized rendering for specific scenarios.

Resource Types: Every resource in JCR has a sling:resourceType property defining which component renders it. Resource types are paths pointing to component definitions in the repository. This indirection allows changing rendering without modifying content.

Servlet Registration: Developers register servlets with specific resource types, paths, selectors, or extensions using OSGi annotations. Sling routes matching requests to appropriate servlets for processing.

Sling Models: A framework for mapping JCR resources to Java objects using annotations. Sling Models simplify accessing content properties and creating presentation logic, reducing boilerplate code for common patterns.

What is JCR (Java Content Repository)?

JCR (Java Content Repository) is a Java API specification for accessing content repositories in a uniform manner. AEM uses Apache Jackrabbit Oak as its JCR implementation, providing the foundation for all content storage.

JCR Key Concepts:

Hierarchical Structure: Content organizes in a tree structure with nodes containing properties and child nodes. Each node has a primary type defining its structure and behavior. This hierarchy naturally represents content relationships like pages containing components.

Properties: Nodes store data as properties with specific types (String, Long, Boolean, Date, Binary, etc.). Properties can be single-valued or multi-valued. This flexible schema accommodates diverse content types without rigid table structures.

Node Types: Define the structure and constraints for nodes. Primary types determine node behavior, while mixin types add optional features. Node types specify allowed properties, child nodes, and constraints, providing schema enforcement while maintaining flexibility.

Sessions: JCR sessions provide transactional access to repository content. Operations execute within session context, with changes saved atomically through session.save(). Sessions must be properly managed (opened and closed) to prevent resource leaks.

Querying: JCR supports multiple query languages including JCR-SQL2 and QueryBuilder API. Queries search content based on property values, path constraints, and full-text search. Proper indexing is essential for query performance.

Versioning: JCR provides built-in versioning for tracking content changes over time. Version history maintains previous content states, enabling rollback and comparison. AEM extends this with page versioning features.

AEM Components Interview Questions

Component development represents core AEM functionality, making component-related questions common in AEM interviews.

What is an AEM Component?

An AEM component is a modular, reusable element that renders content on pages. Components encapsulate presentation logic, dialogs for authoring, and client libraries for styling and behavior. Each component serves a specific purpose, from simple text blocks to complex interactive features.

Component Structure:

Components reside in the JCR repository under /apps/<project>/components/. A typical component includes:

• HTL/Sightly scripts: Render component output (e.g., component.html)
• Dialog definition: Author interface for configuring the component (cq:dialog)
• Design dialog: Template-level configuration (cq:design_dialog)
• Client libraries: CSS and JavaScript for styling and behavior
• Java backing class: Optional Sling Model or WCMUsePojo for business logic
• Thumbnail: Visual representation in component browser

Resource Type: Components are referenced by their resource type (repository path). Pages and content fragments specify which component renders them through the sling:resourceType property.

Component Hierarchy: Components can inherit from other components using sling:resourceSuperType, enabling reuse and specialization. Child components inherit parent rendering logic while overriding specific aspects.

Explain the difference between Foundation Components and Core Components

This AEM interview question addresses a fundamental shift in AEM development practices.

Foundation Components:

The original AEM component library providing standard functionality like text, image, carousel, etc. Foundation components served as building blocks for AEM sites for many years. However, they presented several limitations:

• Monolithic structure: Tightly coupled rendering and business logic
• Limited extensibility: Difficult to customize without copying entire components
• Inconsistent patterns: Components developed over time with varying approaches
• Maintenance burden: Deprecated in favor of Core Components

Core Components:

Modern, well-engineered components following best practices and current standards. Core Components represent Adobe’s recommended approach for new projects:

Key Advantages:

• Modular architecture: Clean separation of concerns with HTL rendering and Sling Models
• Highly configurable: Extensive authoring dialogs with feature toggles
• Responsive design: Built-in responsive behavior and image optimization
• Accessibility: WCAG 2.1 AA compliance out of the box
• Style System integration: Support for style variations without code changes
• Active development: Regular updates with new features and improvements
• Best practices: Demonstrates proper patterns for custom development
• Open source: Available on GitHub for learning and contribution

When to use Core Components:

New projects should use Core Components as the foundation, extending them through proxy components or delegation patterns. Migration from Foundation to Core Components is recommended for existing projects to leverage modern capabilities and ongoing support.

What is HTL/Sightly in AEM?

HTL (HTML Template Language), formerly called Sightly, is AEM’s server-side templating language for rendering component markup. HTL replaced JSP and ESP as the recommended templating approach.

HTL Advantages:

Security: Automatic XSS protection through context-aware output encoding. HTL analyzes output context (HTML element, attribute, JavaScript, CSS, URL) and applies appropriate encoding automatically, preventing most common security vulnerabilities without developer intervention.

Simplicity: Clean, HTML-like syntax that designers can understand. Logic remains minimal in templates, with complex business logic delegated to Java backing classes (Sling Models). This separation improves maintainability and testability.

Performance: HTL compiles to optimized Java code, providing excellent runtime performance. The compiled classes execute efficiently without template parsing overhead.

Future-proof: Adobe’s strategic templating language with ongoing investment and development.

HTL Syntax Examples:

<!-- Display property -->
<h1>${properties.title}</h1>

<!-- Conditional rendering -->
<div data-sly-test="${properties.showSection}">
    <p>${properties.description}</p>
</div>

<!-- Iteration -->
<ul data-sly-list.item="${model.items}">
    <li>${item.title}</li>
</ul>

<!-- Include other components -->
<div data-sly-resource="${'path/to/resource' @ resourceType='myproject/components/component'}"></div>

<!-- Use object (Sling Model) -->
<div data-sly-use.model="com.myproject.core.models.MyModel">
    <p>${model.processedValue}</p>
</div>

Context-Aware Encoding: HTL automatically encodes output based on context. Values in element content receive HTML encoding, attribute values receive attribute encoding, JavaScript strings receive JavaScript encoding, etc.

What are Sling Models and why use them?

Sling Models provide a POJO (Plain Old Java Object) approach for adapting Sling resources to Java objects using annotations. They represent the modern, preferred method for implementing component business logic in AEM.

Sling Models Benefits:

Annotation-driven: Simple annotations handle injection of properties, child resources, OSGi services, and other dependencies. This declarative approach reduces boilerplate code significantly.

Testability: POJOs are easily unit tested without requiring AEM runtime, improving test coverage and development velocity.

Clean separation: Business logic resides in Java classes separate from presentation templates (HTL), following best practices for separation of concerns.

Type safety: Strongly typed Java objects provide compile-time checking and IDE support, reducing errors.

Sling Model Example:

@Model(adaptables = {SlingHttpServletRequest.class, Resource.class},
       defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)
public class MyComponentModel {
    
    @ValueMapValue
    private String title;
    
    @ValueMapValue
    private String description;
    
    @ChildResource
    private Resource image;
    
    @OSGiService
    private QueryBuilder queryBuilder;
    
    @PostConstruct
    protected void init() {
        // Initialization logic
    }
    
    public String getTitle() {
        return StringUtils.defaultString(title, "Default Title");
    }
    
    public String getProcessedDescription() {
        // Business logic for processing description
        return description != null ? description.toUpperCase() : "";
    }
}

Usage in HTL:

<div data-sly-use.model="com.myproject.core.models.MyComponentModel">
    <h2>${model.title}</h2>
    <p>${model.processedDescription}</p>
</div>

Adaptable Types: Sling Models can adapt from Resource or SlingHttpServletRequest. Adapting from request provides access to request-specific data, while resource adaptation focuses on content structure.

Explain Component Dialog in AEM

Component dialogs define the authoring interface for configuring components. Dialogs allow content authors to input data without touching code or repository structure directly.

Also Read: AEM Tutorial 

Dialog Types:

cq:dialog (Touch UI Dialog): The modern dialog format using Granite UI framework. Defined in XML or JSON, these dialogs use Granite/Coral UI components providing responsive, touch-friendly authoring interfaces.

dialog (Classic UI): Legacy dialog format for Classic UI (deprecated). New development should use Touch UI dialogs exclusively.

cq:design_dialog: Template-level configuration applying to all instances of the component in a template. Design dialogs configure default values, style options, or global component behavior.

Dialog Structure Example:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
    xmlns:cq="http://www.day.com/jcr/cq/1.0"
    xmlns:jcr="http://www.jcp.org/jcr/1.0"
    xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
    jcr:primaryType="nt:unstructured"
    jcr:title="My Component"
    sling:resourceType="cq/gui/components/authoring/dialog">
    <content
        jcr:primaryType="nt:unstructured"
        sling:resourceType="granite/ui/components/coral/foundation/container">
        <items jcr:primaryType="nt:unstructured">
            <tabs
                jcr:primaryType="nt:unstructured"
                sling:resourceType="granite/ui/components/coral/foundation/tabs">
                <items jcr:primaryType="nt:unstructured">
                    <properties
                        jcr:primaryType="nt:unstructured"
                        jcr:title="Properties"
                        sling:resourceType="granite/ui/components/coral/foundation/container">
                        <items jcr:primaryType="nt:unstructured">
                            <title
                                jcr:primaryType="nt:unstructured"
                                sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
                                fieldLabel="Title"
                                name="./title"/>
                            <description
                                jcr:primaryType="nt:unstructured"
                                sling:resourceType="granite/ui/components/coral/foundation/form/textarea"
                                fieldLabel="Description"
                                name="./description"/>
                        </items>
                    </properties>
                </items>
            </tabs>
        </items>
    </content>
</jcr:root>

Common Dialog Fields:

• Textfield: Single-line text input
• Textarea: Multi-line text input
• PathBrowser: DAM or content path selection
• Checkbox: Boolean value
• Select/Dropdown: Fixed list of options
• Radio: Single selection from options
• Datepicker: Date selection
• NumberField: Numeric input with validation
• Hidden: Store values not visible to authors
• Multifield: Repeatable field sets for lists

AEM Templates Interview Questions

Templates define page structure, making template-related questions important in AEM interviews.

What are AEM Templates?

AEM templates define the structure, initial content, and allowed components for pages. Templates provide consistency across site sections while enabling appropriate flexibility for content authors.

Template Types:

Static Templates (Traditional): Older template approach where structure is defined in code under /apps/<project>/templates/. Static templates are less flexible, requiring code changes for structural modifications.

Editable Templates (Recommended): Modern template approach allowing template editing through AEM UI. Editable templates separate structure (template), policies (what’s allowed), and content (initial content), providing superior flexibility.

Explain Editable Templates?

Editable Templates represent AEM’s modern, flexible templating approach, making this a critical AEM interview topic.

Editable Template Architecture:

Template Type: Defines basic structure and properties for templates. Template types reside in /conf/<config-name>/settings/wcm/template-types/ and define the foundation for specific templates.

Template: The actual template instance created from a template type. Templates define page structure using Layout Container, initial content, and component policies. Templates are stored in /conf/<config-name>/settings/wcm/templates/.

Policy: Defines which components are allowed, default values, and style system options. Policies are created in Template Editor and stored separately, enabling reuse across templates and template structures.

Page: The actual content page created from a template. Pages inherit structure from templates but allow content authoring within defined constraints.

Editable Template Benefits:

Flexibility: Structure modifications through UI without code changes. Content authors with appropriate permissions can evolve template structures as requirements change.

Policies: Reusable component configurations and allowed component definitions. Policies separate what’s structurally possible from what’s permitted, enabling governance while maintaining flexibility.

Initial Content: Define default content for new pages, accelerating content creation and ensuring consistency.

Layout Container: Responsive grid system for organizing components with responsive breakpoints, supporting mobile-first design.

Versioning: Templates maintain version history, enabling rollback and change tracking.

What is the difference between Template and Page?

This fundamental AEM interview question clarifies the relationship between templates and pages:

Template: Blueprint defining structure, allowed components, and initial content. Templates are reusable definitions stored in configuration (/conf/). Content authors cannot modify template structure while editing pages; template modifications require appropriate permissions and occur through Template Editor.

Page: Specific content instance created from a template. Pages inherit template structure but contain unique content. Authors create, edit, and delete pages while working within template-defined constraints. Pages are stored in content hierarchy (typically /content/<project>/).

Relationship:

• Templates define “what’s possible” on pages
• Pages implement actual content within those possibilities
• Template changes can propagate to existing pages (structure/policies)
• Page content remains independent of template modifications
• One template can generate thousands of pages
• Pages reference their template through properties

Locked vs. Unlocked Components:

Templates define which areas are locked (structure) and unlocked (editable). Locked components appear on all pages but cannot be removed or modified by page authors. Unlocked areas allow component addition, removal, and configuration.

What is the Style System in AEM?

The Style System enables content authors to apply visual variations to components without developer involvement, making it a powerful feature often discussed in AEM interviews.

Style System Purpose:

Provides a way to define multiple visual styles for components that authors can select from dropdown menus. This approach separates visual presentation from component code, enabling design variations without duplicating components.

Implementation:

Define Styles: Create CSS classes for different visual variations (e.g., .hero-large, .hero-dark, .card-horizontal).

Configure Style Policy: In Template Editor, add style definitions to component policies, specifying class names and author-facing labels.

Apply Styles: Authors select styles from dropdown menu in component toolbar or dialog.

Rendered Output: AEM adds selected CSS classes to component wrapper, applying associated styling.

Example Style Policy Configuration:

{
  "cq:styleGroups": {
    "size": {
      "jcr:title": "Size",
      "styles": {
        "small": {
          "cq:styleLabel": "Small",
          "cq:styleClasses": "hero-small"
        },
        "large": {
          "cq:styleLabel": "Large",  
          "cq:styleClasses": "hero-large"
        }
      }
    },
    "theme": {
      "jcr:title": "Theme",
      "styles": {
        "light": {
          "cq:styleLabel": "Light",
          "cq:styleClasses": "hero-light"
        },
        "dark": {
          "cq:styleLabel": "Dark",
          "cq:styleClasses": "hero-dark"
        }
      }
    }
  }
}

Benefits:

• Empowers content authors with design flexibility
• Reduces component proliferation
• Simplifies maintenance (single component, multiple styles)
• Enables rapid design iterations without code changes
• Supports A/B testing and personalization

AEM Workflow Interview Questions

Workflow questions assess understanding of AEM’s process automation capabilities.

What is AEM Workflow?

AEM Workflow provides process automation and orchestration capabilities for content lifecycle management. Workflows automate repetitive tasks, enforce governance, and coordinate activities across teams.

Workflow Components:

Workflow Models: Define process steps, transitions, and routing logic. Models are created in Workflow Model Console (/libs/cq/workflow/admin/console/content/models.html) using graphical editor.

Workflow Steps: Individual units of work within workflow models. Steps can be:

• Process steps: Execute Java code or scripts
• Participant steps: Assign tasks to users or groups
• Container steps: Group multiple steps
• OR/AND splits: Conditional routing
• Dialog participant steps: Gather user input

Workflow Instances: Active execution of a workflow model. Each instance tracks current state, history, and associated payload (typically a page or asset).

Workflow Payload: The content item (page, asset, etc.) that the workflow operates on. Steps access and modify payload as part of workflow execution.

Workflow Inbox: User interface showing assigned workflow tasks. Users complete tasks, provide input, and route workflows to next steps.

Common Workflow Use Cases

Understanding typical workflow applications helps answer AEM interview questions about practical implementations:

Content Approval: Multi-stage review process where content passes through editors, legal review, and final approval before publication. Workflow routes content to appropriate reviewers, tracks approval status, and automatically publishes upon final approval.

Asset Processing: Automated processing for uploaded assets including metadata extraction, rendition generation, thumbnail creation, and archival. Workflows trigger on asset upload, coordinating multiple processing steps.

Translation Management: Orchestrating content translation including project creation, content export, translation handoff, import, and review. Workflows coordinate between content authors, translation vendors, and reviewers.

Page Activation: Scheduled or approval-based page publication. Workflows enforce governance by requiring appropriate approvals before content reaches publish instances.

Expiration Management: Automatically unpublishing or archiving content after specified dates, ensuring time-sensitive content doesn’t remain active beyond validity periods.

What are Launchers in AEM?

Launchers automatically trigger workflows based on repository events, enabling event-driven automation.

Launcher Configuration:

Event Type: Node added, removed, modified, or property changed Path: JCR path where events are monitored (supports wildcards) Conditions: Additional filters like node type, property values Workflow Model: Which workflow to trigger Run Mode: Author, publish, or both

Common Launcher Patterns:

DAM Asset Processing: Launch asset processing workflow when new assets are uploaded to /content/dam/

Automatic Activation: Trigger activation workflow when pages are created or modified in specific paths

Notification: Launch notification workflow when critical content changes

Cleanup: Trigger maintenance workflows based on content lifecycle events

Considerations:

Launchers execute synchronously by default, potentially impacting performance for high-frequency events. Async execution or event throttling may be necessary for performance optimization. Launchers should be carefully scoped to avoid triggering unnecessarily, as each trigger consumes resources.

AEM OSGi Interview Questions

OSGi understanding is essential for AEM development, making OSGi-related questions common in technical interviews.

What is OSGi in AEM?

OSGi (Open Service Gateway initiative) provides the modularity framework underlying AEM. OSGi enables deploying Java applications as collections of dynamically manageable modules (bundles) rather than monolithic applications.

OSGi Core Concepts:

Bundles: JAR files containing Java classes, resources, and metadata (manifest). Bundles represent deployment units that can be installed, started, stopped, updated, or uninstalled independently. Each bundle has lifecycle states (installed, resolved, starting, active, stopping, uninstalled).

Services: Objects registered in OSGi service registry, available to other bundles through well-defined interfaces. Services enable loose coupling—bundles depend on service interfaces rather than implementations. Services can be dynamically registered and unregistered at runtime.

Components: OSGi Declarative Services (DS) provides component model for creating and consuming services using annotations. Components automatically handle service lifecycle, dependencies, and configuration.

Configuration: OSGi Configuration Admin service provides centralized configuration management. Configurations are created in Felix console or configuration files and injected into components automatically.

What are OSGi Services?

OSGi services enable component communication through service registry, making service understanding critical for AEM development.

Service Registration:

Services register in OSGi service registry, making them discoverable by other components. Registration includes service interface(s) and optional properties for service selection.

Service Example:

@Component(service = MyService.class)
public class MyServiceImpl implements MyService {
    
    @Reference
    private QueryBuilder queryBuilder;
    
    @Override
    public List<Result> performSearch(String searchTerm) {
        // Implementation using injected QueryBuilder service
        return results;
    }
}

Service Consumption:

@Component(service = MyComponent.class)
public class MyComponent {
    
    @Reference
    private MyService myService;
    
    public void doSomething() {
        List<Result> results = myService.performSearch("query");
        // Use results
    }
}

Service Benefits:

Decoupling: Consumers depend on interfaces, not implementations. Implementations can change without affecting consumers.

Replaceability: Multiple implementations can coexist. Service ranking and targeting enable selecting specific implementations.

Dynamic: Services can come and go at runtime. OSGi handles dependency injection and lifecycle automatically.

Testing: Services facilitate unit testing through dependency injection and interface-based design.

Explain OSGi Configurations in AEM

OSGi configurations provide runtime settings for services and components without code changes.

Configuration Methods:

Felix Console: Web interface (/system/console/configMgr) for creating and modifying configurations. Suitable for development but not recommended for production deployment.

Configuration Files: .cfg.json or .config files deployed with code, representing configuration as code. Files reside in /apps/<project>/config/ with environment-specific subdirectories.

JCR Repository: Configurations stored in repository nodes under /apps/<project>/config/, manageable through CRXDE or package manager.

Configuration Example (.cfg.json):

{
  "service.ranking:Integer": 100,
  "max.results:Integer": 50,
  "enabled:Boolean": true,
  "cache.ttl:Long": 3600000,
  "allowed.paths": [
    "/content/site1",
    "/content/site2"
  ]
}

Configuration Injection:

@Component(service = MyService.class)
@Designate(ocd = MyServiceConfig.class)
public class MyServiceImpl implements MyService {
    
    private int maxResults;
    private boolean enabled;
    
    @Activate
    protected void activate(MyServiceConfig config) {
        this.maxResults = config.max_results();
        this.enabled = config.enabled();
    }
}

@ObjectClassDefinition(name = "My Service Configuration")
public @interface MyServiceConfig {
    
    @AttributeDefinition(name = "Max Results")
    int max_results() default 50;
    
    @AttributeDefinition(name = "Enabled")
    boolean enabled() default true;
}

Run Mode Specific Configurations:

AEM supports run mode-specific configurations through directory structure:

• /apps/<project>/config/ – Default configuration
• /apps/<project>/config.author/ – Author-specific
• /apps/<project>/config.publish/ – Publish-specific
• /apps/<project>/config.prod/ – Production-specific

What are OSGi Bundles?

Bundles represent the deployment and modularity unit in OSGi, containing Java classes and resources with metadata defining dependencies and capabilities.

Bundle Structure:

JAR file containing:

• Java classes organized in packages
• Resources (templates, client libraries, etc.)
• META-INF/MANIFEST.MF with OSGi metadata

Manifest Metadata:

Bundle-Name: My Project Core
Bundle-SymbolicName: com.myproject.core
Bundle-Version: 1.0.0
Export-Package: com.myproject.core.models,com.myproject.core.services
Import-Package: org.apache.sling.api,javax.jcr,org.osgi.service.component

Key Manifest Headers:

Bundle-SymbolicName: Unique bundle identifier Bundle-Version: Semantic version (major.minor.patch) Export-Package: Packages this bundle makes available to others Import-Package: Packages this bundle requires from other bundles Require-Bundle: Direct bundle dependencies (avoid when possible)

Bundle Lifecycle:

1. Installed: Bundle deployed but not yet resolved
2. Resolved: Dependencies satisfied, ready to start
3. Starting: Bundle activator executing
4. Active: Bundle running normally
5. Stopping: Bundle deactivating
6. Uninstalled: Bundle removed from framework

Bundle Management:

Felix console (/system/console/bundles) provides bundle management interface showing all bundles, their states, and allowing start/stop/update operations.

AEM Performance Interview Questions

Performance optimization knowledge demonstrates advanced AEM expertise.

How do you optimize AEM performance?

Performance optimization in AEM encompasses multiple layers and approaches:

Caching Strategies:

Dispatcher Cache: Configure aggressive dispatcher caching for all static and semi-static content. Use cache rules to define what caches and invalidation patterns. Proper cache headers ensure browsers and CDNs cache appropriately.

Browser Cache: Set appropriate cache control headers for assets (long expiry) and HTML (shorter, but cacheable).

AEM Cache: Utilize internal caches including result cache, local disk cache on query processing layer, and rendered fragment caching.

Query Optimization:

Oak Indexes: Create appropriate indexes for query predicates. Monitor slow queries and add indexes for frequent queries. Use Query Performance tool to analyze query execution and index usage.

Avoid Traversal: Queries should leverage indexes rather than traversing nodes. Traversal queries don’t scale and cause performance issues as content grows.

Limit Results: Use limits and offsets appropriately, avoiding retrieving more results than needed.

Component Optimization:

Lazy Loading: Load below-the-fold components lazily to improve initial page load.

Client Libraries: Minify and combine CSS/JavaScript. Use AEM clientlib categories and embedding to optimize resource loading.

Image Optimization: Use Dynamic Media or adaptive image servlets to serve appropriately sized images. Enable responsive images and modern formats (WebP).

Efficient HTL: Avoid complex logic in templates, delegate to Sling Models. Minimize object creation and resource-intensive