AEM Architect Interview Prep: Questions and How to Answer Them

Senior AEM interviews (lead, architect, solution architect) differ from developer interviews. Interviewers assume you can write a Sling Model. What they want to find out is whether you can design a platform, defend trade-offs, anticipate operational problems and lead a team. This post covers the topics that come up most, with model answers you can adapt in your own words.

How Senior Interviews Are Different

The most common failure is giving a textbook definition when the interviewer wanted a decision. Always finish an answer with why, and when you'd choose differently.

A Framework for Any Design Question

When asked an open design question, don't start with the technology. Use a consistent flow:

1. Clarify requirements: scale, number of brands and locales, authors, integrations, timelines, compliance
2. State assumptions out loud, so the interviewer can correct you
3. Propose the high-level architecture: author/publish/Dispatcher/CDN, content structure, integrations
4. Walk through the key decisions and the alternatives you rejected
5. Cover non-functional needs: performance, security, availability, observability, cost
6. Name the risks and how you'd reduce them
7. Say how you'd deliver it: phases, team shape, what to build first

Interviewers score the structure of your thinking at least as much as the final diagram.

Core Platform Questions

1. Explain the AEM architecture and how a request flows.

Model answer outline: Author for authoring and workflows, Publish for serving, replication (or Sling Content Distribution on Cloud Service) moving content between them. A request hits the CDN, then Dispatcher, which serves a cached file if valid, and otherwise asks Publish to render using Sling resolution and HTL. Mention that Cloud Service adds an Adobe-managed CDN and pipeline-based distribution.

2. How does Sling resolve a request to a script?

Outline: The URL is split into path, selectors and extension. Sling resolves the resource at that path, reads its sling:resourceType, and looks for a matching script, searching /apps first and then /libs. Selectors and the HTTP method refine the match. Mention overlays and why you never modify /libs.

3. OSGi: what is it and how do you use it in AEM?

Outline: A modular runtime where bundles expose services. You write OSGi components with @Component, inject others with @Reference, and make them configurable with @Designate and a config class. Configuration varies by run mode and, on Cloud Service, by environment. Mention @Activate/@Deactivate and keeping services stateless where possible.

4. Sling Models vs WCMUsePojo vs servlets: when do you use which?

Outline: Sling Models for component logic (testable, annotation-driven). Servlets for endpoints that return data or accept requests, registered by resource type, not by path where possible, because path-bound servlets are harder to secure. Avoid WCMUsePojo in new work.

5. How do editable templates work?

Outline: Templates have a structure (locked content), initial content (copied to new pages) and policies (what components are allowed and how they're configured). Page policies and content policies are stored under /conf. Mention template types and why editable templates replaced static ones.

6. Content Fragments vs Experience Fragments: when to use each?

Outline: Content Fragments hold structured, channel-neutral content, suited to headless delivery through GraphQL. Experience Fragments hold a designed block (content plus layout) that you reuse across pages or export to other channels. If the same content needs different presentations, use CFs. If the same presentation needs reuse, use XFs.

7. What is MSM and when would you avoid it?

Outline: Multi Site Manager lets you maintain a blueprint and live copies that inherit from it, with rollout configurations controlling how changes propagate. It suits tightly governed brands and regional variants. Avoid it when sites diverge heavily, since constant overrides erode the inheritance and the maintenance cost exceeds the benefit. Compare with language copies and translation workflows for pure localization.

Architecture and Operations Questions

8. How does Dispatcher caching work and what makes content stale?

Outline: File-based cache, cacheable only if it meets conditions (GET, extension, no query string unless ignored, 200 response, no no-cache headers). Invalidation via .stat files and /statfileslevel, flush requests after activation, TTL-based expiry. Stale content usually comes from a missed flush, a wrong /invalidate rule, a too-deep /statfileslevel, or the CDN holding an old copy.

9. Your cache hit ratio is poor. What do you do?

Outline: Measure first. Look for uncacheable requests: query strings, no-cache headers, missing extensions and cache rules that deny paths. Use an allow-list for ignorable parameters, set TTLs, move personalization out of cached HTML (client-side or Sling Dynamic Include), tune /statfileslevel. Then re-measure.

10. Compare AEM 6.5 and AEM as a Cloud Service.

Outline: Managed platform with continuous updates and auto-scaling, deployment through Cloud Manager, immutable /apps and /libs, distribution instead of replication agents, Asset Compute instead of the DAM Update Asset workflow, CDN included, and quality gates in pipelines. Say what stays the same: authoring and core development model.

11. How would you migrate a 6.5 estate to Cloud Service?

Outline: Run the Best Practices Analyzer, restructure the repository into immutable and mutable parts, refactor incompatible code (replication agents, launchers, runtime /apps changes), convert Dispatcher and indexes, migrate content in passes with the Content Transfer Tool, test on Stage, cut over with a content freeze. Mention risk management and rollback.

12. How do you troubleshoot "I published but it isn't live"?

Outline: Walk the pipeline left to right: Author status, replication or distribution, Publish (request directly), Dispatcher (.stat and cached file), CDN (Age, Cache-Control), browser. Check references and permissions. The key point is a method, not a guess.

13. How do you handle performance problems on Publish?

Outline: Baseline first. Raise cache hit ratio, then find slow queries (Query Performance, traversal warnings, indexes), remove work from rendering, fix resolver leaks, and reduce frontend weight. On 6.5, add JVM and repository maintenance. On Cloud Service, remember that scaling is automatic but inefficient code still costs.

Assets Questions

14. How does asset processing work on Cloud Service?

Outline: Direct binary upload, Asset Compute generates renditions and metadata through processing profiles, then a post-processing workflow runs for extra steps. Custom renditions come from custom Asset Compute workers on Adobe I/O Runtime. Don't process binaries inside workflow steps.

15. How would you design a DAM for a multi-brand organization?

Outline: Organize by ownership (brand, then function, then campaign or product), not by file type. Use metadata and tags for attributes, groups for permissions, processing and metadata profiles at the right folder level, naming conventions, expiry and archive rules. Mention Smart Tags with governance and sensitive-content exclusions.

Security Questions

16. How do you secure an AEM implementation?

Outline: Layers. Dispatcher filters (default deny, allow only needed paths and selectors), no Author exposed publicly, ACLs through groups, service users instead of admin sessions, HTL's context-aware XSS protection, CORS policies, CSRF protection, secure headers, dependency and code scanning in the pipeline, secrets in environment variables, SSO through your identity provider. Mention regular penetration testing and keeping up with Adobe's security bulletins.

17. What is a service user, and why does it matter?

Outline: A system user with minimal permissions, mapped to a bundle's subservice and used to open a resource resolver from code. It replaces deprecated admin sessions, follows least privilege and makes audits clear. Always close the resolver.

Modern Platform Questions

18. When would you recommend headless AEM?

Outline: When content must reach several channels or a decoupled front end, and the team has front-end capability. Use Content Fragments and persisted GraphQL queries with CDN caching. Mention costs: less in-context authoring, more front-end work, and the need for preview strategy.

19. Where does Edge Delivery Services fit?

Outline: A performance-first delivery model with code in Git, content from documents or AEM through the Universal Editor, and blocks instead of components. Strong for marketing and content sites that need speed and fast launch. Classic Sites still suits complex server-side logic and heavy governance. Often the right answer is a mix. Be honest about feature parity checks.

Scenario: The Whiteboard Question

"Design a platform for a company with 8 brands, 25 locales and 60 authors."

Walk through, in your own words:

• Clarify: brand independence, shared components, compliance, integrations (commerce, CRM, search), traffic profile, release cadence
• Platform: AEM as a Cloud Service, Cloud Manager pipelines, CDN plus Dispatcher
• Content structure: a root per brand, then language roots, with a consistent tree. MSM or language copies depending on how much brands share
• Code structure: a shared core of components and styles with brand-specific themes, a design system, and clear ownership of each module
• DAM: brand folders, a shared folder for cross-brand assets, metadata schemas, processing profiles
• Governance: groups per brand, approval workflows, template and policy ownership
• Search and integrations: where search lives, how external systems connect, secrets handling, egress rules
• Non-functionals: cache strategy and hit ratio targets, availability, monitoring through log forwarding, security reviews, accessibility
• Delivery: a pilot brand first, shared foundations, then onboarding other brands in waves
• Risks: over-customizing MSM, inconsistent component usage, content migration quality, author training

End by naming the decision you're least sure about and how you'd reduce that uncertainty, which signals mature judgment.

Leadership and Behavioral Questions

At lead and architect level, expect these:

• "Tell me about a technical decision you made that turned out wrong."
• "How do you run code reviews and maintain quality across a team?"
• "How do you estimate and manage risk on a large AEM project?"
• "How do you handle a disagreement with a client or architect?"
• "How do you grow juniors in your team?"
• "Describe how you've worked across onshore and offshore teams."

Use a simple STAR structure (Situation, Task, Action, Result), and spend most of the time on Action and Result. Include numbers where you honestly can: team size, delivery dates, performance improvements, defects reduced. Never claim credit for team results as personal results, because interviewers probe for exactly that.

Preparation Plan

1. Pick three real projects and be ready to explain architecture, your role, one hard problem and the outcome
2. Practice the framework on three design questions out loud, with a timer
3. Refresh the differences between 6.5 and Cloud Service, and Dispatcher details, because these come up in almost every interview
4. Know the modern topics (headless, EDS, Universal Editor) well enough to discuss trade-offs, even if you haven't used them in production
5. Prepare questions for them: team structure, delivery model, client maturity, what success looks like in six months
6. Be honest about gaps. "I haven't done that in production, but here's how I'd approach it" is a strong answer, and a bluff is not

Common Mistakes

• Reciting definitions without a decision or a trade-off
• Jumping to technology before clarifying requirements
• Ignoring non-functional needs such as security, cost and operations
• Presenting one solution as the only possible one
• Overstating personal ownership of team work
• Not knowing current Cloud Service behavior because experience is only on 6.x

What's Next

The last topic in this series is one you will almost certainly face, whether in an interview or on the job: migrating to AEM as a Cloud Service, with the practical lessons that documentation tends to leave out.

Next in this series: [Migrating to AEM as a Cloud Service: Lessons Learned]