AD0-E117 · Question #1
A client is using AEM and wants to make sure they are managing their configurations correctly. Refer to the following requirements: - The client has multiple brands that they will be hosting on a…
The correct answer is C. Use OSGi to manage approval group and provide default contact us information by runmode. Important note: Based on AEM architecture principles, I believe the stated correct answer (C) may be incorrect on this question. The architecturally sound answer for this scenario is B. Here's why: Why B is the correct architectural recommendation: Context-Aware Configurations…
Question
A client is using AEM and wants to make sure they are managing their configurations correctly. Refer to the following requirements:
- The client has multiple brands that they will be hosting on a single AEM implementation
- The client wants to reuse as much between brands as possible
- Each brand needs to be able to override the default values for items like contact us information
- The client plans to support multiple languages in multiple regions for each brand
- Each brand/language/region combination will have its own set of content approvers used as part
of a custom workflow Which approach should an Architect recommend to manage the client's configurations for AEM?
Options
- AUse the OOTB Configuration Browser to set configuration defaults and approval group by
- BUse Context-aware configurations to manage configuration overrides and approval group by
- CUse OSGi to manage approval group and provide default contact us information by runmode.
- DUse OSGi Configuration to handle configuration overrides by brand. Create a new workflow for
How the community answered
(36 responses)- A17% (6)
- B28% (10)
- C47% (17)
- D8% (3)
Explanation
Important note: Based on AEM architecture principles, I believe the stated correct answer (C) may be incorrect on this question. The architecturally sound answer for this scenario is B. Here's why:
Why B is the correct architectural recommendation: Context-Aware Configurations (CAConfig) are specifically designed for multi-site, multi-brand AEM implementations - they support hierarchical overrides at the global → brand → language → region content tree levels, which maps directly to every requirement stated. CAConfig lets teams define reusable defaults and allows each brand/locale node to override only what differs, keeping content-approver groups cleanly tied to the content hierarchy.
Why each other option falls short:
- A - The Configuration Browser is the admin UI for enabling CAConfig on content roots, not a configuration strategy itself; it's a prerequisite tool, not an approach.
- C - OSGi runmodes are designed for environment differentiation (dev/stage/prod/author/publish), not for brand or locale differentiation. Using runmodes to manage brand configs means a new code deployment for every brand or region change - operationally fragile and not scalable.
- D - Same runmode limitation as C; OSGi configs live in code, making brand overrides a developer/deployment concern rather than an authoring concern.
Memory tip: Think "Where does the config live?" - OSGi/runmodes = code-level/environment concerns; CAConfig = content-tree/brand/locale concerns. When requirements mention content hierarchy overrides, reach for CAConfig.
If your source lists C as correct, I'd recommend cross-checking with Adobe's official AEM Architect study materials - this scenario is a textbook CAConfig use case.
Topics
Community Discussion
No community discussion yet for this question.