AD0-E106 Adobe Experience Manager Dev/Ops Engineer: Retired Exam Context and the Current AD0-E124 Role

AD0-E106 was the Adobe Experience Manager Dev/Ops Engineer exam. It is retired, but it represented a role that remains critical: operating AEM reliably across installation or provisioning, configuration, deployment, caching, monitoring, troubleshooting, security, and release processes. Adobe’s current certification program carries that responsibility forward in AD0-E124 Adobe Experience Manager DevOps Engineer Expert.

The biggest change since the AD0-E106 era is the operating model. Older AEM Dev/Ops work often involved direct instance installation, repository and datastore configuration, patching, dispatcher administration, topology management, and server-level troubleshooting. AEM as a Cloud Service moves many infrastructure responsibilities to Adobe and uses Cloud Manager and managed environments, so current DevOps expertise is less about manually tending servers and more about safe configuration, pipelines, observability, environment readiness, and supported cloud operations.

This evolution mirrors the wider DevOps role: automation does not remove operational responsibility; it changes where that responsibility is expressed. Within Adobe certifications, the current AEM DevOps role sits between application teams and the managed cloud platform.

Legacy Dev/Ops knowledge explains the platform layers current engineers still troubleshoot

Even when engineers no longer install every AEM instance manually, they benefit from understanding author and publish roles, the content repository, OSGi configuration, dispatcher behavior, replication or distribution concepts, logs, packages, indexes, and external dependencies. These layers help explain why an issue appears in one environment or tier but not another.

Study the request path from client to CDN or dispatcher to publish, then through application code and repository access. Separately, study the authoring-to-publishing content path. When a symptom is reported, decide which path is affected and which layer can produce it. This narrows troubleshooting much faster than changing settings at random.

Configuration should be reproducible instead of being repaired by hand

DevOps practice aims to make environments consistent. Configuration that exists only because an administrator clicked a console months ago is difficult to audit and reproduce. Current AEM projects should keep supported application and environment configuration in source control or managed platform settings so changes can be reviewed and promoted predictably.

Classify configuration by scope: application code, OSGi settings, secrets, dispatcher rules, environment variables, external endpoints, and platform-level controls may have different mechanisms. The engineer should know which changes require a code deployment, which are environment-specific, and which must be managed outside the repository.

Dispatcher and caching remain operationally important even in cloud delivery

Caching protects publish capacity and reduces latency, but only when rules match application behavior. DevOps engineers need to understand cacheability, invalidation, URL patterns, headers, filtering, allowed methods, and how personalized or authenticated content changes the strategy. A cache misconfiguration can create either a performance problem or a correctness and security problem.

Troubleshoot with evidence from request headers, cache behavior, dispatcher logs, publish logs, and reproducible URLs. If a page appears stale, determine whether the problem is authoring, publishing, invalidation, cache key design, or browser/CDN caching before purging everything. Controlled diagnosis is safer than broad operational actions.

Pipelines make build quality and deployment safety visible

Modern AEM deployments rely on automated build and release pipelines. DevOps engineers should understand source control, Maven builds, quality gates, test stages, artifact creation, environment promotion, rollback or recovery options, and how configuration is injected. A pipeline failure is not merely an inconvenience; it is a signal about the deployability of the application.

Good teams make pipeline failures actionable. Logs should identify the failing stage, application owners should know how to reproduce build issues locally when possible, and releases should not depend on undocumented manual fixes. The DevOps role helps establish this feedback loop with developers rather than acting as the final person who makes broken packages work.

Observability connects incidents to evidence instead of intuition

Logs, metrics, alerts, traces where available, health checks, and platform dashboards should answer operational questions. Is response time increasing? Are requests failing in one service? Did a deployment change the error rate? Is an external dependency timing out? Are repository operations or queries unusually expensive?

Prepare by working from symptoms to evidence. For slow pages, inspect traffic, cache ratio, application logs, external calls, and repository/query behavior. For intermittent failures, correlate timestamps across layers. For deployment-related issues, compare before-and-after versions and environment configuration. This diagnostic process is more durable than memorizing the location of one log file.

Good observability also depends on correlation. A single user request may cross CDN, dispatcher, AEM application code, authentication, and external APIs, so isolated log messages are rarely enough. Define identifiers, timestamps, and context that let operators reconstruct the path without exposing sensitive data. During practice, start from one symptom and trace it across layers. The goal is not to collect the most logs; it is to reduce the time required to distinguish an application defect, dependency failure, configuration problem, and platform issue.

Security operations include configuration hygiene and controlled privileges

AEM operational security covers administrative accounts, service permissions, secrets, network exposure, dispatcher filters, TLS, software updates, logging, and access to production environments. DevOps engineers should know the difference between fixing a symptom by granting more access and solving the actual permission or configuration problem.

Least privilege should extend to automation. Build and deployment systems need credentials, but those credentials should be scoped, rotated, and protected. Production troubleshooting should use auditable access. Operational convenience is not a reason to keep broad persistent privileges that make mistakes or compromises more damaging.

Cloud operations require understanding the boundaries of managed responsibility

AEM as a Cloud Service manages infrastructure that older teams operated directly. That does not mean every responsibility belongs to Adobe. Customer teams still own application code, dispatcher configuration within supported patterns, integrations, content models, environment-specific settings, release readiness, and investigation of application behavior.

An expert should be able to distinguish a platform incident from an application or configuration incident. Escalating everything to the provider delays resolution; trying to repair managed infrastructure directly violates the operating model. The current role requires knowing where to observe, what evidence to collect, which controls are available, and when escalation is appropriate.

Release readiness should be evaluated as an operational decision, not only as a successful pipeline result. Before a significant deployment, identify the user journeys and integrations most likely to reveal a regression, the dashboards and logs that will be watched, the acceptable error and latency ranges, and the response if those signals move outside expectations. After deployment, compare the observed behavior with that baseline. This closes the loop between CI/CD, monitoring, and incident response instead of treating them as separate exam topics.

Backup and recovery thinking also changes in a managed service, but the business requirement does not disappear. Teams still need to understand which content, configuration, code, and external-system data are recoverable, what recovery objectives matter, and which restoration actions are controlled by the platform provider versus the customer team. Document those boundaries before an incident. A runbook built around unsupported server-level assumptions is not a recovery plan, even if those assumptions were reasonable in the era when AD0-E106 was current.

Prepare for AD0-E124 by converting old operational tasks into current cloud responsibilities

Make a mapping from legacy AD0-E106 topics to modern equivalents. Manual instance installation becomes environment and pipeline readiness. Patch management becomes release awareness and compatibility. Direct server changes become source-controlled or portal-managed configuration. Dispatcher troubleshooting remains relevant, while infrastructure scaling becomes largely managed. The concepts survive even when the control surface changes.

Then study the current AD0-E124 prep guide and current Adobe documentation as the authority. Use hands-on exercises that include failed deployments, bad configuration, cache issues, integration outages, permission problems, and log analysis. A DevOps certification is strongest when preparation reflects the operational decisions an engineer actually makes under pressure.

Run a controlled incident exercise to turn operational topics into usable skill

Create a non-production scenario where users report intermittent stale content and slow responses after a deployment. Begin with a timeline: deployment time, first alert, affected URLs, author changes, and any external-service incidents. Do not change configuration yet. Collect request headers, cache behavior, dispatcher information, application logs, pipeline status, and relevant platform metrics.

Form competing hypotheses. The issue could be failed invalidation, a cache key change, an external API slowdown, a new repository query, a configuration mismatch, or an application error causing retries. Identify the evidence that would confirm or reject each hypothesis. This prevents the common operational mistake of applying several “fixes” at once and losing the ability to learn what actually caused the incident.

Apply the smallest safe change through the supported path. If the cause is application code or configuration, fix it in source control and redeploy rather than relying on an undocumented production edit. If the platform itself appears unhealthy, assemble the evidence needed for escalation. The process should preserve auditability even when the team is under time pressure.

After recovery, verify more than page availability. Check error rates, cache behavior, response time, author-to-publish updates, integration health, and any backlog created during the incident. Then document the root cause and contributing factors. A successful incident response restores service; a mature response also reduces the chance of recurrence.

Use the post-incident review to map your skills to AD0-E124. Identify which knowledge came from AEM internals, which came from cloud operations, which depended on CI/CD, and which required developer collaboration. This integrated exercise reflects current DevOps work far better than memorizing separate administration commands from the AD0-E106 era.