AEM Interview Questions

AEM Sites is the component for building and managing websites and digital experiences. AEM Assets is the digital asset management component for storing, organizing, and delivering images, videos, and documents. AEM Forms handles creating and managing digital and print forms, and organizations can use one or more of these depending on their needs.

The JCR, Java Content Repository, is the underlying content storage model AEM is built on, based on the Content Repository API for Java specification. It stores content as a hierarchical tree of nodes and properties, similar conceptually to a file system, rather than in traditional relational database tables.

Apache Sling is a web framework AEM is built on top of that maps HTTP requests to content stored in the JCR based purely on the request's URL structure, using a resource centric approach rather than traditional servlet based routing. This lets AEM resolve which component should render a given piece of content just from the URL and node type.

A component in AEM is a reusable building block, like a text block, image, or carousel, that authors can drag onto a page to add content. Each component typically has an associated dialog for authors to configure its content and a script that renders its HTML output.

A template defines the overall structure and allowed components for a category of pages, giving authors a consistent starting point when creating new content. AEM supports both older static templates and newer editable templates that let authorized users configure the template's structure through the AEM interface itself.

CRXDE Lite is a browser based development tool in AEM that lets developers browse and directly edit the JCR repository's node structure, useful for quickly inspecting content, creating nodes, or making small script changes without needing a full IDE setup.

A page in AEM is a node in the JCR repository of type cq:Page that represents a single web page, containing a jcr:content child node that holds the page's properties and the components placed on it.

The author instance is where content creators and developers work to create, edit, and preview content before it goes live. The publish instance is the environment that serves the finalized content to actual site visitors. Content is moved from author to publish through a process called replication or activation.

Replication is the process of pushing content changes from the author instance to one or more publish instances, or sometimes from author to other authors, so that approved content becomes visible to end users. It can happen automatically on activation or through scheduled and workflow driven processes.

A dialog is the configuration form authors see when they select a component to edit, letting them input the content and settings the component needs, like text, an image path, or a link. Dialogs are typically defined using AEM's Granite UI framework and stored as nodes under the component's cq:dialog node.

Sling Resource Resolution is the process by which Sling maps an incoming HTTP request URL to a specific resource in the JCR repository, then determines which script or servlet should render that resource based on its resource type, forming the foundation of how AEM decides what to render for any given URL.

HTL, HTML Template Language, formerly called Sightly, is AEM's preferred templating language for writing component rendering scripts. It's designed to keep presentation logic simple and secure by restricting how much business logic can be embedded directly in the markup, pushing complex logic into backing Java classes instead.

A Sling Model is a Java class annotated to automatically adapt from a Sling resource or request, exposing content properties and business logic to the HTL template in a clean, testable way. It's the recommended pattern for backing component logic in modern AEM development.

The Package Manager is a tool within AEM used to create, install, and manage packages, which are archives containing content, code, or configuration that can be exported from one AEM instance and imported into another, commonly used for deployments and content migration.

A workflow in AEM is a defined sequence of steps, like requesting approval before publishing a page, that content or assets move through, often involving multiple people or automated processes. Workflows help enforce governance and consistency around how content changes get reviewed and released.

The Dispatcher is Adobe's caching and load balancing module that sits in front of AEM publish instances, typically as a web server plugin, caching rendered pages so repeat requests don't need to hit AEM directly, and also providing a layer of security by filtering which requests are allowed through.

A client library is a structured way to organize and deliver CSS and JavaScript files in AEM, allowing them to be grouped by category, minified, and combined for efficient delivery to the browser rather than being referenced as many separate individual files.

A static template is defined entirely in code by a developer, with a fixed structure authors can't change. An editable template lets authorized users configure the allowed components, layout, and policies for that template type directly through the AEM authoring interface, without needing a developer to make code changes.

A policy defines the configuration and allowed options for a component when it's used within a specific template or page context, like which components can be dropped into a particular layout container. Policies let the same component behave differently depending on where it's used.

The content tree, visible in the AEM authoring interface's sidebar, shows the hierarchical structure of pages and folders in the repository, letting authors and administrators navigate, organize, and manage pages and assets without needing to know the underlying JCR node paths directly.

A proxy component is a project specific component that extends or references a core component from Adobe's core component library, allowing projects to customize behavior or appearance while still benefiting from updates to the underlying core component, following Adobe's recommended pattern for building on core components.

The Core Components are a set of open source, Adobe maintained components covering common needs like text, image, teaser, and navigation, designed to be extended rather than rebuilt from scratch, saving development time and providing a consistent, well tested foundation for new AEM projects.

An OSGi bundle is a modular unit of Java code, packaged as a JAR file with additional metadata, that AEM's underlying OSGi framework can install, start, stop, and update independently of other bundles. AEM's own functionality and custom project code are both organized as OSGi bundles.

An OSGi configuration is a set of settings applied to a specific OSGi service or component, allowing behavior to be adjusted without changing code, such as setting a service's timeout value or endpoint URL differently across environments.

A Sling Servlet is a Java class that handles specific types of requests within AEM's Sling framework, commonly used to build custom endpoints, like a servlet that returns JSON data for a component's AJAX call, registered to respond to a particular resource type or path pattern.

Touch UI refers to the modern, responsive authoring interface introduced in AEM, replacing the older Classic UI, providing a more intuitive drag and drop authoring experience designed to work well on both desktop and touch enabled devices.

A launch is a way to create a temporary copy of a page or set of pages for working on future changes, like a redesign or a promotional campaign, without affecting the live content, which can later be promoted to merge those changes back into the main content when ready.

Multi Site Manager is an AEM feature that lets a master site's content and structure be rolled out to one or more dependent sites, commonly used for managing regional or localized versions of a website while keeping shared content synchronized from a central master.

A Live Copy is a page or site structure created through Multi Site Manager that inherits content from a master source, staying synchronized with future changes to the master unless a specific piece of content is explicitly broken off from inheritance for local customization.

A tag in AEM is a piece of metadata that can be applied to content, like pages or assets, to categorize or classify it, stored in a dedicated tag structure in the repository and usable for search, filtering, and content organization across the site.

The Digital Asset Manager, or DAM, within AEM Assets provides centralized storage and management for media files like images, videos, and PDFs, including automatic metadata extraction, renditions for different sizes or formats, and workflows for asset approval before use.

A rendition is a generated or derived version of an original asset, such as a resized thumbnail or a web optimized version of an image, automatically created by AEM's processing workflows so different use cases can pull the appropriately sized version without reprocessing the original each time.

A Content Fragment is a structured piece of channel neutral content, defined by a model with specific fields, that can be reused across multiple experiences and channels, like a website and a mobile app, separate from any specific page layout or presentation.

A Content Fragment holds structured, channel neutral content data defined by a model, without layout. An Experience Fragment is a reusable, pre-composed piece of a page's actual layout and design, like a promotional banner, meant to be reused as is across multiple pages with its visual presentation intact.

Headless content delivery means AEM exposes content, typically through Content Fragments and APIs like GraphQL, for consumption by external front end applications or other channels without AEM itself rendering the final HTML, which suits use cases like a separate JavaScript front end or a mobile app.

I would check whether the component's dependencies, like a Sling Model or backing service, were actually replicated to publish along with the content and code, review the publish instance's error log for the specific exception, and confirm any OSGi configuration differences between author and publish aren't the cause.

I would configure caching rules to cache the static, non personalized pages aggressively while excluding or using more limited caching for pages and requests that return personalized content, and use techniques like edge side includes or client side personalization to avoid personalized content breaking cacheability for the whole page.

I would use Adobe's provided upgrade tooling to identify deprecated APIs and components that need remediation, run the upgrade in a staging environment first to catch issues, and plan a content and code freeze window around the actual cutover to avoid last minute changes complicating validation.

I would inject the resource properties needed from the page directly using standard Sling Model injection annotations, and call the external service through a separate OSGi service with its own configuration and error handling, keeping the model itself focused on presenting data rather than performing the actual external call logic.

I would check the workflow's configuration to confirm the notification step is correctly wired to the right participant step and email service configuration, review AEM's workflow logs for errors during that specific step's execution, and verify the underlying email service, like an SMTP configuration, is actually working correctly.

I would default to sensible, pre-configured options rather than exposing every possible setting, group related fields logically using tabs if the dialog has many fields, and add clear field descriptions so authors understand what each option does without needing separate documentation.

I would use AEM's metadata schema editor to ensure the target fields are properly defined, and use a bulk workflow or a script leveraging AEM's APIs to update the metadata programmatically rather than manually editing each asset, especially if the count is in the hundreds or thousands.

I would check whether the slowness comes from an expensive query or external service call happening on every component render, consider caching results where appropriate even on author, and review whether too many heavy components are stacked on a single page causing cumulative rendering overhead.

I would organize client libraries by logical grouping, like a base library for shared styles and per component libraries that depend on it, use AEM's category and embed mechanism to control what gets loaded on a given page, and avoid loading every component's assets on every page regardless of whether that component is actually used.

I would check the replication queue on the author instance for errors or a backlog, verify the replication agent's connection settings to the publish instance are correct and the target is reachable, and review whether the specific content actually triggered activation versus being saved without being explicitly published.

I would evaluate whether AEM's built in query capabilities through the JCR query language are sufficient for the scale and complexity needed, and if search requirements grow more advanced, like faceted search or relevance tuning, consider indexing content into a dedicated search platform fed by AEM rather than relying purely on repository queries.

I would look at whether Multi Site Manager or Content Fragments could centralize the shared content so it's maintained once rather than duplicated across pages, and pair that with clearer authoring guidelines or governance around which content should be centrally managed versus locally editable.

I would use editable template policies to pass different configuration into the same underlying component rather than building separate components, and have the component's backing logic read that policy configuration to adjust its rendering, keeping one maintainable codebase instead of forked variants.

I would check whether the dispatcher's cache invalidation rules and flush agent are correctly configured to clear the cache on activation, confirm the flush request actually reaches the dispatcher and isn't being blocked by a firewall or misconfigured agent, and manually verify cache file timestamps against the actual republish time to confirm the mismatch.

I would check that the configuration values are externalized properly through OSGi configuration rather than hardcoded, confirm reasonable defaults exist so the service doesn't fail ungracefully if a configuration is missing in a new environment, and verify sensitive values like credentials aren't committed directly in configuration files.

I would isolate the personalized portions using client side rendering or a separate uncached endpoint the browser calls after the mostly static page loads from cache, so the bulk of the page stays cacheable while only the genuinely personalized fragment bypasses the cache.

I would start them with the fundamentals of the JCR and Sling resource resolution model since that's the biggest conceptual shift from typical Java web development, have them build a small component end to end early on, and pair them with an experienced AEM developer on their first real ticket.

I would write unit tests for the Sling Model's business logic using a mocking framework like AEM Mocks, manually verify the component's authoring dialog and rendered output in a local development instance, and check the component against both populated and empty content states to make sure it degrades gracefully.

I would check whether an existing core component's configuration options and extension points can already satisfy the requirement, since Core Components receive regular maintenance and updates from Adobe, and only build a fully custom component when the requirement genuinely falls outside what extending or configuring a core component can reasonably achieve.

I would give the new field a sensible default value so existing content renders unchanged until an author explicitly sets it, test the component against pages created before the change to confirm nothing breaks, and document the new option for authors rather than assuming the dialog change alone is self explanatory.

I would have them run a local AEM instance using the standard SDK or quickstart jar, set up their IDE with the appropriate project structure and build tooling like Maven, and walk them through deploying a small change end to end so they understand the full build and deploy cycle before working independently.

I would check whether the responsive grid configuration or breakpoint specific settings for that component are correctly configured in the template's layout, verify the image renditions being served are appropriate for the smaller viewport, and reproduce the issue directly on a mobile device or emulator rather than relying only on a resized desktop browser.

I would ask for tests covering the model's core logic, especially any conditional behavior or edge cases like missing properties, explain why untested logic in content rendering paths tends to cause silent authoring issues that are hard to trace later, and offer to pair on writing the tests if they're unfamiliar with the mocking approach used on the project.

I would run a thorough code compatibility assessment early since Cloud Service enforces stricter constraints than on-premise AEM, prioritize remediating deprecated APIs and non compliant custom code, and plan the migration in phases starting with less critical sites to validate the approach before migrating the most business critical properties.

I would layer a CDN in front of the dispatcher to absorb the bulk of traffic before it even reaches AEM's infrastructure, configure aggressive cache TTLs for content that doesn't need to be instantly fresh, and load test the full stack ahead of the expected spike to confirm cache hit rates and origin load stay within acceptable bounds.

I would model the shared content as Content Fragments with a well defined structure, expose it through AEM's GraphQL API for headless consumption by the mobile app and partner integration, while continuing to use traditional page and component rendering for the website, avoiding content duplication across channels.

I would check for expensive or poorly written queries running against the repository, review whether workflow processes or scheduled jobs are consuming excessive resources during business hours, and look at whether the repository has grown large enough that routine maintenance, like data store garbage collection, has fallen behind.

I would establish shared coding standards and a mandatory code review process, require new components to justify why an existing core component extension isn't sufficient, and set up a shared component library review process so teams aren't independently building overlapping functionality.

I would set up a standby environment with regular backups of the repository and configuration, define clear recovery time and recovery point objectives based on the actual business cost of downtime, and test failover procedures periodically rather than assuming the documented plan will work correctly when actually needed.

I would inventory which customizations still deliver real business value versus ones duplicating now available standard functionality like Core Components, and generally favor incremental modernization for business critical, actively used sites given the risk and cost of a full rebuild, while being open to a rebuild for genuinely unsalvageable areas.

I would introduce an integration or API layer between AEM and the external systems rather than building point to point connections directly into components, define clear data contracts for each integration, and make sure a failure or slowdown in one external system doesn't directly degrade page rendering performance across the site.

I would evaluate whether horizontal scaling with additional publish instances behind a load balancer meets the need, invest heavily in dispatcher and CDN caching to reduce load reaching AEM directly, and consider AEM as a Cloud Service's auto scaling capabilities if the organization is positioned to move toward that model.

I would use OSGi configuration with run mode specific settings so the same code deploys unchanged across environments while configuration values differ appropriately, keep sensitive credentials out of source control using a secrets management approach, and validate configuration correctness as part of the deployment pipeline rather than discovering issues after deployment.

I would use Experience Fragments to define the reusable promotional layout and content once, reference it across the relevant landing pages so an update only needs to happen in a single place, and set up clear ownership over the fragment so accountability for its accuracy doesn't get lost across the many pages that depend on it.

I would weigh the reduced operational burden and access to newer capabilities Cloud Service offers against the migration cost and any custom code remediation required, and build a business case tied to Adobe's own support timeline pressure alongside the operational efficiency gains.

I would define a baseline required approval workflow for content going live, allow business units some flexibility in additional review steps specific to their needs, and set clear ownership boundaries in the content tree so different teams aren't able to accidentally impact each other's site sections.

I would base the decision on evidence of actual business impact, like conversion lift from a pilot personalization effort, rather than pursuing personalization for its own sake, since it adds real complexity to caching and content management that needs to be justified by measurable value.

I would inventory custom components and code by actual usage and business criticality, prioritize replacing the highest maintenance, lowest differentiation customizations with Core Components or standard functionality first, and build this reduction into the roadmap as ongoing work rather than a one time cleanup effort.

I would require consistent metadata standards and folder structure conventions across teams, set up approval workflows for assets before they're available for use sitewide, and periodically audit for duplicate or outdated assets that accumulate without ongoing governance.

I would evaluate which capabilities are core to how the organization differentiates its digital experience and build those in-house over time, while continuing to use external partners for specialized, infrequent needs like a major platform migration, to avoid ongoing premium costs for steady state work.

I would define measurable performance targets, like page weight and load time thresholds, tied to business impact data on how performance affects engagement, and build automated checks into the deployment pipeline that flag or block changes pushing a site meaningfully past its budget.

I would fund it as a shared service with cost allocated based on usage or business unit size, justify the investment through reduced duplicate development effort and more consistent governance, and periodically reassess whether the center's scope still matches how the organization's AEM footprint has evolved.

I would require a review and approval process before any new third party script is added, using AEM's tag management or client library structure to load scripts asynchronously where possible, and periodically audit existing integrations to remove ones that are no longer actually needed.

I would weigh the operational efficiency and consistency a shared platform provides against the isolation and independence separate instances give each business unit, and generally favor consolidation where governance can keep pace, while accepting separate instances where regulatory or organizational independence genuinely requires it.

I would define a narrow, clearly documented emergency change procedure that still requires after the fact review, so urgent fixes aren't blocked by process but also remain accounted for and don't quietly become the normal way of shipping changes.

I would frame the platform as a long lived asset needing continued investment similar to physical infrastructure, present a realistic ongoing budget tied to specific maintenance, upgrade, and improvement needs, and avoid letting a successful relaunch create the impression that spending should now drop close to zero.

I would look at signals like how often governance exceptions get requested, how much duplicated effort exists across teams, and how quickly new teams can safely start contributing, and use that evidence to decide whether the governance model needs tightening, simplifying, or more dedicated support staff.

I would set a multi year roadmap that establishes shared platform capabilities, like a common component library and governance model, early enough to prevent divergence, and sequence investment so the platform's scaling keeps pace with business unit growth rather than becoming a bottleneck that slows new site launches.

I would present concrete findings uncovered during the work, like undocumented custom code dependencies or content quality issues, tie the delay to specific risk reduction decisions rather than vague difficulty, and offer a revised plan with visible checkpoints so leadership can track progress rather than waiting on a single end date.

I would ground the discussion in the organization's actual governance maturity and how much genuine content or component reuse exists across business units, weigh the operational efficiency of consolidation against the independence separate instances provide, and make the final call myself if the debate isn't converging given the cost of prolonged indecision.

I would have them clearly articulate what specific gap existing Core Components or standard AEM functionality can't address, since I've seen engineers reach for custom builds prematurely, and coach them to weigh the long term maintenance cost of custom code against the value of the specific capability it unlocks.

I would push for that knowledge and the reasoning behind key design decisions to be documented, deliberately rotate ownership and code review responsibilities across a wider group of engineers, and treat concentrated critical knowledge as an ongoing risk to actively manage rather than something addressed only when someone gives notice.

I would coach them to lead with the specific pain point a team already feels, like duplicated maintenance effort or inconsistent performance, rather than a general mandate for standardization, and have them build a track record of concrete wins with a willing team first to make the case credible to more skeptical ones.

I would look for strong fundamentals in Java and web architecture rather than requiring deep AEM specific expertise on day one, since that adapts with good mentoring, and pair new hires with an experienced engineer on real project work before giving them independent ownership of business critical sites.

I would invest ahead of the demand curve in self service tooling and documentation so routine requests don't all require direct center of excellence involvement, plan staffing growth proactively rather than reactively, and periodically reassess whether the center's structure still matches the organization's current scale.

I would present a phased plan grounded in what's realistically achievable per quarter given team capacity and each business unit's own release cycles, be explicit about dependencies like content migration and custom code remediation that affect timeline, and avoid overpromising a fast, organization wide consolidation that would set the initiative up to look like it's failing.

I would assess which of the three currently poses the greatest risk to the platform's overall health and the business's confidence in it, and generally weight allocation toward stabilizing the foundation before aggressively expanding scope, while keeping a visible, fair process for prioritizing the business unit requests that genuinely can't wait.

I would make raising these issues a normal, rewarded part of the process rather than something reflecting poorly on the original author, allocate real time in the roadmap to address flagged issues rather than treating it as something to fit around feature work, and follow through visibly so the team trusts that flagging problems actually leads to improvement.

I would start a structured knowledge transfer well ahead of the transition, involve less experienced engineers in real architectural decisions under the architect's guidance rather than passive documentation review, and identify one or more successors who get genuine ownership of key platform areas before the transition is complete.

I would define a small set of non negotiable organization wide standards, like security and performance baselines, while leaving content strategy and lighter customization choices to individual business units who understand their own audience best, revisiting where that balance sits as the organization and platform both evolve.